Når dine fejlmeddelelser lukker brugere ude

Øjeblikket, hvor formularen bryder sammen

Forestil dig dette: en blind bruger udfylder en betalingsformular, indsender den og hører intet brugbart fra sin skærmlæser. Ingen annoncering. Ingen forklaring. Siden har visuelt markeret fem valideringsfejl med rødt, men brugeren aner det ikke. De trykker på indsend igen. Og igen. Til sidst forlader de siden.

Dette er ikke et sjældent scenarie. Utilgængelig fejlhåndtering er en af de mest almindelige barrierer, vi finder i rigtige revisioner, og det er en, der typisk frustrerer brugerne på det værst tænkelige tidspunkt — når de forsøger at gennemføre en transaktion eller indsende noget vigtigt.

Den gode nyhed er, at det i høj grad handler om at vide, hvordan “godt” ser ud. Fejlene er næsten altid de samme få mønstre.

Hvorfor fejlmeddelelser er svære for brugere af hjælpeteknologi

Seende musebrugere bemærker typisk valideringsfejl med det samme — den røde kant, advarselsikonet, teksten, der dukker op under feltet. Men brugere, der er afhængige af skærmlæsere, tastaturnavigation eller stemmestyring, oplever noget fundamentalt anderledes.

Når en formular indsendes, og der opstår fejl:

Skærmlæserbrugere hører muligvis ingenting, medmindre fokus flyttes til fejlen, eller et live-område annoncerer den
Tastaturbrugere skal kunne nå hver fejlmeddelelse fra tastaturet og forstå, hvilket felt den hører til
Stemmestyringsbrugere skal kunne adressere felter via en synlig, korrekt etiket — hvis etiketten er forkert eller mangler, sidder de fast

Intet af dette sker automatisk. Du skal bygge det.

De WCAG-kriterier, der gælder

Fire succeskriterier i WCAG 2.2 dækker fejlhåndtering direkte:

3.3.1 Identifikation af fejl (niveau A) — Hvis en fejl opdages automatisk, skal det fejlbehæftede element identificeres og beskrives for brugeren i tekst. Du må ikke formidle fejl gennem farve alene.

3.3.2 Etiketter eller instruktioner (niveau A) — Inputfelter, der kræver et bestemt format, skal gøre kravet tydeligt før eller under indtastningen, ikke først efter at indsendelsen er mislykkedes.

3.3.3 Fejlforslag (niveau AA) — Hvis en fejl opdages, og der kendes forslag til rettelse, skal de gives. “Ugyldig dato” er ikke nok. “Angiv datoen i formatet DD/MM/ÅÅÅÅ” er.

3.3.4 Forebyggelse af fejl (niveau AA) — Ved indsendelser med væsentlige konsekvenser (finansielle transaktioner, juridiske aftaler) skal brugerne kunne gennemgå, rette og bekræfte, før handlingen er endelig.

Der er også 4.1.3 Statusmeddelelser (niveau AA), som dækker dynamisk indsatte meddelelser, der ikke modtager fokus — disse skal annonceres af hjælpeteknologi ved hjælp af role="status" eller role="alert".

Hvad en tilgængelig fejlmeddelelse faktisk kræver

At få fejlmeddelelser rigtige kræver opmærksomhed på fire adskilte lag:

1. Den programmatiske forbindelse

Hver fejlmeddelelse skal knyttes til sit felt via aria-describedby. Det fortæller skærmlæsere, at fejlteksten skal annonceres, når feltet modtager fokus.

<!-- Before: error text exists visually but is invisible to screen readers -->
<label for="email">Email</label>
<input type="email" id="email" class="error">
<p class="error-text">Enter a valid email address.</p>

<!-- After: programmatic association via aria-describedby -->
<label for="email">Email address</label>
<input
  type="email"
  id="email"
  aria-describedby="email-err"
  aria-invalid="true"
>
<p id="email-err" class="error-text">Enter a valid email address.</p>

Attributten aria-invalid="true" signalerer, at feltet i øjeblikket er ugyldigt, hvilket de fleste skærmlæsere annoncerer, når fokus lander på det.

2. Fokusstyring efter indsendelse

Når en formular indsendes, og der er fejl, skal fokus flyttes et brugbart sted hen. De to mest almindelige mønstre:

Flyt fokus til et fejlresumé øverst i formularen, der lister alle fejl med links til de relevante felter
Flyt fokus til det første felt med fejl

Hvis fokus bliver på indsend-knappen eller slet ingen steder, må skærmlæserbrugere selv opdage fejlene ved at navigere gennem formularen — hvis de overhovedet ved, at der er fejl.

