Ga naar hoofdinhoud

Voorkom fouten, help de gebruiker

Een formulier invullen moet zo gemakkelijk mogelijk zijn. Hoe help je je gebruiker het beste?

Vermeld duidelijk of een veld wel of niet verplicht is

Laat gebruikers duidelijk weten welke informatie ingevuld moeten worden om een formulier te verzenden. Hiervoor heb je twee opties.

  • Door de niet-verplichte velden te markeren.
  • Door de verplichte velden te markeren.

Op basis van gebruikersonderzoek zouden wij de eerste optie aanbevelen.

Plaats de uitleg over wel of niet verplichte velden altijd boven het formulier, zodat de gebruiker weet wat te verwachten bij het invullen.

Maak de markering ook onderdeel van de labeltekst.

Screenreadergebruikers krijgen deze informatie daarnaast ook voorgelezen door aria-required of required in de code op te nemen bij de verplichte velden.

Door te helpen fouten te voorkomen voldoe van aan WCAG-Succescriterium 3.3.2 Labels of instructies (niveau A).

Optie 1: 'niet-verplichte' velden markeren

Uitgaande van het gegeven dat je in formulieren enkel het broodnodige uitvraagt zullen de meeste velden verplicht zijn. Hierdoor vormen de niet-verplichte velden een uitzondering. Geef dit aan door bij de niet-verplichte velden de tekst '(niet verplicht)' in het label op te nemen.

Gebruikersonderzoek over de toepassing van 'niet verplicht' versus 'verplicht':

Let op: Het woord 'optioneel' kan te moeilijk zijn voor mensen die laaggeletterd zijn. Gebruik dus 'niet verplicht'.

Doen

Geef boven het formulier aan hoe niet-verplichte velden worden aangegeven.

Vul alle velden in. Als een veld niet verplicht is, staat dit erbij.

Niet doen

De gebruiker laten raden wat er al dan niet verplicht is.

Optie 2: 'verplichte' velden markeren

Zijn de meeste velden in een formulier 'niet verplicht'? Of is het technisch niet mogelijk om de niet-verplichte velden te markeren? Geef dit dan aan door bij de verplichte velden de tekst '(verplicht)' in het label op te nemen.

Een populaire manier om verplichte velden aan te duiden is door in het label een asterisk '*' op te nemen. Dit heeft niet de voorkeur omdat dit een extra denkstap voor de gebruikers vergt, zoals blijkt uit bovenstaand gebruikersonderzoek.

Gebruik je deze constructie toch omdat je CMS of plug-in alleen deze mogelijkheid biedt, leg dan boven het formulier uit wat de asterisk betekent. Een asterisk alleen bij het formulierveld is niet voldoende, niet iedereen bezit deze voorkennis.

Uit onderzoek van Elevenways blijkt dat de asterisk goed wordt voorgelezen door screenreaders: Hoe screenreaders speciale tekens lezen: een update.

Doen

Geef boven het formulier aan hoe verplichte velden worden aangegeven.

Als een veld verplicht is, staat dit erbij.

Doen

Geef boven het formulier aan hoe verplichte velden worden aangegeven en leg uit wat asterisk betekent.

Als een veld verplicht is, staat er een * bij.

Niet doen

Bij alle velden aangeven of het al dan niet verplicht is.

Screenreaderfeedback

Vertel een gebruiker van hulptechnologieën (als screenreaders) dat een veld verplicht is met het ARIA-attribuut aria-required="true".

Je kunt ook het HTML-attribuut required gebruiken in plaats van aria-required, maar dit vereist ook het attribuut novalidate in het <form> element. Novalidate voorkomt dat de formuliervalidatie van de browser in werking treedt. Voor aria-required="true" hoeft dit niet. Alhoewel het gebruik van required in plaats van aria-required niet fout is, geven we daarom de voorkeur aan aria-required.

Doen

Gebruik aria-required om aan te geven of een veld verplicht is.

Doen

Gebruik required om aan te geven of een veld verplicht is, in combinatie met novalidate.

Niet doen

Geef helemaal niet aan of een veld verplicht is, en laat de gebruiker dit pas weten bij de foutmeldingen.

Invoerfout: Vul de naam van een kleur in.

Sta knippen en plakken van een wachtwoord toe

Een wachtwoord moet veilig zijn. Als je het knippen en plakken van een wachtwoord verhindert, dwing je gebruikers tot een simpel en goed te onthouden wachtwoord. Dat is nu juist niet de bedoeling.

Kopiëren/plakken vanuit een wachtwoordmanager is een veel veiligere manier om een gebruiker een wachtwoord te laten invullen.

Zoals het Britse National Cyber Security Centre uitlegt in Let them paste passwords.

Doen

Sta kopiëren van een wachtwoord toe.

Keur niet te snel af

In de formuliervalidatie kan er al veel afgevangen worden. Denk met de gebruiker mee.

Geldige e-mailadressen

Sommige mensen gebruiken een + in hun e-mailadres, bijvoorbeeld om e-mails makkelijker te kunnen groeperen.

Zo kiezen ze voor naam+school@voorbeeld.nl voor e-mails van school en naam+werk@voorbeeld.nl voor e-mails over werk. Dit zijn geldige e-mailadressen, keur ze dus niet af.

email met een plus teken is goedgekeurd

Eenduidig te herschrijven

Postcodes kunnen op verschillende manieren worden geschreven: bijvoorbeeld “1234 AA” (met spatie), “1234AA” (zonder spatie), “1234aa” (met kleine letters). Ook extra spaties aan het begin of eind kunnen meekomen bij het knippen/plakken van tekst.

