Retningslinje
Skjemavalidering og feilmeldinger
Gode feilmeldinger hjelper alle når de fyller ut skjemaer, men de er særlig viktige for folk med nedsatt syn og folk med kognitiv funksjonsnedsettelse.
Plassering, grafisk utforming og innhold
Plasser feilmeldingen i nærheten av feltet som er feil. Dette gjør det lettere for brukeren å forstå hvilket felt feilmeldingen er tilknyttet og korriger feilen mens feilmeldingen er synlig. Ikke vis feilmeldinger i modalvinduer eller dialogbokser.
Feilmeldingen bør også plasseres i nærheten av feltet i DOMen, helst rett etter feltet. Koble feilmeldingen til feltet ved hjelp av aria-describedby
.
Bruk mer enn bare farge for å vise feil. I tillegg til farge skal feil også markeres med grafiske midler, aria-invalid
og selve feilmeldingen i tekst. Feilmeldingen skal gi spesifikk informasjon om hva problemet er. Hvis mulig skal løsningen også foreslå konkrete korrigeringer, f.eks. ved feilstavinger eller ugyldige formater.
Hjelpsom feilmelding
Dynamisk validering
Hvis løsningen validerer brukerens inndata før innsending av skjemaet, må du sikre at folk som bruker skjermleser blir informert at feilen har oppstått ved å bruke en ARIA live region (aria-live="assertive"
eller role="alert"
). Husk at denne må være på plass i DOMen når siden lastes inn for at den skal fungere.
Noen folk utforsker skjemaer før de starter å fylle dem ut ved å tabbe gjennom alle feltene, og mange folk fyller ut skjemaer ved å starte med feltene som er lettest å fylle ut. Derfor er det viktig å ikke vise en feilmelding dersom brukeren ikke har jobbet i feltet ennå. Du bør heller ikke vise en feilmelding mens brukeren fortsatt jobber i feltet.
Feilmeldinger som vises etter innsending
Gi brukere en tilbakemelding om suksess eller feil etter at de har sendt inn et skjema. Denne informasjonen skal ikke forsvinne automatisk. Oppdater gjerne sidens title
og h1
med resultatet av innsendingen.
For skjemaer med flere enn ett input, dersom innsendingen resulterte i feil, oppsummer feilene i en boks med en overskrift som forteller at det har forekommet feil. Si hvor mange feil har oppstått så brukeren får en oversikt over omfanget av problemene. List deretter opp feilene med en kulepunktliste. Bruk det samme tekst som står i label
til feltet som har feil, og lenk denne teksten til inputfeltene der feilene har oppstått.
Relevante lenker
Feil i oppsummeringsboksen kan gjerne forsvinne i det brukeren har korrigert inndataen sin. Etter at brukeren har korrigert alle feilene, må brukeren sende inn skjemaet på nytt for å få skjemaet validert på nytt.
Plassering av oppsummeringsboksen
Oppsummeringsboksen må befinne seg et sted på siden der svaksynte, folk med kognitive funksjonsnedsettelser og skjermleserbrukere ikke går glipp av den. Riktig plassering vil variere avhengig av løsningens arkitektur.
For løsninger som navigerer til en ny side ved innsending, bør oppsummeringsboksen plasseres rett før skjemaet, gjerne rett etter H1
. For løsninger med single-page application (SPA)-arkitektur, der hele siden ikke lastes inn på nytt ved innsending, kan oppsummeringen plasseres enten på toppen av skjemaet eller rett før innsendingsknappen. Bare sørg for at du flytter tastaturfokus til oppsummeringsboksen.
La gyldig data stå
Så langt som mulig bør du la gyldige data bli stående slik at det blir enklere for folk å fortsette med utfylling av skjemaet. Det er ekstremt frustrerende å måtte begynne på nytt med hele skjemaet for hver feilinnsending.
Unngå deaktivering av submit-knappen
Ikke bruk deaktivering av submit-knappen til skjemavalidering. Folk kan bli forvirret dersom de ikke skjønner hvorfor knappen er deaktivert, og synssvake folk og skjermleserbrukere kan slite med å finne knappen og tro at skjemaet har tekniske problemer. La heller submit-knappen forbli aktiv og vis feilmeldinger ved innsending som beskrevet over.
Relevante lenker
Sjekkliste
Validering etter innsending
Dynamisk validering
Medvirkende