När dina felmeddelanden stänger ute användare

Ögonblicket när formuläret brister

Föreställ dig detta: en blind användare fyller i ett kassaformulär, skickar in det och hör inget användbart från sin skärmläsare. Inget besked. Ingen förklaring. Sidan har visuellt flaggat fem valideringsfel i rött, men användaren har ingen aning. Hen trycker på skicka igen. Och igen. Till slut ger hen upp och lämnar sidan.

Detta är inget marginellt scenario. Otillgänglig felhantering är ett av de vanligaste hindren vi hittar i verkliga granskningar, och det är ett som tenderar att frustrera användare vid sämsta möjliga tillfälle — när de försöker slutföra en transaktion eller skicka in något viktigt.

Den goda nyheten är att lösningen till stor del handlar om att veta hur “bra” ser ut. Bristerna är nästan alltid samma få mönster.

Varför felmeddelanden är svåra för användare av hjälpmedelsteknik

Seende musanvändare lägger oftast märke till valideringsfel direkt — den röda ramen, varningsikonen, texten som dyker upp under fältet. Men användare som förlitar sig på skärmläsare, tangentbordsnavigering eller röststyrning möter en i grunden annorlunda upplevelse.

När ett formulär skickas in och fel visas:

Skärmläsaranvändare hör kanske ingenting alls om inte fokus flyttas till felet eller en live-region läser upp det
Tangentbordsanvändare behöver kunna nå varje felmeddelande med tangentbordet och förstå vilket fält det hör till
Röststyrningsanvändare behöver kunna adressera fält via en synlig, korrekt etikett — om etiketten är fel eller saknas sitter de fast

Inget av detta sker automatiskt. Du måste bygga det.

WCAG-kriterierna som gäller

Fyra framgångskriterier i WCAG 2.2 täcker felhantering direkt:

3.3.1 Identifiering av fel (nivå A) — Om ett fel upptäcks automatiskt ska det felaktiga objektet identifieras och beskrivas för användaren i text. Du får inte förmedla fel genom enbart färg.

3.3.2 Etiketter eller instruktioner (nivå A) — Fält som kräver ett visst format måste göra kravet tydligt före eller under inmatningen, inte först efter att inskickningen misslyckats.

3.3.3 Förslag vid fel (nivå AA) — Om ett fel upptäcks och förslag på korrigering är kända, tillhandahåll dem. “Ogiltigt datum” räcker inte. “Ange datumet i formatet DD/MM/ÅÅÅÅ” gör det.

3.3.4 Förebyggande av fel (nivå AA) — För inskickningar med betydande konsekvenser (finansiella transaktioner, juridiska avtal) ska användare kunna granska, korrigera och bekräfta innan åtgärden blir permanent.

Det finns också 4.1.3 Statusmeddelanden (nivå AA), som täcker dynamiskt inskjutna meddelanden som inte får fokus — dessa måste läsas upp av hjälpmedelsteknik med hjälp av role="status" eller role="alert".

Vad ett tillgängligt felmeddelande faktiskt kräver

Att få felmeddelanden rätt kräver uppmärksamhet på fyra separata lager:

1. Den programmatiska kopplingen

Varje felmeddelande måste knytas till sitt fält med aria-describedby. Det talar om för skärmläsare att felttexten ska läsas upp när fältet får 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>

Attributet aria-invalid="true" signalerar att fältet just nu är ogiltigt, vilket de flesta skärmläsare läser upp när fokus hamnar på det.

2. Fokushantering efter inskickning

När ett formulär skickas in och fel finns måste fokus flyttas någonstans användbart. De två vanligaste mönstren:

Flytta fokus till en felsammanfattning överst i formuläret som listar alla fel med länkar till de berörda fälten
Flytta fokus till det första fältet med fel

Om fokus stannar på skicka-knappen eller ingenstans alls måste skärmläsaranvändare själva upptäcka felen genom att navigera genom formuläret — om de ens vet att fel finns.

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

