Bezoekers die een formulier invullen krijgen bij een fout een suggestie hoe ze het veld goed kunnen invullen, als de website weet wat het verwachte antwoord is. Zo begrijpt iedereen direct wat er nodig is om verder te gaan, zonder te hoeven gokken.

Als een formulier weet welk antwoord het verwacht, biedt het bij een fout een suggestie aan. Vult iemand “32 januari” in als datum? Dan meldt het formulier niet alleen “Datum is niet geldig” maar stelt het voor: “Bedoelde je 31 januari of 1 februari?”

Hoe specifieker de suggestie, hoe sneller de bezoeker het formulier correct kan invullen. Bij een wachtwoordveld mag je suggereren welke eis niet is gehaald, zolang je geen gevoelige informatie over geldige wachtwoorden onthult. Vermelden dat een wachtwoord minimaal een bepaald aantal tekens moet hebben mag, want die informatie staat ook op het aanmeldformulier.

Veelgemaakte fouten

Foutmelding zonder suggestie terwijl het verwachte formaat bekend is

Het formulier weet welk formaat het verwacht, maar deelt dat niet met de bezoeker. Een datumveld verwacht “dd-mm-jjjj” maar meldt alleen “Ongeldige datum”. Een telefoonnummerveld verwacht tien cijfers maar meldt alleen “Ongeldig telefoonnummer”. De bezoeker moet raden wat er precies wordt verwacht.

Hoe te testen: vul een veld in met een waarde in het verkeerde formaat. Beschrijft de foutmelding welk formaat wordt verwacht? Bevat de melding een voorbeeld?

<label for="datum">Geboortedatum</label>
<input type="text" id="datum" aria-describedby="datum-fout" aria-invalid="true" />
<p id="datum-fout" class="fout">
  Ongeldige datum
</p>

<label for="datum">Geboortedatum</label>
<input type="text" id="datum" aria-describedby="datum-fout" aria-invalid="true" />
<p id="datum-fout" class="fout">
  Datum is niet in het juiste formaat. Gebruik dd-mm-jjjj, bijvoorbeeld 15-03-1990
</p>

Wie kan dit oplossen: een developer voegt het verwachte formaat en een voorbeeld toe aan de foutmelding.

Postcode wordt afgekeurd omdat het formaat afwijkt

Een Nederlandse postcode bestaat uit vier cijfers en twee letters. Bezoekers schrijven die op twee manieren: “3512JE” en “3512 JE”. Als het formulier alleen het formaat zonder spatie accepteert, krijgt de bezoeker een foutmelding terwijl de postcode correct is. Accepteer beide varianten, of bied een suggestie aan met het verwachte formaat.

Hoe te testen: vul een postcode in met en zonder spatie. Worden beide geaccepteerd? Als niet, biedt de foutmelding dan het verwachte formaat aan?

<label for="postcode">Postcode</label>
<input type="text" id="postcode" value="3512 JE" aria-describedby="postcode-fout" aria-invalid="true" />
<p id="postcode-fout" class="fout">
  Ongeldige postcode
</p>

function normaliseerPostcode(waarde) {
  return waarde.replace(/\s/g, "").toUpperCase();
}

<label for="postcode">Postcode</label>
<input type="text" id="postcode" value="3512 JE" aria-describedby="postcode-fout" aria-invalid="true" />
<p id="postcode-fout" class="fout">
  Postcode is niet in het juiste formaat. Gebruik het formaat zonder spatie, bijvoorbeeld 3512JE
</p>

Wie kan dit oplossen: een developer normaliseert de invoer zodat beide schrijfwijzen worden geaccepteerd, of voegt het verwachte formaat toe aan het label boven het veld en de foutmelding.

Datum buiten bereik zonder te melden welke datums geldig zijn

Een datumveld accepteert alleen datums binnen een bepaald bereik, maar meldt niet welk bereik geldig is. De bezoeker vult een datum in die te ver in het verleden of in de toekomst ligt en krijgt alleen “Datum buiten bereik”. Vermeld de grenzen zodat de bezoeker direct de juiste datum kan kiezen.

Hoe te testen: vul een datum in die buiten het geldige bereik valt. Vermeldt de foutmelding het geldige bereik?

<label for="afspraak">Datum afspraak</label>
<input type="date" id="afspraak" aria-describedby="afspraak-fout" aria-invalid="true" />
<p id="afspraak-fout" class="fout">
  Datum buiten bereik
</p>

<label for="afspraak">Datum afspraak</label>
<input type="date" id="afspraak" aria-describedby="afspraak-fout" aria-invalid="true" />
<p id="afspraak-fout" class="fout">
  Kies een datum tussen 1 april 2026 en 30 juni 2026
</p>

Wie kan dit oplossen: een developer voegt de grenzen van het geldige bereik toe aan de foutmelding.

Verplicht veld met alleen de melding “Dit veld is verplicht”

“Dit veld is verplicht” beschrijft een regel, geen oplossing. De bezoeker weet dat er iets moet worden ingevuld, maar niet wat. Bij een naamveld is “Vul je voor- en achternaam in” direct bruikbaar. Bij een selectie is “Kies een bezorgmethode” concreter dan “Dit veld is verplicht”.

Hoe te testen: laat een verplicht veld leeg en verstuur het formulier. Beschrijft de foutmelding wat je moet invullen, of zegt het alleen dat het veld verplicht is?

