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

Gjør

Unngå

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 på toppen av skjemaet. Dersom du plasserer oppsummeringen andre steder på siden kan svaksynte folk, folk med kognitive funksjonsnedsettelser og skjermleserbrukere gå glipp av den.

Gi boksen 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.

Feil i oppsummeringsboksen bør forsvinne i det brukeren korrigerer inndataen sin. Etter at brukeren har korrigert alle feilene, må brukeren sende inn skjemaet på nytt for å få skjemaet validert på nytt.

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.

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.

Sjekkliste

• Plasser feilmeldingen i nærheten av feltet som har feil.
• Koble feilmeldingen til feltet med `aria-describedby`.
• Marker feilen med farge, tekst, grafiske midler og `aria-invalid`.
• Gi spesifikk informasjon om hvordan brukere kan korrigere feltet.
• La gyldig data bli stående.

Validering etter innsending

• Gi brukeren en tilbakemelding om suksess eller feil i sidens `title `og `H1`.
• Oppsummer feilmeldinger på toppen av skjemaet i en boks med en kulepunktliste.
• Si hvor mange feil har forekommet i boksens tittel.
• Lenk feilmeldingene til feltene de gjelder med feltets `label`.
• Fjern feilmeldingene etter brukeren har korrigert sin inndata.

Dynamisk validering

• Bruk en aria live region til feilmeldingen.
• Valider bare etter brukeren har jobbet i og forlatt feltet.