3. Live-regioner för dynamiska fel

För fel som visas medan användaren skriver (validering i realtid), använd ARIA live-regioner så att meddelandet läses upp utan att fokus behöver flyttas.

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

Använd role="alert" / aria-live="assertive" för fel som kräver omedelbar uppmärksamhet. Använd role="status" / aria-live="polite" för mindre brådskande återkoppling som kan vänta tills användaren gör en paus.

4. Själva felmeddelandet

Språket spelar roll. Tillgängliga felmeddelanden är:

Specifika: säg vad som är fel, inte bara att något är fel
Handlingsbara: tala om för användaren exakt vad hen ska göra för att åtgärda det
Artiga: undvik anklagande formuleringar som “du angav ett ogiltigt värde”

Otillgängligt	Tillgängligt
”Ogiltig inmatning"	"E-postadressen måste innehålla ett @-tecken, t.ex. namn@exempel.se"
"Fel"	"Datumet måste anges i formatet DD/MM/ÅÅÅÅ"
"Obligatoriskt fält"	"Fullständigt namn måste anges"
"Ogiltigt lösenord"	"Lösenordet måste vara minst 8 tecken och innehålla en siffra”

Mönster för olika felscenarier

Fel vid enskilda fält

Det vanligaste mönstret. Ett felmeddelande visas direkt under det tillhörande fältet. Fungerar bra för enkla formulär. Kräver aria-describedby och aria-invalid för att läsas upp korrekt.

Felsammanfattningar

För långa formulär med flera fel, placera en sammanfattning överst som listar alla problem som länkar till respektive fält. Flytta fokus hit efter en misslyckad inskickning. Detta är mönstret som GOV.UK använder och det rekommenderas brett för komplexa formulär.

Toast-notiser

Kortlivade meddelanden som visas i skärmens kant hör till de mest otillgängliga mönstren i vanligt bruk. De försvinner innan skärmläsaranvändare hinner nå dem, de läses ofta inte upp alls, och de erbjuder ingen väg till åtgärd. Undvik att använda toast-notiser för fel. Om du ändå använder dem, kombinera dem med ett beständigt feltillstånd i själva formuläret.

Systemfel

När något går fel på serversidan, berätta för användaren på klarspråk vad som hände och vad hen kan göra härnäst. “Något gick fel” utan vidare vägledning lämnar användare strandade.

<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>

Checklistan för testning

När felhanteringen är implementerad, verifiera följande manuellt — automatiserade verktyg fångar inte de flesta av punkterna:

Att skicka in ett tomt obligatoriskt formulär flyttar fokus till en felsammanfattning eller det första fältet med fel
Varje felmeddelande är kopplat till sitt fält via aria-describedby
Fält med fel har aria-invalid="true"
Felmeddelanden läses upp när fokus hamnar på det berörda fältet
Validering i realtid använder live-regioner
Felmeddelanden använder specifikt, handlingsbart språk — inte bara “ogiltigt”
Färg är inte det enda sättet fel indikeras på (ikon eller textetikett vid sidan av det röda)
Felet går att nå via tabbning från tangentbordet
Fokusordningen efter inskickning är logisk och hoppar inte oförutsägbart
Toast-meddelanden kombineras med ett beständigt feltillstånd

Varför automatiserade verktyg missar det mesta av detta

En automatiserad skanner kan kontrollera om aria-describedby pekar på ett befintligt element och om aria-invalid finns. Den kan inte kontrollera om fokus flyttas korrekt efter inskickning, om felttexten är korrekt eller om en toast-notis försvinner innan den hinner läsas. Våra manuella tillgänglighetsgranskningar omfattar formulärspecifik testning med verklig hjälpmedelsteknik — det enda tillförlitliga sättet att verifiera att felhanteringen faktiskt fungerar hela vägen.

Om du är osäker på hur dina formulär står sig, kör en gratis skanning för att först fånga de problem som kan upptäckas automatiskt, och gå vidare därifrån.