// After validation fails, move focus to the error summary
const summary = document.getElementById('error-summary');
summary.setAttribute('tabindex', '-1');
summary.focus();

3. Live-annonceringer af dynamiske fejl

Til fejl, der vises, mens brugeren skriver (inline realtidsvalidering), skal du bruge ARIA-live-områder, så meddelelsen annonceres, uden at fokus behøver at flyttes.

<p role="alert" aria-live="assertive" id="password-err">
  Password must be at least 8 characters.
</p>

Brug role="alert" / aria-live="assertive" til fejl, der kræver øjeblikkelig opmærksomhed. Brug role="status" / aria-live="polite" til mindre presserende feedback, der kan vente på, at brugeren holder pause.

4. Selve fejlmeddelelsen

Sproget betyder noget. Tilgængelige fejlmeddelelser er:

Specifikke: sig, hvad der er galt, ikke bare at noget er galt
Handlingsanvisende: fortæl brugeren præcis, hvad de skal gøre for at rette det
Høflige: undgå bebrejdende sprog som “du har indtastet en ugyldig værdi”

Utilgængeligt	Tilgængeligt
”Ugyldigt input"	"E-mailadressen skal indeholde et @-tegn, f.eks. navn@eksempel.dk"
"Fejl"	"Datoen skal være i formatet DD/MM/ÅÅÅÅ"
"Obligatorisk felt"	"Fulde navn er påkrævet"
"Adgangskode ugyldig"	"Adgangskoden skal være på mindst 8 tegn og indeholde ét tal”

Mønstre til forskellige fejlscenarier

Inline-fejl ved felter

Det mest almindelige mønster. En fejlmeddelelse vises direkte under det tilknyttede felt. Fungerer godt til simple formularer. Kræver aria-describedby og aria-invalid for at blive annonceret korrekt.

Fejlresumé-bannere

Til lange formularer med flere fejl placeres et resumé øverst, der lister alle problemer som links, der hopper til det relevante felt. Flyt fokus hertil efter en mislykket indsendelse. Dette er mønsteret, GOV.UK bruger, og det anbefales bredt til komplekse formularer.

Toast-notifikationer

Kortvarige meddelelser, der vises i kanten af skærmen, er blandt de mest utilgængelige mønstre i almindelig brug. De forsvinder, før skærmlæserbrugere kan nå dem, de bliver ofte slet ikke annonceret, og de giver ingen vej til at rette op. Undgå at bruge toasts til fejl. Hvis du alligevel bruger dem, skal du kombinere dem med en vedvarende fejltilstand på selve formularen.

Systemfejl

Når noget går galt på serversiden, skal du fortælle brugeren i et klart sprog, hvad der skete, og hvad de kan gøre nu. “Noget gik galt” uden yderligere vejledning efterlader brugerne strandede.

<div role="alert" aria-live="assertive">
  <p>We couldn't save your changes due to a network error.
  Please check your connection and try again.</p>
</div>

Tjeklisten til test

Efter du har implementeret fejlhåndtering, skal du verificere disse manuelt — automatiserede værktøjer fanger ikke de fleste af dem:

Indsendelse af en tom, obligatorisk formular flytter fokus til et fejlresumé eller det første felt med fejl
Hver fejlmeddelelse er knyttet til sit felt via aria-describedby
Felter med fejl har aria-invalid="true"
Fejlmeddelelser annonceres, når fokus lander på det berørte felt
Realtidsvalidering bruger live-områder
Fejlmeddelelser bruger specifikt, handlingsanvisende sprog — ikke bare “ugyldig”
Farve er ikke den eneste måde, fejl vises på (ikon eller tekstetiket sammen med det røde)
Fejlen kan nås med tabulatortasten fra tastaturet
Fokusrækkefølgen efter indsendelse er logisk og hopper ikke uforudsigeligt
Toast-meddelelser er kombineret med en vedvarende fejltilstand

Hvorfor automatiserede værktøjer overser det meste af dette

En automatiseret scanner kan tjekke, om aria-describedby peger på et eksisterende element, og om aria-invalid er til stede. Den kan ikke tjekke, om fokus flyttes korrekt efter indsendelse, om fejlteksten er præcis, eller om en toast-notifikation forsvinder, før den kan læses. Vores manuelle tilgængelighedsrevisioner omfatter formularspecifik test med rigtig hjælpeteknologi — den eneste pålidelige måde at verificere, at fejlhåndteringen faktisk fungerer hele vejen igennem.

Hvis du er usikker på, hvor dine formularer står, så kør en gratis scanning for at afdække de automatiserbare problemer først, og tag den derfra.