Een bezoeker die een formulier invult, kan een fout maken. Het formulier geeft aan welk veld de fout bevat en beschrijft in tekst wat er mis is. Zo kan de bezoeker de fout vinden en corrigeren.

Foutmeldingen verschijnen op het moment dat de fout wordt herkend: na het verzenden van het formulier of direct bij het verlaten van een veld. De melding staat bij het veld waar de fout zit, niet alleen in een samenvatting bovenaan de pagina. Een screenreader leest de foutmelding voor in samenhang met het veld, zodat de bezoeker weet welk veld aandacht nodig heeft.

Een rode rand of een icoon alleen is niet voldoende. De foutmelding moet in tekst beschrijven wat er mis is, zodat iedereen de fout kan begrijpen en corrigeren.

Veelgemaakte fouten

Foutmelding beschrijft niet wat er mis is

Een foutmelding bij een invoerveld beschrijft wat er mis is en hoe de bezoeker het kan corrigeren. Een generieke melding als “Dit veld is verplicht” of “Ongeldige invoer” zegt niet wat er wordt verwacht. Bij een e-mailveld is “Geen geldig e-mailadres ingevoerd” direct bruikbaar.

Hoe te testen: vul een formulier bewust fout in en verstuur het. Beschrijft elke foutmelding concreet wat er mis is? Weet je na het lezen van de melding hoe je de fout kunt oplossen?

<label for="email">E-mailadres</label>
<input type="email" id="email" aria-describedby="email-fout" />
<p id="email-fout" class="fout">
  Ongeldige invoer
</p>

<label for="email">E-mailadres</label>
<input type="email" id="email" aria-describedby="email-fout" aria-invalid="true" />
<p id="email-fout" class="fout">
  E-mailadres is niet geldig. Gebruik het format naam@voorbeeld.nl
</p>

Wie kan dit oplossen: een developer schrijft specifieke foutmeldingen per validatieregel. Een contentbeheerder levert de teksten aan.

Foutmelding is niet gekoppeld aan het invoerveld

Een foutmelding staat visueel bij het juiste veld, maar is er in de code niet aan gekoppeld. Een screenreader leest de foutmelding dan niet voor wanneer de bezoeker naar het veld navigeert. De bezoeker hoort alleen het label en weet niet dat er een fout is.

Hoe te testen: navigeer met een screenreader naar een veld met een fout. Wordt de foutmelding voorgelezen samen met het label? Inspecteer het veld in de DevTools: heeft het een aria-describedby dat verwijst naar de foutmelding?

<label for="postcode">Postcode</label>
<input type="text" id="postcode" />
<p class="fout">Postcode is niet geldig. Gebruik het format 1234 AB</p>

<label for="postcode">Postcode</label>
<input type="text" id="postcode" aria-describedby="postcode-fout" aria-invalid="true" />
<p id="postcode-fout" class="fout">
  Postcode is niet geldig. Gebruik het format 1234 AB
</p>

Wie kan dit oplossen: een developer koppelt de foutmelding aan het veld met aria-describedby en markeert het veld met aria-invalid="true".

Fout is alleen aangegeven met kleur

Een invoerveld met een fout heeft alleen een rode rand of een rood label. Iemand die kleuren niet kan onderscheiden, ziet geen verschil tussen een veld met en zonder fout. Combineer kleur altijd met een tekst en bij voorkeur een icoon.

Hoe te testen: controleer of de foutmelding in tekst is gegeven. Bekijk het formulier in grijswaarden (gebruik de DevTools-optie “Emulate vision deficiencies” > “Achromatopsia”). Kun je nog zien welke velden een fout bevatten?

input.fout {
  border-color: red;
}

<label for="naam">Naam</label>
<input type="text" id="naam" class="fout" aria-describedby="naam-fout" aria-invalid="true" />
<p id="naam-fout" class="fout">
  <svg aria-hidden="true" class="fout-icoon"><!-- waarschuwingsicoon --></svg>
  Naam is niet ingevuld
</p>

Wie kan dit oplossen: een developer voegt een tekstuele foutmelding toe naast de kleurverandering.

Foutmeldingen verschijnen alleen bovenaan de pagina

Na het verzenden van een formulier verschijnt een samenvatting van fouten bovenaan de pagina, maar bij de velden zelf staat niets. De bezoeker moet heen en weer scrollen tussen de samenvatting en de velden om te begrijpen wat er mis is. Bij lange formulieren is dat onwerkbaar.

Hoe te testen: verstuur een formulier met meerdere fouten. Staan de foutmeldingen ook bij de individuele velden? Of moet je scrollen naar een samenvatting bovenaan?

<div class="fout-samenvatting">
  <p>Er zijn 3 fouten gevonden:</p>
  <ul>
    <li>Naam is verplicht</li>
    <li>E-mailadres is ongeldig</li>
    <li>Postcode is verplicht</li>
  </ul>
