Ga naar hoofdinhoud

Formulieren

Foutmeldingen in een formulier

Formuliervalidatie werkt het best met duidelijke en goed getimede foutmeldingen en logische validatieregels. Als een veld niet goed is ingevuld, moet voor iedereen duidelijk zijn wat er niet klopt. Hoe help je de gebruiker het beste als deze onjuiste of onvolledige informatie invult?

Belangrijk bij het aangeven van fouten:

  • Controleer op het juiste moment op fouten.
  • Schrijf een foutmelding uit in tekst.
  • Schrijf een duidelijke foutmelding.
  • Zet de foutmeldingen bij de betreffende formuliervelden.
  • Gebruik geen HTML-formuliervalidatie.
  • Zet een samenvatting van de foutmeldingen boven het formulier.
  • Geef feedback aan screenreadergebruikers.

Controleer op het juiste moment op fouten

Het is van belang wanneer een veld op fouten wordt gecheckt.

Stel, je typt een e-mailadres en na het invoeren van het eerste karakter verschijnt al een foutmelding "Ongeldig e-mailadres".

Die melding verdwijnt pas als het hele e-mailadres is ingevuld. Dit is niet alleen irritant, het kan ook onzekerheid en verwarring veroorzaken. “Wat doe ik fout? Ik ben nog niet klaar met invullen en het is nu al fout!”

Controleer een veld bijvoorbeeld als de gebruiker het veld heeft aangepast en daarna verlaat ('blur' en 'input') of wanneer het formulier wordt verzonden.

Meer informatie over de bezwaren van "live" validatie: The problem with live validation and what to do instead van Adam Silver.

Schrijf een foutmelding uit in tekst

Schrijf de foutmelding altijd uit in tekst. Dus niet alleen met een rood randje om het veld heen of met een icoontje van een uitroepteken, maar in duidelijke taal.

Je kunt zeker kleur en icoontjes gebruiken, maar niet als enige foutindicatie.

Formulierfouten in tekst beschrijven is nodig om te voldoen aan het WCAG-succescriterium 3.3.1 Foutidentificatie (niveau A).

Doen

Naast een visuele indicatie ook een foutmelding in tekst tonen.

In dit voorbeeld staat er een rood randje om het invoerveld heen, plus de foutmelding in tekst.

Invoerfout: Vul een geldige datum in (bijvoorbeeld 6 januari 2030).

Niet doen

Alleen een visuele indicatie geven dat er iets fout is gegaan.

In dit voorbeeld staat er alleen een rood randje om het invoerveld heen.

Schrijf een duidelijke foutmelding

"Dit veld is verplicht" geeft onvoldoende informatie. Een op maat geschreven foutmelding geeft de gebruiker veel meer houvast.

Geef de gebruiker ook nooit de schuld. De meeste mensen worstelen met alle informatie en functionaliteit op het web. Help gebruikers zo goed mogelijk om het formulier te versturen.

Maak foutmeldingen daarom zo veel mogelijk beschrijvend en op maat. Schrijf in plaats van "Ongeldige invoer" of "Dit veld is verplicht" bijvoorbeeld:

  • Vul een geldig e-mailadres in, bijvoorbeeld naam@voorbeeld.nl.
  • De geldigheidsdatum van uw paspoort moet in de toekomst zijn.
  • Vul het huisnummer in zodat wij je bestelling kunnen opsturen.

Gebruik een punt aan het eind van de foutmelding (of andere melding). Dan stopt de screenreader even en is het duidelijker dat de foutmelding apart een zin is.

Het design system van GOV.UK geeft duidelijke (Engelstalige) informatie over de tekst van foutmeldingen Be clear and concise.

Het schrijven van foutmeldingen en een duidelijke toelichting op wat er mis gaat, is nodig om te voldoen de volgende WCAG-succescriteria:

Doen

Leg uit waarom een datum wordt afgekeurd.

Invoerfout: De geldigheidsdatum van uw paspoort moet in de toekomst liggen.

Doen

Geef een voorbeeld van wat er verwacht wordt.

Invoerfout: Vul een geldig e-mailadres in, bijvoorbeeld naam@voorbeeld.nl.

Niet doen

Alleen beschrijven dat het veld verplicht is, zonder toelichting dat er informatie mist of aan welke voorwaarde niet is voldaan.

Invoerfout: Dit veld is verplicht.

Zet de foutmeldingen bij de betreffende formuliervelden

Voor foutmeldingen geldt hetzelfde als voor descriptions: de beste locatie is boven het formulierveld. Bovendien moet de foutmelding aria-describedby gekoppeld zijn aan het formulierveld.

Hoe dit te doen is beschreven bij de richtlijnen over descriptions.

Doen

Plaats alle descriptions, ook de foutmeldingen, op een consistente plek, liefst tussen het label en het formulierveld.

Kies een wachtwoord van minimaal 8 karakters lang.

Invoerfout: Je gekozen wachtwoord is te kort.

Niet doen

Description boven het formulierveld en foutmelding eronder plaatsen.

Kies een wachtwoord van minimaal 8 karakters lang.

Invoerfout: Je gekozen wachtwoord is te kort.

Gebruik geen HTML-formuliervalidatie

Voorbeeld van HTML-validatie, een ballonnetje boven het formulierveld met de tekst: vul dit veld in.

