Foutmeldingen in formulieren die mensen echt helpen

Neem drie varianten van dezelfde melding. “Ongeldige invoer.” “Het veld telefoonnummer is niet correct.” “Vul uw telefoonnummer in met tien cijfers, bijvoorbeeld 0612345678.” Alle drie zeggen dat er iets mis is. Alleen de laatste helpt de bezoeker om het op te lossen. Voeg daar een screenreadergebruiker aan toe die de rode tekst niet ziet, of iemand die ingezoomd is en de melding bovenaan de pagina mist, en u begrijpt waarom een goede foutmelding in een formulier meer is dan een rood zinnetje. Hieronder stap voor stap hoe u ze opbouwt.

Wat WCAG vraagt van foutmeldingen

Drie criteria gaan direct over fouten in formulieren:

Daarnaast speelt 1.4.1 mee: een fout mag niet alleen met kleur worden aangegeven. Een rode rand zonder tekst is dus niet genoeg. Meer daarover leest u in kleur mag niet het enige signaal zijn.

Stap 1: schrijf een melding die het probleem oplost

Een goede foutmelding beantwoordt twee vragen: wat is er mis, en wat moet ik doen?

• Noem het veld. “E-mailadres” in plaats van “Dit veld”.
• Zeg wat er mis is, in gewone taal. “Het e-mailadres mist een @” in plaats van “Ongeldig formaat”.
• Geef het goede voorbeeld. “Bijvoorbeeld naam@voorbeeld.nl.”
• Geen schuld. “U heeft een fout gemaakt” klinkt verwijtend. “Vul een postcode in, zoals 1234 AB” is neutraal.
• Kort. Eén of twee zinnen.

Een paar voorbeelden:

Stap 2: zet de melding bij het veld

Een foutmelding hoort direct bij het veld waar het om gaat, meestal er net onder of erboven. Dan ziet de bezoeker hem op de plek waar hij aan het werk is, ook als hij ingezoomd is.

Koppel de melding in de code aan het veld met aria-describedby, en markeer het veld als ongeldig met aria-invalid. Een screenreader leest dan bij het veld de melding mee voor.

<label for="postcode">Postcode</label>
<input id="postcode" name="postcode" type="text"
       autocomplete="postal-code"
       aria-invalid="true"
       aria-describedby="postcode-fout">
<p id="postcode-fout" class="veldfout">
  Fout: vul een postcode in met vier cijfers en twee letters, zoals 1234 AB.
</p>

Het woord “Fout:” aan het begin is een kleine moeite. Het maakt voor iedereen duidelijk dat dit een foutmelding is, ook voor wie de kleur niet ziet. Een icoon ervoor kan ook, mits het icoon voor screenreaders verborgen is en de tekst blijft staan.

Zodra de bezoeker het veld goed invult, haalt u de melding weg en zet u aria-invalid op false of verwijdert u het.

Stap 3: zorg dat de bezoeker de fouten vindt

Na het verzenden van een formulier met fouten moet de bezoeker weten dat er iets mis is en waar. Bij een kort formulier, met een paar velden, is het genoeg om de focus naar het eerste foute veld te zetten. De screenreader leest dan het label en de melding voor.

Bij een langer formulier werkt een foutoverzicht bovenaan beter:

<div role="alert" tabindex="-1" id="foutoverzicht">
  <h2>Er zijn 2 fouten in het formulier</h2>
  <ul>
    <li><a href="#postcode">Postcode: vul een geldige postcode in</a></li>
    <li><a href="#telefoon">Telefoonnummer: vul tien cijfers in</a></li>
  </ul>
</div>

Zet na het verzenden de focus op dit overzicht. Elke link brengt de bezoeker direct naar het betreffende veld. De meldingen bij de velden zelf blijven ook staan. Zo werkt het voor iedereen: wie ziet, ziet het overzicht; wie een screenreader gebruikt, hoort het; wie met het toetsenbord werkt, springt met één klik naar het veld.

Wordt het formulier zonder herladen verwerkt, dan moet ook een bevestiging of foutmelding die op de pagina verschijnt, worden voorgelezen. Dat heet een statusbericht, en het werkt net iets anders. Zie statusberichten die een screenreader ook meldt.

Stap 4: voorkom fouten waar dat kan

De beste foutmelding is de melding die niet nodig is. Een paar manieren om fouten te voorkomen:

• Zeg vooraf welk formaat u verwacht. Zet een voorbeeld bij het label, niet alleen als placeholder in het veld.
• Wees ruimhartig in wat u accepteert. Een telefoonnummer met spaties, streepjes of +31? Accepteer het en maak het zelf netjes. Een postcode zonder spatie of met kleine letters? Ook prima.
• Geef aan welke velden verplicht zijn, op een manier die iedereen begrijpt. Hoe dat werkt, leest u in verplichte velden aangeven zonder alleen een sterretje.
• Valideer niet te vroeg. Een foutmelding die al verschijnt terwijl iemand nog typt, is irritant en voor screenreadergebruikers verwarrend. Controleer pas als de bezoeker het veld verlaat of op verzenden drukt.
• Bewaar wat goed was. Laat na een fout alle correct ingevulde velden staan. Niemand wil een formulier opnieuw invullen.

Formulierplugins in WordPress

Contact Form 7, Gravity Forms, WPForms en vergelijkbare plugins hebben elk een eigen manier van foutmeldingen tonen. Sommige koppelen de melding netjes aan het veld en zetten de focus goed, andere tonen alleen een algemene melding bovenaan of een rode rand. Vaak kunt u de teksten van de meldingen aanpassen in de instellingen of per veld, en dat is al een mooie eerste stap: vervang “Dit veld is verplicht” door iets specifiekers.

Test daarna zelf: verstuur het formulier leeg, met de Tab-toets en zonder muis, en luister met een screenreader wat er gebeurt. Hoort u welk veld fout is en wat u moet doen? Een uitgebreider overzicht van wat een formulier toegankelijk maakt, staat op toegankelijke formulieren op uw website. Hoe formulieren passen in de rest van een toegankelijke site, vindt u op website toegankelijk maken.