Hopp til hovedinnhold
UUKontroll logo UUKontroll

Hjelp brukeren å rette skjemafeil (WCAG 3.3.3)

Når en feil oppdages automatisk, gi brukeren et konkret forslag til hvordan feilen kan rettes.

wcag niva-aa skjema

Det er én ting å fortelle brukeren at det er en feil. Det er noe helt annet å hjelpe dem med å fikse den. Mange nettsider stopper ved å si «Ugyldig verdi» uten å gi noe hint om hva som er gyldig. Det er som om en lærer bare skriver «Feil» i margen uten å forklare hva som er galt eller hvordan oppgaven skal løses.

Hva sier kravet?

WCAG 3.3.3 Forslag ved feil krever at dersom en feil oppdages automatisk og forslag til rettelse er kjent, skal forslagene presenteres for brukeren - med mindre det ville undergrave sikkerheten eller formålet med innholdet. Kravet er på nivå AA.

Forskjellen mellom 3.3.1 (Identifikasjon av feil) og 3.3.3 er viktig: 3.3.1 krever at du sier hva som er galt, mens 3.3.3 krever at du i tillegg foreslår hva som er riktig. WCAG 3.3.1 sier: «E-postadressen er ugyldig.» WCAG 3.3.3 sier: «E-postadressen mangler @-tegn. Prøv et format som navn@eksempel.no.»

Unntaket for sikkerhet er viktig. Hvis brukeren skriver feil passord, skal du ikke foreslå det riktige passordet. Men du kan si «Passordet er feil. Prøv igjen eller bruk lenken for glemt passord.»

Hvorfor er dette viktig?

Brukere vet ikke alltid hva som forventes

Mange skjemaer har krav til format som ikke er åpenbare. Skal telefonnummeret ha landskode? Skal postnummeret ha mellomrom? Er «ole.hansen» en gyldig e-postadresse? Uten konkrete forslag blir brukeren stående og gjette, og hvert mislykket forsøk øker frustrasjonen.

Kognitive utfordringer

Brukere med dysleksi, ADHD eller kognitive funksjonsnedsettelser kan ha spesielt vanskelig for å tolke abstrakte feilmeldinger. «Format ugyldig» gir dem lite å jobbe med. «Datoen skal skrives som DD.MM.ÅÅÅÅ, for eksempel 15.03.2026» gir dem et konkret mønster å følge.

Reduserer avbrudd og frafall

Hvert forsøk som mislykkes er en mulighet for at brukeren gir opp. I nettbutikker kan et forvirrende betalingsskjema med dårlige feilmeldinger føre direkte til tapt omsetning. I offentlige tjenester kan det bety at folk ikke får utført oppgaver de har krav på.

Skjermleserbrukere trenger spesifikke instruksjoner

En skjermleserbruker kan ikke se formateksempler eller andre visuelle hint rundt skjemafeltet. De er avhengige av at feilmeldingen i seg selv gir nok informasjon til å rette feilen uten å trenge visuell kontekst.

Slik oppfyller du kravet

Gi konkrete forslag ved formatfeil

Når du validerer input og oppdager en formatfeil, fortell brukeren nøyaktig hva du forventer:

<!-- Etter mislykket validering av telefonnummer -->
<div class="skjema-felt har-feil">
  <label for="telefon">Telefonnummer</label>
  <input type="tel" id="telefon" name="telefon"
    aria-invalid="true"
    aria-describedby="telefon-feil"
    value="12345">
  <span id="telefon-feil" class="feilmelding">
    Telefonnummeret må ha 8 siffer. 
    Skriv nummeret uten mellomrom eller landskode, 
    for eksempel 98765432.
  </span>
</div>

Foreslå rettelser der det er mulig

Noen ganger kan systemet gjette hva brukeren mente å skrive. I slike tilfeller, tilby et forslag:

<!-- E-post med vanlig skrivefeil -->
<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@gmial.com">
  <span id="epost-feil" class="feilmelding">
    Mente du ola@gmail.com? 
    <button type="button" 
      onclick="correctEmail('ola@gmail.com')">
      Bruk ola@gmail.com
    </button>
  </span>
