Wanneer je foutmeldingen gebruikers buitensluiten

Het moment waarop het formulier stukloopt

Stel je voor: een blinde gebruiker vult een afrekenformulier in, verstuurt het en hoort niets bruikbaars van zijn schermlezer. Geen melding. Geen uitleg. De pagina heeft visueel vijf validatiefouten in het rood gemarkeerd, maar de gebruiker heeft geen idee. Hij klikt opnieuw op versturen. En nog eens. Uiteindelijk haakt hij af.

Dit is geen randgeval. Ontoegankelijke foutafhandeling is een van de meest voorkomende barrières die we in echte audits tegenkomen, en het is er een die gebruikers frustreert op het slechtst denkbare moment — wanneer ze een transactie proberen af te ronden of iets belangrijks willen versturen.

Het goede nieuws is dat het oplossen ervan vooral een kwestie is van weten hoe “goed” eruitziet. De fouten volgen bijna altijd dezelfde paar patronen.

Waarom foutmeldingen lastig zijn voor gebruikers van hulptechnologie

Ziende muisgebruikers merken validatiefouten meestal direct op — de rode rand, het waarschuwingspictogram, de tekst die onder het veld verschijnt. Maar gebruikers die afhankelijk zijn van schermlezers, toetsenbordnavigatie of spraakbesturing hebben een fundamenteel andere ervaring.

Wanneer een formulier wordt verstuurd en er fouten verschijnen:

• Schermlezergebruikers horen mogelijk niets, tenzij de focus naar de fout verplaatst of een live region deze aankondigt
• Toetsenbordgebruikers moeten elke foutmelding met het toetsenbord kunnen bereiken en begrijpen bij welk veld deze hoort
• Gebruikers van spraakbesturing moeten velden kunnen aanspreken via een zichtbaar, accuraat label — als het label fout is of ontbreekt, lopen ze vast

Niets hiervan gebeurt automatisch. Je moet het bouwen.

De WCAG-criteria die van toepassing zijn

Vier succescriteria in WCAG 2.2 gaan rechtstreeks over foutafhandeling:

3.3.1 Foutidentificatie (niveau A) — Als een fout automatisch wordt gedetecteerd, wordt het foutieve item geïdentificeerd en in tekst aan de gebruiker beschreven. Je mag fouten niet alleen via kleur overbrengen.

3.3.2 Labels of instructies (niveau A) — Invoervelden die een specifiek formaat vereisen, moeten die eis duidelijk maken vóór of tijdens de invoer, niet pas nadat het versturen is mislukt.

3.3.3 Foutsuggestie (niveau AA) — Als een fout wordt gedetecteerd en er correcties bekend zijn, bied die dan aan. “Ongeldige datum” is niet genoeg. “Voer de datum in als DD/MM/JJJJ” wel.

3.3.4 Foutpreventie (niveau AA) — Voor verzendingen met belangrijke gevolgen (financiële transacties, juridische overeenkomsten) moeten gebruikers de mogelijkheid krijgen om te controleren, te corrigeren en te bevestigen voordat de actie definitief is.

Daarnaast is er 4.1.3 Statusberichten (niveau AA), dat betrekking heeft op dynamisch ingevoegde berichten die geen focus krijgen — deze moeten door hulptechnologie worden aangekondigd via role="status" of role="alert".

Wat een toegankelijke foutmelding werkelijk nodig heeft

Foutmeldingen goed doen vraagt aandacht voor vier afzonderlijke lagen:

1. De programmatische koppeling

Elke foutmelding moet aan zijn veld worden gekoppeld met aria-describedby. Dit vertelt schermlezers dat ze de fouttekst moeten voorlezen wanneer het veld de focus krijgt.

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

Het attribuut aria-invalid="true" geeft aan dat het veld op dat moment ongeldig is, wat de meeste schermlezers voorlezen zodra de focus erop landt.

2. Focusbeheer na het versturen

Wanneer een formulier wordt verstuurd en er fouten zijn, moet de focus naar een nuttige plek verplaatsen. De twee meest gangbare patronen:

• Verplaats de focus naar een foutsamenvatting bovenaan het formulier die alle fouten opsomt met links naar de betreffende velden
• Verplaats de focus naar het eerste veld met een fout

Als de focus op de verzendknop blijft staan of nergens naartoe gaat, moeten schermlezergebruikers de fouten zelf ontdekken door het formulier door te lopen — als ze überhaupt weten dat er fouten zijn.

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

