Ga naar hoofdinhoud

Wanneer gebruik je welk formulierelement

Je wilt natuurlijk dat zoveel mogelijk mensen een formulier kunnen invullen op de makkelijkste manier. We geven twee richtlijnen die hierbij helpen.

Er is nog veel te onderzoeken over wat het beste formulierelement is voor wat je wilt uitvragen. Doe je gebruikersonderzoek? Deel dan alsjeblieft je bevindingen op gebruikersonderzoeken.nl zodat we hiervan allemaal kunnen leren.

Zorg dat iedereen een formulierelement kan bedienen of geef een alternatief

Sommige formulierelementen werken (nog) niet goed of zijn complex om te bedienen met toetsenbord, screenreader of stembesturing.

Op HTML5 Accessibility houdt Steve Faulkner de ondersteuning bij van HTML-elementen, in de verschillende browsers en voor de diverse hulpmiddelen.

De ontwikkeling van browsers gaat snel en het gebruik van HTML geeft niet altijd garantie voor toegankelijkheid. Test daarom altijd een formulier met toetsenbord, screenreader of stembesturing.

Ervoor zorgen dat iedereen een formulierelement kan bedienen en begrijpen is nodig om te voldoen aan de volgende WCAG-succescriteria:

Multiselect

Het multiselect formulierelement <select multiple> is ingewikkeld te bedienen met toetsenbord. In Safari werkt multiselect (nog) niet met een toetsenbord en daarom ook niet met de screenreader VoiceOver.

Gebruik in plaats van multiselect bijvoorbeeld checkboxes om gebruikers meerdere keuzes te laten maken.

Datum- en tijdkiezers

Datum- en tijdkiezers zijn lastig goed toegankelijk te maken, zodat ze voor iedereen makkelijk te begrijpen en te bedienen zijn. Maar ze kunnen wel handig zijn voor ziende muisgebruikers.

De beste optie is om naast de kiezer ook een alternatief toe te voegen, een formulierveld waar gebruikers de datum of tijd kunnen invullen.

Veel browsers voegen zelf al een kiezer toe voor de <input type="date"> en <input type="time">-elementen, de gebruiker kan dan beide opties gebruiken. Het is alleen jammer dat deze kiezers (nog) niet te stijlen zijn met CSS. Daarnaast zien de kiezers er per browser verschillend uit en werken ze anders.

Input type="number" versus inputmode="numeric"

Een andere optie is het laten invoeren van alleen nummers met <input type="number"> Bijvoorbeeld:

<label for="dag1">Geboortedag</label> <input id="dag1" type="number" autocomplete="bday-day" min="1" max="31" />

GOV.UK heeft hier onderzoek naar gedaan en vindt type=number qua gebruikersvriendelijkheid te foutgevoelig.

Met <input type="number"> bestaat het risico dat gebruikers per ongeluk een getal verhogen wanneer ze iets anders proberen te doen, bijvoorbeeld omhoog of omlaag scrollen op de pagina. En als de gebruiker iets probeert in te voeren dat geen getal is, is er geen expliciete feedback over wat verkeerd gaat.

Zij beveelt het gebruik van inputmode="numeric" aan, omdat dit het numerieke toetsenbord op mobile apparaten activeert.

Bijvoorbeeld:

<label for="dag2">Geboortedag</label> <input id="dag2" type="text" inputmode="numeric" autocomplete="bday-day" />

Selects voor dag, maand en jaar

Een optie is het gebruik van 3 select-opties met de waardes van bijvoorbeeld dag, maand en jaar. Het nadeel hiervan is dat de select voor een geboortejaar een hele lange lijst kan worden. Het kan confronterend zijn als, scrollend door een lange lijst aan jaartallen, beseft dat je wel erg oud aan het worden bent...

Tekstveld

Als de data niet verder automatisch verwerkt gaat worden is een tekstveld een makkelijke optie. Dan is de gebruiker vrij een eigen format te kiezen. Geef dan wel een hint in de description hoe dit het beste te doen.

De keuze hangt af van de context

Welke optie je kiest, is afhankelijk van de context. Wat vraag je uit? En wat gaat er met de data gebeuren? Bijvoorbeeld:

  • Kent men de datum uit het hoofd (bijvoorbeeld geboortedatum)? Gebruik dan drie losse invulvelden.
  • Kan men een datum prikken (bijvoorbeeld een afspraak)? Dan is een datumkiezer in combinatie met zelf invullen een goed plan. "Ik weet de datum niet maar woensdagen komen mij het best uit". Hou wel rekening met 'niet beschikbare' dagen, gebruik in dat geval als alternatief bijvoorbeeld een select-optie met beperkte keuzes.
  • Kan de gebruiker alleen kiezen uit een paar data (bijvoorbeeld vanaf vandaag tot een week vooruit), dan zijn radio buttons geschikt.

Lees hierover meer op Ask users for Dates van GOV.UK.

De regel is altijd: Je kunt een ontoegankelijke component aanbieden, mits je ook een goed toegankelijk alternatief aanbiedt.

Doen

Uitvragen geboortedatum met een tekstveld.

Bijvoorbeeld 31 december 1970.

Doen

Uitvragen geboortedatum met een datumveld.

De meeste browsers voegen zelf een datumkiezer toe.

Bijvoorbeeld 31/12/1970.

Doen

Uitvragen geboortedatum met een inputmode=numeric.

Geboortedatum
Bijvoorbeeld 31.
Bijvoorbeeld 12 voor december.
Bijvoorbeeld 1970.

Niet doen

Uitvragen geboortedatum met een nummerveld (type=number).

Geboortedatum
Bijvoorbeeld 31.
Bijvoorbeeld 12 voor december.
Bijvoorbeeld 1970.

Kies voor het meest gebruiksvriendelijke formulierelement

Deze richtlijn is tevens een opdracht; doe gebruikersonderzoek voor nieuwe formulieren of componenten. Gebruiksvriendelijkheid is afhankelijk van het specifieke doel en de doelgroep van een formulier.

Eigen onderzoek is dan altijd belangrijk, maar er is al veel onderzocht. Op gebruikersonderzoeken.nl staan de bevindingen van veel verschillende gebruikersonderzoeken.

Maar er zijn ook gerenommeerde bronnen voor toegankelijkheid en gebruikersonderzoek zoals de Nielsen Norman Group, Adrian Roselli, The A11y Project, TPGi, en Adam Silver. Doe in elk geval ook eigen onderzoek op het formulier wat je ontwikkelt.

Een voorbeeld: wanneer gebruik je een <select> met opties en wanneer radiobuttons? Of kies je een eigen oplossing? Hierover is (onder andere) het volgende onderzoek gepubliceerd:

Andere bronnen voor gebruikersonderzoek:

Studeer en test met hulpmiddelen en met gebruikers. Dat is de boodschap die we hier willen meegeven.

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.