Formulieren: instructies en foutmeldingen

We kennen het allemaal wel: je bent lekker bezig met het invullen van een formulier en BAM, een felrode foutmelding verschijnt. Een verplicht veld vergeten, een ongeldige waarde ingevoerd, whoopsie! 

Fouten maken overkomt de besten. Maar goed nieuws! Als ontwikkelaars, redacteurs en ontwerpers kunnen we de kans op fouten wél zo klein mogelijk te maken. En als er dan toch een foutje insluipt? Dan kunnen we ook helpen om dat weer op te lossen.

Door formulieren toegankelijk aan te bieden, help je eigenlijk iedereen. Win-win! Maar gebruikers met een beperking profiteren hier extra van, bijvoorbeeld omdat ze moeite hebben met het waarnemen van alle informatie, of omdat het invullen van een formulier cognitief gezien voelt als een marathon door modder. Assistentie bij invoer is dan niet alleen fijn, maar gewoonweg onmisbaar.

WCAG 3.3 – Assistentie bij invoer

Één van de richtlijnen binnen de WCAG is richtlijn 3.3 Assistentie bij invoer. Deze richtlijn heeft als doel om het aantal ernstige of onherstelbare fouten te verminderen, de kans te vergroten dat alle fouten door de gebruiker worden opgemerkt en gebruikers te helpen begrijpen wat ze moeten doen om een fout te corrigeren. In dit artikel ga ik in op drie van de zes succescriteria binnen deze richtlijn:

• 3.3.1 Fout identificatie

• 3.3.2 Labels of instructies

• 3.3.3 Foutsuggestie

Deze drie criteria vormen de algemene basis rondom assistentie bij invoer. De overige criteria zijn wat specifieker voor bepaalde situaties en komen een andere keer aan bod.

Ondanks dat dit de volgorde is hoe deze succescriteria in de WCAG-richtlijnen staan, is dat niet de volgorde waarin ik ze zal toelichten. Waarom? Dat is je helemaal duidelijk na het lezen van deze editie van Opvallend (on)toegankelijk.

Instructies en foutmeldingen: 3 belangrijke criteria

1.   WCAG 3.3.2 – Labels of instructies

Wanneer er input vanuit een gebruiker nodig is, is het belangrijk dat daar een label of instructie bij staat. Met goede labels en instructies wordt het voor een gebruiker duidelijk wat er bijvoorbeeld bij een invoerveld ingevuld moet worden. Hiermee voorkom je dat er onnodige fouten worden gemaakt. Dat scheelt een hoop tijd en energie, zeker voor mensen met een beperking.

In mijn onderzoeken kom ik regelmatig problemen met dit succescriterium tegen. Om de meest gevonden problemen te voorkomen, hier wat aandachtspunten:

• Zorg dat invoervelden zijn voorzien van een label dat zichtbaar blijft. Alleen een placeholdertekst is niet genoeg, want als een gebruiker gaat typen, verdwijnt die placeholdertekst en is het doel niet meer te bepalen. 

• Als een bepaald format nodig is bij de invoer, dan moet dit als instructie vermeld worden. Denk bijvoorbeeld aan verplichte formats voor een datum (DD/MM/JJJJ), telefoonnummer (met of zonder koppelteken of spaties) en postcodes.

In het ideale geval zorgen duidelijke labels en instructies dus voor zo min mogelijk fouten (vandaar deze volgorde in de uitleg!). Treden er toch fouten op, dan is het van belang om de gebruiker goed op weg te helpen bij het oplossen van deze fouten.

2.   WCAG 3.3.1 – Fout identificatie

Als er fouten zijn opgetreden bij de invoer (ongeldige invoer of leeggelaten vereiste invoer), dan moet de gebruiker hiervan op de hoogte worden gebracht. Het is belangrijk om duidelijk te maken:

• Dat er een fout is opgetreden

• Wat er precies is foutgegaan

• En bij welk invoerveld.

Er zijn meerdere manieren hoe dit bereikt kan worden. Een goede manier is bijvoorbeeld om foutmeldingsteksten te gebruiken die echt een fout beschrijven (vaak zit daar een ontkenning in) en deze onder de bijbehorende invoervelden te plaatsen. Bijvoorbeeld “Het veld voornaam is niet ingevuld” of “Het telefoonnummer bevat te weinig cijfers”. Vaak wordt dit ook gecombineerd met een dikke rode rand, een rode tekst voor de foutmelding en een icoon dat een fout aangeeft.

Ook bij foutmeldingen zie ik in mijn onderzoek regelmatig dingen misgaan. De meest voorkomende is denk ik toch wel 10x in hetzelfde formulier de melding “Dit veld is verplicht”. Dit is én een instructie die niet duidelijk aangeeft dat er iets fout is gegaan en wat, én geeft niet aan bij welk invoerveld. Natuurlijk komt daar nog wel wat meer bij kijken, maar door meldingen als “Dit veld is verplicht” te vermijden, voorkom je vaak al veel problemen met dit succescriterium.

3.   WCAG 3.3.3 – Foutsuggestie

Het laatste criterium van de drie heeft als doel om een gebruiker duidelijk te maken hoe hij een gemaakte fout in een invoerveld van een formulier kan oplossen. Dit kan door suggesties te geven hoe hij het veld wel in zou moeten vullen.

Met de vorige twee criteria wordt er al voor gezorgd dat er duidelijke labels of instructies en duidelijke foutmeldingen moeten zijn. In 95% van de gevallen is dat genoeg om te zorgen dat gebruikers de formulieren in één keer of na één ronde foutmeldingen succesvol kunnen invullen.

→ Als er een goede instructie is (3.3.2) en een goede foutmelding (3.3.1), dan is er bijna nooit meer een probleem bij succescriterium 3.3.3.

Wanneer er wél iets fout kan gaan voor dit succescriterium, is als er een verkeerde foutsuggestie wordt gegeven, waardoor de gebruiker onjuiste informatie krijgt. Bijvoorbeeld als bij het invoerveld “E-mailadres” de foutsuggestie staat dat de gebruiker een telefoonnummer in moet vullen. Gelukkig kom ik dit in mijn onderzoeken bijna nooit tegen!

Zijn we er dan?

Deze drie succescriteria helpen je goed op weg om te zorgen dat je gebruikers formulieren succesvol kunnen invullen. Maar nee, helaas betekent dit niet dat we er dan al helemaal zijn. Er komt namelijk nog veel meer kijken bij het maken van toegankelijke formulieren. Zo kwamen formulieren bijvoorbeeld ook al aan bod in mijn vorige artikel over WCAG 1.4.1 Gebruik van kleur.

Een laatste tip wil ik je wel alvast meegeven. Dit valt eigenlijk onder succescriterium 1.3.1 Info en relaties, maar gaat toch regelmatig mis en heeft veel raakvlakken met de inhoud van dit artikel:

→ Zorg dat je labels, instructies en foutmeldingen koppelt aan het bijbehorende invoerveld. Zo zorg je dat de relaties niet alleen visueel, maar ook voor hulpsoftware beschikbaar zijn.

Hoe dat precies werkt, daarover binnenkort meer.