Innledning

Feilmeldinger kan komme fra systemet eller være utløst av noe brukerne har gjort. Denne artikkelen handler om brukerutløste feilmeldinger i selvbetjeningsløsninger og skjema. Hvordan kan vi unngå å gi feilmeldinger, og hvordan kan vi hjelpe brukerne å komme seg videre når det likevel har oppstått en feil?

Når brukerne har gjort en feil som hindrer dem i å komme videre, skal vi varsle dem om feilen slik at de kan rette opp:

• Beskriv problemet på en lettforståelig måte.
• Forklar hva brukerne må gjøre for å komme videre.
• Passe på at feilmeldingen er lett synlig.

Feilmeldinger kan være knyttet til ett enkelt felt eller til flere. Vi viser en oppsummering av flere feil hvis brukeren forsøker å gå videre uten å ha fylt ut alt.

Feilmeldinger på enkeltfelt

Vi skal kunne vise feilmeldinger sammen med alle typer felt i et skjema. Meldingen skal stå nært feltet som feiler.

Oppsummering av flere feilmeldinger

En oppsummering kan gjelde for én eller flere feil. Hvis brukerne prøver å gå videre uten å ha fylt ut alt, eller de har gjort feil, oppsummerer vi like over Neste/Send inn-knappen.

Vi anbefaler å vise oppsummeringen i nærheten av Neste-knappen for at brukerne skal forstå sammenhengen mellom feilen og hvorfor de blir hindret i å gå videre. I noen tilfeller kan det likevel være bedre å vise oppsummeringen i toppen, for eksempel hvis

• den tekniske løsningen laster siden på nytt når brukerne velger Neste
• brukerne har vært ute av et skjema og går inn igjen
• løsningen ikke stopper brukerne fra å gå til neste side selv om de har feil på en side

Pass på at

• oppsummeringen viser alle feilmeldingene som gjelder for siden eller trinnet
• brukerne kan gå direkte til feilene de må rette opp, og fokuset blir flyttet dit
• lenkene i oppsummeringen stemmer med feilmeldingene de lenker til
• du lenker til den første av flere feil
• feilene forsvinner fra oppsummeringen etter hvert som brukerne fikser dem
• feilmeldingen i oppsummeringen har med nøkkelord fra ledeteksten

Det er best om vi kan unngå å gi feilmeldinger

Når vi planlegger en løsning, bør målet være å hindre at det oppstår feil. Disse punktene kan hjelpe i planleggingen:

• Gi all relevant informasjon før brukerne starter, i klart og tydelig språk.
• Bruk ledetekster og beskrivelser for å hjelpe brukerne underveis.
• Unngå hjelpetekster bak spørsmålstegn om du kan, men bruk dem om nødvendig.
• Gi brukerne mulighet til å endre svar i felt eller gå tilbake.
• La brukerne ta en pause i utfyllingen eller avbryte den.
• Sørg for at feltene godtar ulik formatering, for eksempel for datoer og telefonnummer.
• Legg inn en bestemt rekkefølge på svaralternativene, for å hindre at brukeren tar valg som fører til feil.
• Vis informasjon om maks. antall tegn under ledeteksten hvis feltet har tegnbegrensning.

Ulike typer feilmeldinger

Systemgenererte meldinger

Vi bruker systemmeldinger, eller systemvarsler, for å varsle brukeren om feil i systemet eller gi dem viktig informasjon de bør få med seg. Vi har en egen artikkel om systemvarsler.

Infomeldinger til brukeren

Infomeldinger som vises på grunn av noe brukerne gjør, stopper ikke brukerne fra å sende inn eller gå videre til neste steg.

Vi viser infomeldinger når vi skal informere om konsekvenser av et valg. Slike meldinger kan vi for eksempel presentere i en alert av typen "info" eller "success". Disse meldingene vises etter at brukeren har oppgitt informasjon i et skjemafelt, og oppfører seg på samme måte som feilmeldinger.

Eksempler:

• Du starter en bedrift og skal registrere navnet. Du får beskjed om at bedriftsnavnet allerede er i bruk av noen andre. Du kan bruke navnet du har valgt, men du kan få problemer med domenenavn eller at foretaket ditt blir forvekslet med et annet.
• Du gjør et valg i et søknadskjema som fører til lengre behandlingstid. Du får en infomelding om lengre ventetid.

Språk

Skriv gode feilmeldinger

Den viktigste jobben til en feilmelding er å hjelpe brukerne videre:

• Skriv vennlig, klart og tydelig.
• Hold feilmeldingen så kort som mulig.
• Vær konkret. Hvis vi skriver “Feltet er ikke fylt ut korrekt”, får brukeren ingen forklaring på hva som er feil.
• Gjenta nøkkelord fra ledeteksten/feltnavnet så tidlig som mulig i feilmeldingen.

Noen tekniske løsninger gjør at vi kan ta inn feltnavnet som en variabel i feilmeldinger, da blir feltnavnet i ubestemt form, som i disse eksemplene:

• “Postnummer må ha 4 siffer”
• "Fødselsnummer må ha 11 siffer"
• “Velg minst ett leveringsalternativ”

Hvis løsningen ikke tar inn feltnavnet som variabel i feilmeldinger, anbefaler vi å skrive substantivet med bestemt form: Postnummeret må ha fire siffer.

Design og opplevelse

Utseendet på feilmeldinger

Når det oppstår feil i et felt er det viktig at feltet blir godt synlig, slik at det er lett for brukerne å se hvor de må fylle ut eller rette opp noe.