3. Live region-aankondigingen voor dynamische fouten

Voor fouten die verschijnen terwijl de gebruiker typt (realtime inline validatie), gebruik je ARIA live regions zodat het bericht wordt aangekondigd zonder dat de focus hoeft te verplaatsen.

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

Gebruik role="alert" / aria-live="assertive" voor fouten die directe aandacht vereisen. Gebruik role="status" / aria-live="polite" voor minder urgente feedback die kan wachten tot de gebruiker pauzeert.

4. De foutmelding zelf

De formulering doet ertoe. Toegankelijke foutmeldingen zijn:

• Specifiek: zeg wat er mis is, niet alleen dát er iets mis is
• Uitvoerbaar: vertel de gebruiker precies wat hij moet doen om het op te lossen
• Beleefd: vermijd verwijtende taal zoals “u heeft een ongeldige waarde ingevoerd”

Ontoegankelijk	Toegankelijk
”Ongeldige invoer"	"E-mailadres moet een @-teken bevatten, bijv. naam@voorbeeld.nl"
"Fout"	"Datum moet het formaat DD/MM/JJJJ hebben"
"Verplicht veld"	"Volledige naam is verplicht"
"Wachtwoord ongeldig"	"Wachtwoord moet minimaal 8 tekens lang zijn en één cijfer bevatten”

Patronen voor verschillende foutscenario’s

Inline veldfouten

Het meest voorkomende patroon. Een foutmelding verschijnt direct onder het bijbehorende veld. Werkt goed voor eenvoudige formulieren. Vereist aria-describedby en aria-invalid om correct te worden voorgelezen.

Foutsamenvattingsbanners

Plaats bij lange formulieren met meerdere fouten een samenvatting bovenaan die alle problemen opsomt als links die naar het betreffende veld springen. Verplaats de focus hierheen na een mislukte verzending. Dit is het patroon dat GOV.UK gebruikt en dat breed wordt aanbevolen voor complexe formulieren.

Toastmeldingen

Kortstondige berichten die aan de rand van het scherm verschijnen, behoren tot de meest ontoegankelijke patronen in algemeen gebruik. Ze verdwijnen voordat schermlezergebruikers ze kunnen bereiken, ze worden vaak helemaal niet aangekondigd en ze bieden geen herstelmogelijkheid. Vermijd toasts voor fouten. Als je ze toch gebruikt, combineer ze dan met een blijvende foutstatus op het formulier zelf.

Systeemfouten

Wanneer er aan de serverkant iets misgaat, vertel de gebruiker dan in gewone taal wat er is gebeurd en wat hij vervolgens kan doen. “Er is iets misgegaan” zonder verdere uitleg laat gebruikers stranden.

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

De testchecklist

Controleer na het implementeren van foutafhandeling het volgende handmatig — geautomatiseerde tools vangen het merendeel niet op:

• Het versturen van een leeg verplicht formulier verplaatst de focus naar een foutsamenvatting of het eerste veld met een fout
• Elke foutmelding is via aria-describedby aan zijn veld gekoppeld
• Velden met een fout hebben aria-invalid="true"
• Foutmeldingen worden voorgelezen wanneer de focus op het betreffende veld landt
• Realtime validatie gebruikt live regions
• Foutmeldingen gebruiken specifieke, uitvoerbare taal — niet alleen “ongeldig”
• Kleur is niet de enige manier waarop fouten worden aangegeven (een pictogram of tekstlabel naast het rood)
• De fout is met het toetsenbord via tab te bereiken
• De focusvolgorde na het versturen is logisch en springt niet onvoorspelbaar rond
• Toastmeldingen zijn gecombineerd met een blijvende foutstatus

Waarom geautomatiseerde tools het meeste hiervan missen

Een geautomatiseerde scanner kan controleren of aria-describedby naar een bestaand element verwijst en of aria-invalid aanwezig is. Hij kan niet controleren of de focus na het versturen correct verplaatst, of de fouttekst klopt, of dat een toastmelding verdwijnt voordat deze gelezen kan worden. Onze handmatige toegankelijkheidsaudits omvatten formulierspecifieke tests met echte hulptechnologie — de enige betrouwbare manier om te verifiëren dat foutafhandeling van begin tot eind echt werkt.

Weet je niet zeker hoe je formulieren ervoor staan? Start een gratis scan om eerst de automatisch detecteerbare problemen bloot te leggen, en ga van daaruit verder.