</div>

Denne «mente du?»-tilnærmingen er spesielt nyttig for e-postadresser, der skrivefeil i domenenavnet er vanlig.

Vis tillatte verdier for begrensede felt

Når et felt bare godtar verdier fra et bestemt sett, fortell brukeren hva som er gyldig:

<div class="skjema-felt har-feil">
  <label for="fylke">Fylke</label>
  <input type="text" id="fylke" name="fylke"
    aria-invalid="true"
    aria-describedby="fylke-feil"
    value="Nord-Trøndelag">
  <span id="fylke-feil" class="feilmelding">
    «Nord-Trøndelag» er ikke et gyldig fylke. 
    Etter regionreformen heter det nå «Trøndelag». 
    Gyldige fylker er: Agder, Innlandet, 
    Møre og Romsdal, Nordland, Oslo, Rogaland, 
    Troms og Finnmark, Trøndelag, Vestfold og 
    Telemark, Vestland og Viken.
  </span>
</div>

Bruk inline-validering med forsiktighet

Sanntidsvalidering (mens brukeren skriver) kan gi umiddelbar tilbakemelding, men den bør implementeres med omhu:

const epostFelt = document.getElementById('epost');
const epostFeil = document.getElementById('epost-feil');

epostFelt.addEventListener('blur', function() {
  const verdi = this.value;
  
  if (verdi && !verdi.includes('@')) {
    this.setAttribute('aria-invalid', 'true');
    epostFeil.textContent = 
      'E-postadressen mangler @-tegn. ' +
      'Skriv adressen på formen navn@domene.no.';
    epostFeil.style.display = 'block';
  } else if (verdi && !verdi.includes('.')) {
    this.setAttribute('aria-invalid', 'true');
    epostFeil.textContent = 
      'E-postadressen mangler et gyldig domene. ' +
      'Sjekk at du har med .no, .com eller lignende.';
    epostFeil.style.display = 'block';
  } else {
    this.removeAttribute('aria-invalid');
    epostFeil.style.display = 'none';
  }
});

Legg merke til at valideringen kjører på blur (når brukeren forlater feltet), ikke på hvert tastetrykk. Å vise feilmeldinger mens brukeren fortsatt skriver er forvirrende og forstyrrende.

Datofelt med tydelige forventninger

Datoer er en klassisk kilde til forvirring. Er det DD/MM/ÅÅÅÅ eller MM/DD/YYYY? Gi tydelig beskjed:

<div class="skjema-felt har-feil">
  <label for="fodselsdato">Fødselsdato</label>
  <input type="text" id="fodselsdato" 
    name="fodselsdato"
    aria-invalid="true"
    aria-describedby="dato-feil"
    value="03/15/2026">
  <span id="dato-feil" class="feilmelding">
    Datoen ser ut til å bruke amerikansk format. 
    Skriv datoen som DD.MM.ÅÅÅÅ, 
    for eksempel 15.03.2026.
  </span>
</div>

Vanlige feil

  • «Ugyldig verdi» uten forklaring - den vanligste synden. Brukeren vet at noe er galt, men ikke hva eller hvordan de skal fikse det.
  • Tekniske feilmeldinger - meldinger som «Regex mismatch» eller «Validation error: pattern» er uforståelige for vanlige brukere. Oversett feilmeldinger til et språk brukerne forstår.
  • Manglende formatforslag - feltet krever et spesifikt format (f.eks. organisasjonsnummer med ni siffer), men feilmeldingen nevner ikke formatet.
  • Forslag som ikke fungerer - «Mente du?»-forslag som peker til feil alternativ, eller lenker som ikke virker. Test forslagene grundig.
  • Manglende forslag ved passord - i stedet for bare «Passordet oppfyller ikke kravene», vis kravene tydelig: «Passordet må ha minst 8 tegn, en stor bokstav og et tall.»
  • Ingen forslag for datoer - feilmelding sier «Ugyldig dato» uten å vise forventet format.

Gode forslag ved feil er en investering i brukeropplevelsen. De sparer brukerne for frustrasjon, reduserer frafall, og gjør at flere fullfører det de kom for å gjøre.