Når den tekniske løsningen sjekker for feil, det vi kaller validerer, ønsker vi å vise hvilke felt som har feil. Til det kan vi bruke flere virkemidler.

Visuelle endringer

Vis feilmeldingsteksten nært feltet det gjelder. Vi anbefaler å ha med et ikon som en visuell indikator i tillegg til tekst. For skjemakomponenter som tillater det, kan vi også endre tykkelsen på rammen rundt, som vist i eksempelet over.

Fargevalg

Vi bruker rød som varselfarge for feil, det vi si at feltet og selve feilmeldingen blir røde. Dette er et godt etablert mønster, som hjelper med å skille feltet fra andre felt.
Feltet må ha 3:1 kontrast til bakgrunnsfargen. Hvis vi også bruker rød tekst til feilmeldingen, må den minst ha kontrasten 4.5:1. Les mer om kontraster hos Tilsynet for universell utforming av IKT.

Slik plasserer vi en feilmelding

Vi viser feilmeldingen under feltet med feil. Dette er det vanligste mønsteret, selv om det også diskuteres om den skal stå mellom ledeteksten og feltet.

Når skal vi vise en feilmelding?

Vi kan vise feilmeldinger når brukerne forlater feltet, når de velger å gå videre, eller sender inn. Vi unngår å vise feilmeldinger mens brukeren fyller ut et felt.

Når brukerne har gjort en feil når de fyller ut et felt og de går videre, viser vi feilmeldinger når vi kan se at brukeren ikke har fylt ut det vi forventer. Et eksempel kan være at de har lagt inn bokstaver i et fødselsnummer, eller at en e-postadresse mangler krøllalfa (@).

Brukerne bør ikke få feilmelding for et tomt obligatorisk felt før de går til neste side eller sender inn skjemaet. Vi vet ikke alltid når brukeren er ferdig med å fylle ut feltene, så da venter vi til brukeren selv er klar til å gå videre. Det er spesielt viktig når brukere benytter tastaturet til å navigere i løsningen.

Kryssvalidering

Noen ganger vil det brukeren velger i ett eller flere felt påvirke felt som kommer senere i skjemaet. For eksempel kan et valg brukerne gjør i en radiogruppe, gjøre at et frivillig felt lenger ut i skjemaet blir obligatorisk. Et valg på ett sted kan også gjøre at et valg et annet sted må være innenfor en viss verdi. I slike tilfeller snakker vi om kryssvalidering.

Her må vi gjøre det så tydelig som mulig for brukeren at flere felt påvirker hverandre:

• Merk alle feltene visuelt og med feilmelding.
• Forklar hva som utløste feilen. Vær tydelig på at feilen skyldes kryssvalidering.
• Fortell brukerne hva de kan gjøre for å rette feilen.

Feilmeldinger som gjelder flere felt

I dette eksempelet har vi en gruppe med felt, der brukeren ikke nødvendigvis har alle opplysningene, men må fylle ut minst ett felt.

Kode

Feilmeldinger og tilgjengelighet

Det er flere WCAG-kriterier som gjelder for feilmeldinger. Vi har tatt hensyn til disse i arbeidet med denne artikkelen. Hvis du vil vite mer om det, kan du lese tolkningene av WCAG-kravene hos Tilsynet for universell utforming av IKT.

Relevante WCAG-krav:

• 3.3.1 Identifikasjon av feil
• 3.3.3 Forslag ved feil
• 1.4.3 Kontrast (minimum)
• 1.4.11 kontrast for ikke-tekstlig innhold

Ikke deaktiver submit-knappen

Vi bruker ikke deaktivert "Gå videre/Send inn"-knapp til å validere skjema. Noen brukere forstår ikke hvorfor knappen er deaktivert og blir forvirret. Brukere med nedsatt syn kan slite med å finne knappen og tro at skjemaet har tekniske problemer. Hvis brukerne prøver å gå videre mens det fortsatt er feil i skjemaet, kan vi heller vise en oppsummerende feilmelding over "Gå videre/Send inn"-knappen.

HTML og Aria

For at alle brukere skal oppfatte feilmeldinger, er det viktig med et tydelig forhold mellom feilmeldingene og feltene de tilhører, også for dem som ser på innhold med ulike hjelpemidler.

Vi kan bruke disse aria-attributtene og rollene:

• Vi setter aria-invalid="true" på felt med feil, for å si fra om at det er en feil der.
• Vi bruker aria-describedby for å koble feilmelding til feltet.

Gi automatiske beskjeder

Vi kan også gi automatiske beskjeder når vi vil at brukeren så snart som mulig skal få opplest viktig informasjon. Det kan for eksempel være når det blir en stor visuell endring, eller nytt innhold.

For feilmeldinger som dukker opp dynamisk må vi bruke aria-live for at meldingen skal bli lest opp av skjermlesere. Pass godt på om du setter aria-live til å være assertive eller polite. I de fleste tilfeller er det best å bruke polite, for da venter skjermleseren med å lese opp feilmeldingen til den er ferdig med å lese opp innholdet.

Kilder

• Help users to Recover from validation errors, GovUK
• Designing Better Error Messages UX, Smashing Magazine/Vitaly Friedman
• Formidle feil i skjema, UU-tilsynet
• Use forgiving formatting, NN Group
• Error Messages Guidelines, NN Group
• How to Report Errors in Forms, NN Group
• Suksesskriterium 3.3.1 Identifikasjon av feil
• Suksesskriterium 3.3.3 Forslag ved feil
• Skjemavalidering, Aksel
• Fejlmeddelelser, Fælles designsystem