In code kunnen deze vormen gemakkelijk naar elkaar worden herschreven. Door alle vormen te accepteren en door de software te laten corrigeren, geef je prioriteit aan de gebruiker, in plaats van aan je systeem.

De 3 verschillende wijzen van postcode invoeren die allemaal goed zijn

Geef geldige waardes aan voor een invoerveld

Geef geldige waardes aan voor een invoerveld (bijvoorbeeld de datum- of wachtwoordeisen) en niet alleen in de placeholder.

Bedenk ook of het echt belangrijk is of, bijvoorbeeld een geboortedatum of telefoonnummer aan exacte invoereisen moet voldoen.

Wachtwoord-eisen zijn in de description getoond

Voorbeeld van de waarden voor de geboortedatum worden in de description getoond

Doen

Leg uit hoe een veld in te vullen.

Bijvoorbeeld in de description.

Minimaal 8 karakters, waarvan 2 cijfers en 1 hoofdletter.

Niet doen

Wijze van invullen weglaten.

Laat de gebruiker niet raden of pas bij de foutmeldingen ontdekken wat er mis is.

Niet doen

Wijze van invullen alleen in de placeholder zetten.

Zeker als de wijze van invullen precies goed moet zijn.

Vul bekende informatie in waar mogelijk

Als de gebruiker is ingelogd, gebruik dan bekende informatie om velden vast in te vullen. In DigiD-sessies is bijvoorbeeld al veel informatie beschikbaar, die zou kunnen worden gebruikt om velden vooraf in te vullen. Het gebruik van DigiD is wel aan wettelijke voorwaarden verbonden.

Autocomplete

Het HTML-attribuut autocomplete maakt het voor de gebruiker makkelijker om al eerder ingevulde informatie automatisch toe te voegen. De volledige lijst waarden staat op de MDN-website: HTML-attribuut: autocomplete.

Sommige waarden zijn onduidelijk of ontbreken voor Nederlandse toepassingen. Jules Ernst van 200 OK heeft een overzicht gemaakt van de beste manier om autocomplete in Nederlandse formulieren toe te passen.

Toevoegen van autocomplete aan de formuliervelden is nodig om te voldoen aan het WCAG-Succescriterium 1.3.5 Identificeer het doel van de input (niveau AA).

Doen

Voeg autocomplete waarden toe aan adresgegevens.

Niet doen

Laat autocomplete waarden weg bij adresgegevens.

Maak het mogelijk een inzending te controleren, te wijzigen of ongedaan te maken

Wanneer een gebruiker een formulier invult met juridische, financiële of persoonlijke gegevens, is het extra belangrijk dat de gegevens juist zijn en dat de gebruiker goed kan controleren wat is ingevuld.

Een verkeerd of onvolledig ingevuld formulier kan grote consequenties hebben voor de inzender.

Dit is niet alleen belangrijk voor mensen met een functiebeperking, maar voor iedereen. Je wilt toch graag extra goed controleren of je de juiste aankomst- en vertrekdatum hebt ingevuld bij het boeken van een dure vakantie. Of dat je alles naar waarheid en compleet hebt ingevuld bij de belastingaangifte.

Zorg er daarom voor dat gebruiker de ingevulde gegevens kan controleren en indien gewenst kan corrigeren. En als dat niet mogelijk is: bied de mogelijkheid om een inzending of transactie te annuleren.

Bied ten minste één van de volgende opties aan: "omkeerbaar", "gecontroleerd" of "bevestigd".

Omkeerbaar

Geef de gebruiker de mogelijkheid om een online aanvraag, opzegging of financiële transactie terug te draaien of naderhand te wijzigen.

Bijvoorbeeld:

  • Het is mogelijk om een bestelling binnen 24 uur te annuleren.
  • De gebruiker heeft een week bedenktijd voordat gegevens definitief worden verwijderd.
  • Persoonlijke gegevens zijn te wijzigen in een "Mijn-omgeving".

Gecontroleerd

Controleer tijdens het invullen de gegevens op invoerfouten en geef de gebruiker de mogelijkheid de gegevens te verbeteren.

Een goede foutafhandeling tijdens het invullen van een formulier helpt de gebruiker fouten te voorkomen en te corrigeren. Lees hiervoor ook de richtlijnen over foutmeldingen.

Bevestigd

Geef de gebruiker, voor inzending, de mogelijkheid om de ingevulde gegevens te lezen en te verbeteren.

Bij een complex formulier en als er juridische, financiële of persoonlijke gegevens worden uitgevraagd, is het essentieel dat de gebruiker kan controleren of alles goed is ingevuld voor verzenden.

Alles op een rij in de laatste stap van het formulier, met de mogelijkheid om nog correcties te maken. Dit staat uitgebreider beschreven in Meerdere stappen in een formulier.

Gebruikersonderzoek voor het Contactformulier voor WMEBV laat goed zien hoe belangrijk deze laatste stap is.

GOV.UK beschrijft hoe gebruikers te helpen in Help users to Check answers.

Voorbeelden van patronen in het NL Design System:

Omkeerbaarheid, controle of bevestiging bij een formulier waarin om juridische, financiële of persoonlijke gegevens wordt gevraagd, is nodig om te voldoen aan het WCAG-succescriterium 3.3.4 Foutpreventie (wettelijk, financieel, gegevens) (niveau AA).

Over deze richtlijnen

Deze richtlijnen worden onderhouden door het NL Design System en zijn op dit moment in beta.

We willen graag van de community horen of ze werkbaar en nuttig zijn. Heb je vragen, aanvullingen of opmerkingen? Deel je mening op GitHub met je suggesties.