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. Hvis du bruker skjemakomponentene i Aksel og propen error blir disse kravene automatisk oppfylt.

Hjelpsom feilmelding

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.

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. Skjemakomponentene i Aksel har dette innebygget.

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. Bruk gjerne komponenten ErrorSummary. Les mer om hvordan en slik oppsummeringsboks bør implementeres i dokumentasjonen til ErrorSummary.

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.

Mønster for skjemavalidering

For å fremme mer enhetlige løsninger er det på bakgrunn av god praksis utformet et mønster for skjemavalidering. Mønsteret beskriver en detaljert, anbefalt løsning for skjemavalidering i søknadsdialoger.

Sjekkliste

Validering etter innsending

Dynamisk validering