De meeste browsers kunnen zelf controleren of een veld is ingevuld. Dit gebeurt als het HTML-attribuut required in het formulierveld staat.

<input type="text" id="voorbeeld" name="voorbeeld" required />

Dit type foutafhandeling geeft onvoldoende informatie. In veel browsers wordt niet aan alle gebruikers overgebracht dat het veld verplicht is, en mist uitleg wanneer niet wordt voldaan een een opgegeven pattern. Zie ook: Avoid default field validation van Adrian Roselli.

Wanneer er voldoende tijd en kennis is, heeft het de voorkeur om zelf client-side validatie toe te voegen.

Om specifiek aan hulptechnologieën te communiceren dat een veld verplicht is, kan aria-required worden gebruikt. Als je alleen aria-required gebruikt, zal de browser niet zelf valideren of feedback geven.

Het toegankelijk maken van foutmeldingen is nodig om te voldoen aan het WCAG-succescriterium 3.3.1 Foutidentificatie (niveau A).

Samenvatting boven het formulier

Een zeer gebruikersvriendelijke manier om fouten weer te geven is een combinatie van:

  • een samenvatting boven het formulier en;
  • per formulierveld de foutmelding herhalen.

Elke foutmelding in de samenvatting is ook een link naar het formulier. Hierdoor kan de toetsenbordgebruiker direct doorgaan naar het veld met de foutmelding.

De constructie is als volgt:

  • Na het versturen van een formulier met fouten wordt boven het formulier een lijst met fouten getoond.
  • Deze lijst heeft een kopje met bijvoorbeeld de tekst: "Er was een probleem met je inzending. Verbeter de fouten voor je verder gaat.".
  • Daaronder staat een lijst met de foutmeldingen. Elke foutmelding is ook een link naar het bijbehorende formulierveld.
  • Het kopje boven de fouten krijgt de toetsenbordfocus. Dan staat het meteen in beeld, wordt het voorgelezen door screenreaders en is de tabvolgorde logisch: de links naar de betreffende velden zijn de eerstvolgende items.

GOV.UK geeft hiervan enkele duidelijke voorbeelden op Components Error summary.

Duidelijke foutmeldingen zijn nodig om te voldoen aan het WCAG-succescriterium 3.3.1 Foutidentificatie (niveau A).

Doen

Een samenvatting van de fouten boven het formulier.

Verplaats focus naar de samenvatting of de kop van de samenvatting.

Invoerfouten gevonden in het formulier

[...]

Feedback voor screenreadergebruikers

We geven je 3 extra manieren om feedback te geven over foutmeldingen voor screenreadergebruikers. Met aria-required, aria-invalid in het formulierveld en het <title> element in de <head> van de webpagina.

Het geven van feedback aan screenreadergebuikers foutmeldingen is nodig om te voldoen aan het WCAG-succescriterium 3.3.1 Foutidentificatie (niveau A).

Gebruik ARIA voor feedback

Gebruik ARIA om aanvullende informatie en feedback te geven aan screenreadergebruikers. Informatie die nodig is om het formulier goed te gebruiken en te begrijpen.

Twee ARIA-attributen zijn belangrijk voor screenreaderfeedback:

  • aria-required="true" vertelt dat een veld verplicht is.
  • aria-invalid="true" vertelt dat een veld niet goed is ingevuld.

Initieel staat de waarde van aria-invalid op false. Verander bij foutmeldingen de waarde van false naar true. Eventueel kan het attribuut aria-invalid kan ook worden weggelaten totdat de validatie is uitgevoerd.

<label for="voorbeeld">Voorbeeld</label>
<input aria-required="true" aria-invalid="false" id="voorbeeld" name="voorbeeld" type="text" />

VoiceOver leest voor: "Voorbeeld, vereist, bewerkt tekst".

<label for="voorbeeld">Voorbeeld</label>
<input aria-required="true" aria-invalid="true" id="voorbeeld" name="voorbeeld" type="text" />

VoiceOver leest voor: "Voorbeeld, vereist, ongeldige gegevens, bewerk tekst".

Screenreaderfeedback en focusmanagement na submit

Voor toetsenbord- en screenreadergebruikers is het van belang dat na een submit, de visuele- en toetsenbordfocus op een logische plek komt.

Update het <title> element in de <head>

De inhoud van het <title> element is het eerste wat een screenreader voorleest bij het inladen van een webpagina.

Je kunt hier dus waardevolle informatie kwijt zoals:

  • een formulier heeft 2 foutmeldingen;
  • bij welke stap je bent in een formulier met meerdere stappen;
  • een formulier is succesvol verzonden.

Bijvoorbeeld:

<head>
  <title>Fout: Stap 1 van 4: Uw vraag - Gemeente Voorbeeld</title>
  [...]
</head>

Of:

<head>
  <title>Uw vraag is met succes verstuurd - Gemeente Voorbeeld</title>
  [...]
</head>

Het geven van een beschrijvend <title>-element is nodig om te voldoen aan het WCAG-succescriterium 2.4.2 Paginatitel (niveau A).

Aanvullingen of opmerkingen?

Deze richtlijnen worden onderhouden door het NL Design System. Heb je aanvullingen of opmerkingen? Deel je mening op GitHub met je suggesties.