<label for="naam">Naam</label>
<input type="text" id="naam" aria-describedby="naam-fout" aria-invalid="true" />
<p id="naam-fout" class="fout">
  Dit veld is verplicht
</p>

<label for="naam">Naam</label>
<input type="text" id="naam" aria-describedby="naam-fout" aria-invalid="true" />
<p id="naam-fout" class="fout">
  Vul je voor- en achternaam in
</p>

Wie kan dit oplossen: een developer of contentbeheerder schrijft per veld een specifieke foutmelding die beschrijft wat er verwacht wordt.

Wachtwoord voldoet niet aan de eisen maar de melding zegt niet welke eis niet is gehaald

Een wachtwoordveld heeft meerdere eisen: minimale lengte, een hoofdletter, een cijfer. De foutmelding zegt alleen “Wachtwoord voldoet niet aan de eisen” zonder te specificeren welke eis niet is gehaald. De bezoeker moet alle eisen opnieuw doorlopen.

Hoe te testen: vul een wachtwoord in dat aan sommige eisen voldoet maar niet aan alle. Specificeert de foutmelding welke eis niet is gehaald?

<label for="wachtwoord">Wachtwoord</label>
<input type="password" id="wachtwoord" aria-describedby="ww-fout" aria-invalid="true" />
<p id="ww-fout" class="fout">
  Wachtwoord voldoet niet aan de eisen
</p>

<label for="wachtwoord">Wachtwoord</label>
<input type="password" id="wachtwoord" aria-describedby="ww-fout" aria-invalid="true" />
<ul id="ww-fout" class="fout">
  <li>Minimaal 8 tekens (je hebt er nu 5)</li>
  <li>Minimaal één cijfer</li>
</ul>

Noem in de foutmelding niet welke tekens wél correct zijn — dat onthult informatie over het wachtwoord.

Wie kan dit oplossen: een developer splitst de validatie op in afzonderlijke controles en toont per eis of die is gehaald.

Hoe te testen

Voor iedereen

1. Vul een formulier in met waarden in een verkeerd formaat (datum, telefoonnummer, postcode). Biedt de foutmelding het verwachte formaat en een voorbeeld?
2. Typ een waarde met een kleine typefout in een zoekveld of keuzelijst. Biedt het formulier een alternatief aan?
3. Vul een datum in buiten het geldige bereik. Vermeldt de foutmelding welke datums geldig zijn?
4. Controleer wachtwoordvelden. Geeft de foutmelding aan welke specifieke eis niet is gehaald?

Voor developers

1. Controleer elke foutmelding in het formulier. Bevat de melding een suggestie of voorbeeld als het verwachte formaat of de geldige opties bekend zijn?
2. Test met een screenreader. Worden suggesties voorgelezen samen met de foutmelding? Zijn klikbare suggesties bereikbaar met het toetsenbord?
3. Controleer dat suggesties bij wachtwoordvelden geen informatie onthullen die de beveiliging ondermijnt.
4. Gebruik axe DevTools voor een eerste scan. Foutsuggesties zijn niet automatisch te herkennen — dit vereist handmatig testen.

Gerelateerde succescriteria

• 3.3.1 Foutidentificatie: het formulier meldt welk veld fout is en wat er mis is. Foutsuggestie bouwt hierop voort door ook een oplossing aan te bieden.
• 3.3.2 Labels of instructies: duidelijke labels en instructies bij invoervelden voorkomen fouten voordat ze ontstaan. Lees hier meer als je het verwachte formaat al bij het label wilt tonen.
• 3.3.4 Foutpreventie: bij juridische of financiële transacties kan de bezoeker invoer controleren en corrigeren voordat deze definitief wordt verzonden.

Relevante bronnen

• WCAG 2.2: Succescriterium 3.3.3 Foutsuggestie — de officiële Nederlandstalige vertaling van het succescriterium. Gebruik dit als referentie voor de exacte eisen.
• Understanding SC 3.3.3: Error Suggestion — de W3C-uitleg bij het succescriterium, met technieken en voorbeelden (Engels).
• Accessible form validation — uitgebreide gids van Smashing Magazine over toegankelijke formuliervalidatie, inclusief patronen voor foutsuggesties (Engels).

Gerelateerde NL Design System-richtlijnen

• Formulieren: Foutmeldingen.
• Formulieren: Descriptions.

Bronnen

Op GOV.UK:

• Error Message.
• Be clear and concise.
• Wiki 3.3.3 Error Suggestion.

Overige bronnen:

• Toegankelijke foutmeldingen in formulieren, op het blog van het NL Design System.
• Error-Message Guidelines van de Nielsen Norman Group.

Gebruikersonderzoek

• Contactformulier voor WMEBV.
• Onderzoek online meldingen.

Heb je gebruikersonderzoek gedaan dat betrekking heeft op dit succescriterium en wil je dit delen? Kijk eens bij Gebruikersonderzoeken delen op gebruikersonderzoeken.nl.

W3C referenties

• Engelse tekst van het WCAG-succescriterium: 3.3.3 Error Suggestion.
• Nederlandse vertaling van het WCAG-succescriterium: 3.3.3 Foutsuggestie.
• Engelstalige informatie op How to Meet WCAG: Quick Reference 3.3.3 Error Suggestion.
• Engelstalige toelichting: Understanding SC 3.3.3 Error Suggestion.

Help richtlijn verbeteren

Aanvullingen of opmerkingen?

Deze pagina’s over WCAG worden onderhouden door NL Design System. Heb je aanvullingen of opmerkingen? Deel je mening op GitHub.