Vis tydelig hvor og hva feilen er (WCAG 3.3.1)

Du fyller ut et kontaktskjema og trykker «Send». Skjemaet oppdateres, og nå har tre felter fått en rød ramme. Men hvilke felter er det? Hva er feil med dem? Hvorfor ble de avvist? Hvis det eneste hintet er en farge, har du et tilgjengelighetsproblem - og en dårlig brukeropplevelse for alle.

Hva sier kravet?

WCAG 3.3.1 Identifikasjon av feil krever at når en inndatafeil oppdages automatisk, skal elementet med feilen identifiseres og feilen beskrives i tekst. Kravet er på nivå A.

«Oppdages automatisk» betyr feil som systemet kan oppdage uten menneskelig vurdering - for eksempel at et obligatorisk felt er tomt, at en e-postadresse mangler @-tegnet, eller at et postnummer har bokstaver. Kravet handler ikke om innholdsmessige feil som systemet ikke kan vite om (for eksempel at brukeren har skrevet feil navn).

To ting er sentrale: feilen skal identifiseres (brukeren skal vite hvilket felt som har feilen) og den skal beskrives i tekst (ikke bare med farge, ikon eller plassering).

Hvorfor er dette viktig?

Farge alene er ikke nok

Det er vanlig å markere feil med rød farge - en rød ramme rundt feltet, rød tekst, eller at label-teksten blir rød. Men omtrent 8 % av alle menn er fargeblinde, og mange av disse ser ikke forskjell på rød og grønn. For dem er den røde rammen usynlig.

I tillegg: selv for brukere med normalt fargesyn kan farge alene være tvetydig. Er feltet rødt fordi det er feil, eller fordi det er viktig? En tydelig tekstbeskrivelse fjerner all tvil.

Skjermlesere trenger tekst

En skjermleser kan ikke se at et felt har fått rød ramme. Den trenger en programmatisk kobling mellom feltet og en tekstbeskrivelse av feilen. Uten det vil en skjermleserbruker ikke engang vite at det er en feil, langt mindre hva feilen er eller hvordan den kan fikses.

Alle brukere gjør feil

Å fylle ut skjemaer er en av de vanligste kildene til frustrasjon på nettet. Tydelige feilmeldinger hjelper alle - ikke bare brukere med funksjonsnedsettelser. Et godt feilhåndteringssystem gjør at brukeren raskt forstår hva som gikk galt, og fikser det uten å måtte gjette.

Juridiske konsekvenser

For norske virksomheter er dette et lovkrav. Hvis skjemaene dine ikke identifiserer feil på en tilgjengelig måte, er det et brudd på forskrift om universell utforming av IKT. For virksomheter som leverer offentlige tjenester, kan det også bety at brukere ikke får utført tjenester de har krav på.

Slik oppfyller du kravet

Vis feilmelding i tekst ved hvert felt

Den mest robuste løsningen er å vise en feilmelding i ren tekst like ved feltet som har feilen, og koble den programmatisk til feltet med aria-describedby:

<div class="skjema-felt har-feil">
  <label for="epost">E-postadresse</label>
  <input type="email" id="epost" name="epost"
    aria-invalid="true"
    aria-describedby="epost-feil"
    value="ola.nordmann">
  <span id="epost-feil" class="feilmelding" role="alert">
    E-postadressen mangler @-tegn og domene. 
    Skriv en gyldig e-postadresse, 
    for eksempel navn@eksempel.no.
  </span>
</div>

Legg merke til tre viktige ting i eksempelet:

1. aria-invalid="true" forteller hjelpeteknologi at feltet har en ugyldig verdi
2. aria-describedby="epost-feil" kobler feltet til feilmeldingen slik at skjermleseren leser den opp
3. role="alert" gjør at meldingen annonseres automatisk av skjermlesere når den dukker opp

Vis en oppsummering av feil øverst i skjemaet

I tillegg til feilmeldinger ved hvert felt, er det god praksis å vise en feiloppsummering øverst i skjemaet:

<div role="alert" class="feiloppsummering">
  <h2>Det er 2 feil i skjemaet</h2>
  <ul>
    <li>
      <a href="#epost">E-postadresse: 
        Mangler @-tegn og domene</a>
    </li>
    <li>
      <a href="#telefon">Telefonnummer: 
        Må inneholde 8 siffer</a>
    </li>
  </ul>
</div>

Lenkene i oppsummeringen peker til de aktuelle feltene, slik at brukeren raskt kan hoppe dit og rette feilen. Flytt også fokus til feiloppsummeringen etter innsending, slik at skjermleserbrukere umiddelbart hører at det er feil.

Bruk HTML5-validering som grunnlag

Nettleserens innebygde validering gir en grunnleggende feilhåndtering, men den er begrenset og vanskelig å style. Mange velger å supplere eller erstatte den med egendefinert validering:

<form novalidate>
  <div class="skjema-felt">
    <label for="postnr">Postnummer</label>
    <input type="text" id="postnr" name="postnr"
      pattern="[0-9]{4}" 
      required
      aria-describedby="postnr-hjelp">
    <span id="postnr-hjelp" class="hjelpetekst">
      Fire siffer, for eksempel 0150
    </span>
  </div>
  <button type="submit">Send inn</button>
</form>

Med novalidate på <form> kan du ta over valideringen med JavaScript og vise feilmeldinger i ditt eget format, men med riktig semantikk.

Ikke fjern brukerens input

Når du viser feilmeldinger, la verdien brukeren skrev stå i feltet. Det er frustrerende å måtte skrive alt på nytt. La brukeren se hva de skrev, forstå hva som var feil, og korrigere det.

Vanlige feil

• Bare rød ramme, ingen tekst - den vanligste feilen. En fargeendring forteller verken fargeblinde eller skjermleserbrukere hva som er galt.
• Generisk feilmelding - «Det oppstod en feil» eller «Vennligst fyll ut alle felt» uten å spesifisere hvilke felt som er feil. Brukeren skal ikke måtte lete.
• Feilmelding langt fra feltet - en feilmelding øverst på siden uten lenker til de aktuelle feltene. Brukeren (spesielt på mobil) ser kanskje aldri meldingen.
• Manglende aria-invalid og aria-describedby - feilmeldingen kan synes visuelt, men skjermlesere kobler den ikke til riktig felt.
• Feilmeldinger som forsvinner - tidsbegrensede feilmeldinger som forsvinner etter noen sekunder. Brukere som trenger tid til å lese dem, rekker kanskje ikke det.
• Inndata slettes ved feil - feltverdiene tømmes når skjemaet sendes tilbake med feil, slik at brukeren må fylle ut alt på nytt.

God feilhåndtering er respekt for brukerens tid og innsats. Fortell hva som er galt, fortell det tydelig, og gjør det enkelt å rette opp.