</div>
<!-- Velden verderop zonder foutmeldingen -->
<label for="naam">Naam</label>
<input type="text" id="naam" />

<div class="fout-samenvatting" role="alert">
  <p>Er zijn 3 fouten gevonden:</p>
  <ul>
    <li><a href="#naam">Naam is niet ingevuld</a></li>
    <li><a href="#email">E-mailadres is niet ingevuld</a></li>
    <li><a href="#postcode">Postcode is niet ingevuld</a></li>
  </ul>
</div>
<!-- Foutmelding ook bij het veld zelf -->
<label for="naam">Naam</label>
<input type="text" id="naam" aria-describedby="naam-fout" aria-invalid="true" />
<p id="naam-fout" class="fout">Naam is niet ingevuld</p>

De links in de samenvatting verwijzen naar de velden, zodat de bezoeker direct naar het juiste veld kan springen.

Wie kan dit oplossen: een developer voegt foutmeldingen toe bij de individuele velden en maakt de samenvatting klikbaar.

Inline validatie markeert een veld als fout terwijl de bezoeker nog bezig is

Inline validatie controleert een veld terwijl de bezoeker nog aan het typen is. Na het eerste karakter van een e-mailadres verschijnt al een foutmelding dat het adres ongeldig is. Dat is verwarrend en frustrerend. Valideer pas nadat de bezoeker het veld heeft verlaten of het formulier heeft verzonden.

Hoe te testen: begin met het invullen van een veld. Verschijnt er al een foutmelding terwijl je nog aan het typen bent?

emailVeld.addEventListener("input", () => {
  valideerEmail(emailVeld.value);
});

emailVeld.addEventListener("blur", () => {
  valideerEmail(emailVeld.value);
});

Wie kan dit oplossen: een developer wijzigt de validatietrigger van input naar blur of submit.

Hoe te testen

Voor iedereen

1. Verstuur een formulier met bewust lege of fout ingevulde velden. Verschijnt er bij elk veld met een fout een foutmelding?
2. Lees de foutmeldingen. Beschrijven ze concreet wat er mis is en in welk invoerveld?

Voor developers

1. Inspecteer velden met fouten in de DevTools. Heeft elk veld met een fout een aria-invalid="true" en een aria-describedby dat verwijst naar de foutmelding?
2. Test met een screenreader. Navigeer naar een veld met een fout. Wordt de foutmelding voorgelezen samen met het label?
3. Controleer of inline validatie niet triggert terwijl de bezoeker nog aan het typen is.
4. Als er een foutsamenvatting bovenaan staat: controleer of de links naar de individuele velden verwijzen en of de focus naar de samenvatting verplaatst na het verzenden.

Gerelateerde succescriteria

• 3.3.2 Labels of instructies: duidelijke labels en instructies voorkomen fouten. Lees hier meer als velden onduidelijk zijn gelabeld en bezoekers daardoor fouten maken.
• 3.3.3 Foutsuggestie: als het systeem weet hoe de fout gecorrigeerd kan worden, biedt het een suggestie aan. Lees hier meer als je naast foutidentificatie ook automatische correctiesuggesties wilt bieden.
• 1.4.1 Gebruik van kleur: informatie mag niet alleen door kleur worden overgebracht. Relevant als foutmeldingen alleen met een rode rand worden aangegeven.
• 4.1.3 Statusberichten: statusberichten die niet de focus krijgen, worden via ARIA aan screenreaders gemeld. Relevant voor foutsamenvattingen en inline foutmeldingen die verschijnen na het verzenden.

Gerelateerde NL Design System-richtlijnen

• Formulieren: Foutmeldingen.
• Formulieren: Descriptions.

Relevante bronnen

• Accessible form validation — uitgebreide gids over toegankelijke formuliervalidatie, met patronen voor foutmeldingen en ARIA-gebruik (Smashing Magazine, Engels).
• Toegankelijke foutmeldingen in formulieren — blogpost van NL Design System over foutmeldingen in formulieren.
• The problem with live validation and what to do instead — waarom inline validatie tijdens het typen problematisch is (Adam Silver, Engels).
• Avoid Default Field Validation — waarom standaard browservalidatie niet voldoende is (Adrian Roselli, Engels).
• Error Message — het foutmeldingspatroon van GOV.UK, met richtlijnen voor duidelijke teksten (Engels).
• Error summary — het foutsamenvatting-patroon van GOV.UK (Engels).

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

• WCAG 2.2: Succescriterium 3.3.1 Foutidentificatie — de officiële Nederlandstalige vertaling van het succescriterium.
• Understanding SC 3.3.1: Error Identification — de W3C-uitleg bij het succescriterium, met technieken en voorbeelden (Engels).
• Quick Reference 3.3.1 Error Identification — snelreferentie met technieken (Engels).

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.