Det er best om vi klarer å hindre at det oppstår feil. Da må vi på forhånd oppgi tydelig hva brukeren må gjøre for å fylle ut feltene i skjemaet riktig. Vi må godta ulik formatering, for eksempel på felt med tall, som i telefonnummer eller datoer. Brukerne må alltid få mulighet til å redigere felter eller gå tilbake, og kunne pause utfyllingen eller avbryte.
Når det likevel har oppstått et problem som gjør at brukeren ikke kommer videre, skal vi vise en feilmelding som beskriver problemet og forklarer hva brukerne må gjøre.
Vi har ulike typer feilmeldinger
- Detaljerte feilmeldinger, som tilhører et bestemt felt i et skjema.
- Oppsummerende feilmeldinger, som kan vise en eller flere feilmeldinger.
For andre type feil som ikke tilhører et skjemaelement, og som ikke validerer brukerens inndata, kan du bruke alert
-komponenten. Det kan for eksempel være for systemfeil, eller til myke valideringer. Myke valideringer er meldinger som ikke stopper brukeren fra å sende inn eller gå videre til neste steg i prosessen, men som bare gir brukeren informasjon.
Detaljerte feilmeldinger
Plasser feilmeldinger som tilhører et bestemt felt på siden så nært feilen som mulig. Pass på at du kobler den til feltet med aria-describedby
.
Feltet skal tydelig vise at noe er feil. Dette gjør vi med rød farge, forklarende tekst og aria-invalid
. Plasser teksten som viser hva som er feil og hva brukeren må gjøre, rett under selve feltet der feilen er.
Når skal feilmeldinger presenteres for brukeren?
Vi kan presentere feilmeldinger for brukerne enten når
- Brukeren forlater feltet
- Brukeren trykker "Gå videre" eller "Send inn"
Vi skal ikke vise feilmeldinger mens brukeren fyller ut feltet. Mange bruker nemlig tastatur til å navigere i skjemaet. De vil ikke nødvendigvis starte på toppen og jobbe seg nedover og derfor vil det forstyrre hvis det dukker opp feilmeldinger på felter brukeren ikke har fylt ut enda.
Hvis vi har feilmeldinger som skal vises når brukeren forlater feltet, må vi kode det slik at vi vet om brukeren faktisk har skrevet noe i feltet før vi viser feilmeldingen. Det tryggeste er å vise feilmeldingen når brukeren selv er klar til å gå videre.
Det kan være irriterende for brukerne hvis feilmeldingen vises når de forlater feltet. Brukerne bør først få en feilmelding for et obligatorisk felt når de prøver å gå til neste side eller sende inn skjemaet. Vis tydelig at et felt må fylles ut. Her kan du lese mer om hvordan du markerer obligatoriske og valgfrie skjemafelt.
Oppsummerende feilmeldinger
I noen tilfeller bør vi oppsummere alle feil øverst på siden eller like over "Gå videre" / "Send inn"-knappen. Oppsummeringen kan gjelde for én eller flere feil. Teksten i en oppsummerende feilmelding skal være lik det du ser i den detaljerte feilen (se eksempelet under).
Den løsningen eller tjenesten du lager, bestemmer om du bør plassere oppsummeringen øverst på siden eller lenger nede, før knappen som tar brukerne videre. Se eksempelet over. Det viktigste er at brukeren lett ser oppsummeringen.
Pass på at
- oppsummeringen viser alle feilmeldingene som gjelder for siden eller trinnet
- brukerne kan gå direkte til feilene de må rette og at fokuset blir flyttet dit
- lenkene i oppsummeringen stemmer med feilmeldingen de lenker til
- du skriver feilmeldingen slik at den er lett å forstå, at den gir mening for brukerne når de kun leser feilmeldingen i oppsummeringen
- hvis det er flere feil, så lenker du til den første feilen i rekken
- feilene forsvinner fra oppsummeringen etter hvert som brukerne fikser dem
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 kan bli forvirret. Brukere med nedsatt syn kan slite med å finne knappen og tro at skjemaet har tekniske problemer. Hvis brukeren prøver å velge knappen mens det er feil i skjemaet, kan vi heller vise en oppsummerende feilmelding over "Gå videre"/"Send inn"-knappen.
Tekst i feilmeldinger
Den viktigste jobben til teksten i en feilmelding er å hjelpe brukerne videre:
- Tenk på målgruppen og skriv vennlig, klart og tydelig. Unngå passivt eller teknisk språk. Meldingen skal være lett å forstå.
- Unngå humor i feilmeldinger. Når folk møter på et problem, vil de heller ha effektive forslag til hvordan de løser det, enn humoristiske «Oops!»
- Vær konkret. Når du skriver “Feltet er ikke fylt ut korrekt”, får ikke brukeren noen forklaring på hva som er feil. Gi konkret informasjon om hva som er problemet og gjenta gjerne nøkkelord fra ledeteksten.
- Noen ganger må vi beskrive hva feilen er før vi beskriver hva brukerne skal gjøre, men det viktigste er å vise løsningen på problemet.
- Tilpass feilmeldingene til ulike situasjoner. Jobben til teksten er å hjelpe brukeren videre.
- Hold feilmeldingen kort, da sparer du brukerne for tid.
Eksempel på forklarende feilmeldinger:
- “Postnummeret må ha 4 siffer”
- "Fødselsnummeret må ha 11 siffer"
- “Velg minst ett av leveringsalternativene”
- “Kryss av i ruten for å bekrefte at navnet er riktig, før du sender inn skjemaet”
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