Toegankelijke formulieren: zo ontwerp je formulierelementen die iedereen kan gebruiken

Waarom formulieren bepalen wie online kan meedoen

Een product bestellen, een afspraak maken, solliciteren of een aanvraag indienen bij de overheid: bijna elke belangrijke stap online eindigt in een formulier. Voor veel mensen is dat in een minuut gebeurd. Voor anderen houdt het daar op.

Mensen die hulpmiddelen zoals schermlezers, brailleleesregels of spraakherkenningssoftware gebruiken, lopen vaak tegen drempels aan die anderen niet eens opvallen. Dat geldt ook voor mensen met een visuele beperking, kleurenblindheid of een cognitieve beperking. En ook voor veel ouderen en voor iedereen met een tijdelijke beperking, bijvoorbeeld door een gebroken arm of een ooginfectie.

Een ontbrekend label, een foutmelding die alleen "Ongeldige invoer" zegt of een CAPTCHA met wazige afbeeldingen is genoeg om hen buiten te sluiten.

Het goede nieuws: de meeste van deze drempels zijn eenvoudig te voorkomen, en daarmee verbeter je de gebruikerservaring voor iedereen. Dit artikel laat eerst de meest voorkomende obstakels zien en legt daarna per element uit hoe je formulieren bouwt die iedereen zelfstandig kan invullen.

Wanneer onlineformulieren een obstakel worden

Deze vijf drempels komen bij toegankelijkheidsaudits steeds weer terug. Verderop gaan we op elk ervan dieper in.

• Ontbrekende structuur en labels: Gebruikers van schermlezers en mensen met een visuele of cognitieve beperking weten niet welk veld welke invoer verwacht. Zichtbare, gekoppelde labels, een logische volgorde en gegroepeerde onderdelen helpen.

• Alleen te bedienen met de muis: Mensen met een motorische beperking en iedereen die met toetsenbord of stem bedient, komt niet verder. Volledige toetsenbordbediening en toegankelijke namen die overeenkomen met het zichtbare label helpen.

• Weinig contrast en kleine letters: Mensen met een visuele beperking, ouderen en iedereen die in de zon op een telefoon kijkt, kunnen het formulier nauwelijks lezen. Een contrast van minimaal 4,5:1 voor tekst en lay-outs die ook werken bij 200% tekstgrootte helpen.

• Ingewikkelde CAPTCHA's en tijdslimieten: Mensen met een cognitieve beperking of leerproblemen en blinde mensen lopen er vaak op vast. Geen puzzels, geen tijdsdruk en alternatieven zoals passkeys of inloglinks per e-mail helpen.

• Video of audio zonder alternatief: Dove, slechthorende en blinde mensen missen belangrijke informatie. Ondertiteling, transcripties en instructies in tekst helpen.

Formulierelementen en hun labels

De meeste formulieren bestaan uit dezelfde HTML-formulierelementen: tekstvelden van één regel, tekstvakken met meerdere regels, keuzelijsten, keuzerondjes, selectievakjes en knoppen om te verzenden of te annuleren.

Elk van deze formuliervelden heeft een toegankelijke naam nodig. Schermlezers lezen die naam voor zodra het veld focus krijgt, zodat gebruikers weten wat ze moeten invullen. De betrouwbaarste manier is een zichtbaar label-element dat aan het veld is gekoppeld: het for-attribuut van het label komt overeen met de id van het veld. Pas door deze programmatische koppeling wordt een zichtbaar label informatie die hulpmiddelen kunnen gebruiken.

html

<label for="first-name">Voornaam</label>
<input type="text" id="first-name" name="first-name" autocomplete="given-name">

<input type="checkbox" id="newsletter" name="newsletter">
<label for="newsletter">Nieuwsbrief ontvangen</label>

Bij tekstvelden en keuzelijsten staat het label vóór het veld, bij selectievakjes en keuzerondjes erna. Een gekoppeld label heeft nog een voordeel: wie erop klikt, activeert ook het veld. Mensen met een motorische beperking krijgen zo een groter klikvlak.

Keuzerondjes of selectievakjes die bij elkaar horen, plaats je in een fieldset met een legend. De legend werkt als zichtbaar label voor de hele groep, en schermlezers lezen hem samen met elke optie voor.

<fieldset>
  <legend>Voorkeur voor contact</legend>
  <input type="radio" id="contact-email" name="contact" value="email">
  <label for="contact-email">E-mail</label>
  <input type="radio" id="contact-phone" name="contact" value="phone">
  <label for="contact-phone">Telefoon</label>
</fieldset>

Gebruik WAI-ARIA-attributen alleen waar gewone HTML niet volstaat. Het ARIA-attribuut aria-labelledbyverwijst naar bestaande zichtbare tekst, en aria-label geeft een naam aan een element zonder zichtbare tekst, zoals een icoonknop. Zorg dat de toegankelijke naam het zichtbare label letterlijk bevat. Anders bereiken mensen die met hun stem bedienen en "klik op Verzenden" zeggen de knop niet.

Invoervelden van één en meerdere regels

Velden van één regel (input) zijn geschikt voor korte gegevens zoals een naam of e-mailadres. Kies het juiste type, bijvoorbeeld email of tel. Op mobiele apparaten opent dan het passende toetsenbord. Velden met meerdere regels (textarea) zijn geschikt voor langere berichten.

html

<label for="email">E-mailadres</label>
<input type="email" id="email" name="email" autocomplete="email">

<label for="message">Je bericht</label>
<textarea id="message" name="message" rows="5"></textarea>

Met het autocomplete-attribuut kunnen browsers bekende persoonsgegevens automatisch invullen. Dat scheelt typwerk en helpt mensen met een motorische beperking of geheugenproblemen (WCAG 1.3.5).

Placeholders vervangen geen labels

Een placeholder kan een voorbeeld van het verwachte formaat tonen, zoals "DD-MM-JJJJ". Hij mag echter nooit het enige label zijn. De placeholdertekst verdwijnt zodra iemand begint te typen, en daarmee de informatie om de invoer te controleren. Bovendien is hij meestal lichtgrijs en haalt hij het minimale contrast niet. Formaathints horen daarom in het label of in een hulptekst onder het veld, gekoppeld met aria-describedby.

Verplichte velden

Markeer verplichte velden duidelijk en leg de markering uit aan het begin van het formulier, bijvoorbeeld: "Velden met een * zijn verplicht". Vertrouw niet alleen op visuele aanwijzingen zoals kleur, want mensen met kleurenblindheid zien die over het hoofd. Voeg het attribuut required toe, of bij eigen bedieningselementen het attribuut aria-required, zodat schermlezers het veld als verplicht aankondigen.

Toetsenbord, muis en stem: elke invoermethode moet werken

Niet iedereen gebruikt een muis. Mensen met een motorische beperking werken vaak met het toetsenbord, een schakelaar of spraakbesturing. Blinde mensen navigeren met toetsenbord en schermlezer. Een formulier moet daarom toetsenbordnavigatie ondersteunen en volledig zonder muis te bedienen zijn:

• Elk veld, elke optie en elke knop is bereikbaar met de Tab-toets, in een logische volgorde die de visuele opbouw volgt.

• De focus is altijd duidelijk zichtbaar, bijvoorbeeld door een stevige rand.

• Eigen elementen zoals vormgegeven dropdowns of datumkiezers werken met de pijltoetsen, Enter en de spatiebalk, net als standaardelementen.

• Er is geen toetsenbordval: gebruikers kunnen altijd verder vanuit een veld.

• Klik- en aanraakvlakken zijn groot genoeg, minimaal 24 × 24 pixels (WCAG 2.5.8). Dat is belangrijk voor bediening met aanraking op de telefoon en voor mensen met een tremor.

Vermijd sneltoetsen met één toets en het accesskey-attribuut. Ze botsen vaak met sneltoetsen van schermlezers, browsers en spraakbesturing. Bied je toch sneltoetsen aan, dan moeten gebruikers ze kunnen uitschakelen of aanpassen (WCAG 2.1.4).

Contrast en lettergrootte

Tekst en labels hebben een contrast van minimaal 4,5:1 met de achtergrond nodig. Veldranden, focusindicatoren en iconen die nodig zijn om het formulier te begrijpen, hebben minimaal 3:1 nodig. Met een contrastchecker zie je snel of je kleuren deze waarden halen. Kies een goed leesbare lettergrootte en zorg dat het formulier ook werkt bij 200% tekstgrootte of bij inzoomen: niets overlapt, niets wordt afgesneden en op smalle schermen is horizontaal scrollen niet nodig.

Ook een duidelijke formulierlay-out helpt. Groepeer velden die bij elkaar horen, scheid logische onderdelen visueel en houd de opbouw voorspelbaar. Zo kunnen mensen met een cognitieve beperking het formulier stap voor stap volgen.

Hulpteksten en foutmeldingen

Goede formulieren voorkomen fouten voordat ze ontstaan. Bied korte hulpteksten naast het veld, een tooltip of een link naar een hulppagina aan als niet vanzelf duidelijk is wat er verwacht wordt.

HTML5-validatieattributen zoals required, type="email" of pattern vangen veel fouten automatisch af. De standaard foutmeldingen van browsers zijn echter niet betrouwbaar toegankelijk. Voeg daarom ook eigen foutmeldingen toe.

Als er toch een fout optreedt, moet de melding precies zeggen wat er mis is en hoe je het oplost. De WCAG noemen dit foutidentificatie en foutsuggestie (WCAG 3.3.1 en 3.3.3). Toon de melding als tekst direct bij het betreffende veld, niet alleen als rode rand, en koppel hem met aria-describedby. Zet bij het verzenden de focus op het eerste foutieve veld of op een foutenoverzicht bovenaan het formulier.

Een paar voorbeelden van onduidelijke en duidelijke meldingen:

• Formaatfout: In plaats van "Ongeldige invoer" beter "Vul de datum in als DD-MM-JJJJ, bijvoorbeeld 05-03-2026".

• Waardefout: In plaats van "Ongeldige datum" beter "Maart heeft 31 dagen. Controleer de dag".

• Ontbrekende verplichte invoer: In plaats van "Fout" beter "Vul je e-mailadres in".

• Mislukte login: In plaats van "Inloggen mislukt" beter "Het e-mailadres of wachtwoord klopt niet. Controleer beide of stel je wachtwoord opnieuw in".

Duidelijke, eenvoudige taal maakt foutmeldingen en hulpteksten voor iedereen makkelijker te begrijpen.

Vraag alleen wat je echt nodig hebt

Elk extra veld is een extra kans op een fout. Vraag alleen de gegevens die je echt nodig hebt en geen informatie die je al hebt. WCAG 2.2 maakt dit expliciet: gegevens die gebruikers in hetzelfde proces al hebben ingevuld, moeten automatisch worden overgenomen of als keuze worden aangeboden (WCAG 3.3.7).

Toon voorwaardelijke velden alleen als ze relevant zijn. Kiest iemand "geen kinderen", dan hoort het veld voor de leeftijd van de kinderen helemaal niet te verschijnen.

Laat gebruikers hun voortgang opslaan

Lange formulieren en formulieren met meerdere pagina's, zoals aanvragen of belastingaangiftes, kosten tijd. Laat zien in welke stap gebruikers zich bevinden en hoeveel stappen er nog volgen. Maak het mogelijk om invoer op te slaan en later verder te gaan, en verwijder nooit al ingevulde gegevens als er een fout optreedt of een sessie afloopt. Bij formulieren met juridische of financiële gevolgen moeten gebruikers hun gegevens vóór het definitief verzenden kunnen controleren, corrigeren of annuleren (WCAG 3.3.4).

Inloggen, CAPTCHA's en tijdslimieten

Inloggen hoort geen geheugentest of puzzel te zijn. WCAG 2.2 heeft hier speciaal een criterium voor ingevoerd: gebruikers hoeven niets te onthouden, over te typen of uit te rekenen om in te loggen, tenzij er een alternatief is (WCAG 3.3.8).

In de praktijk betekent dit:

• Sta plakken in wachtwoordvelden toe en ondersteun wachtwoordmanagers. Blokkeer nooit het klembord.

• Bied alternatieven voor wachtwoorden aan, zoals passkeys, inloglinks per e-mail of tweestapsverificatie via een app.

• Vermijd CAPTCHA's waarbij vervormde letters ontcijferd of opdrachten opgelost moeten worden. Ze vormen een drempel voor mensen met leerproblemen en een cognitieve beperking, en beeld-CAPTCHA's sluiten blinde mensen uit. Een audioversie alleen lost dit niet op, want die sluit doofblinde mensen uit. Onzichtbare, gedragsgebaseerde botbescherming of een honeypotveld is een betere keuze.

Tijdslimieten zetten veel mensen onder druk, bijvoorbeeld gebruikers van schermlezers, mensen met een motorische beperking of iedereen die langzamer leest. Inlogcodes die na 30 of 60 seconden verlopen, zijn een typisch voorbeeld. Is een tijdslimiet niet te vermijden, dan moeten gebruikers die kunnen uitschakelen, aanpassen of verlengen, en moeten ze gewaarschuwd worden voordat de tijd verstrijkt (WCAG 2.2.1).

Video en audio in formulieren

Sommige formulieren leggen stappen uit in een video of bevatten een audiobericht. Video's hebben ondertiteling nodig, audio-inhoud een transcriptie (WCAG 1.2.1 en 1.2.2). Nog beter: zet de belangrijkste instructies ook als tekst direct in het formulier, zodat niemand afhankelijk is van de media.

Checklist: toegankelijke formulieren in één oogopslag

De bijbehorende WCAG-succescriteria (versie 2.2) staan tussen haakjes.

• Elk veld heeft een zichtbaar, gekoppeld label (1.3.1, 2.4.6, 3.3.2)

• Opties die bij elkaar horen, zijn gegroepeerd met fieldset en legend (1.3.1)

• Velden voor persoonsgegevens gebruiken autocomplete (1.3.5)

• Tekstcontrast minimaal 4,5:1, veldranden en focus minimaal 3:1 (1.4.3, 1.4.11)

• Het formulier werkt bij 200% tekstgrootte en op kleine schermen (1.4.4, 1.4.10)

• Alles is met het toetsenbord te bedienen, met zichtbare focus (2.1.1, 2.4.7)

• Geen sneltoetsen met één toets, of ze zijn uit te schakelen (2.1.4)

• Tijdslimieten zijn uit te schakelen, aan te passen of te verlengen (2.2.1)

• Klikvlakken zijn minimaal 24 × 24 pixels (2.5.8)

• De toegankelijke naam bevat het zichtbare label (2.5.3)

• Verplichte velden worden aangekondigd en niet alleen met kleur gemarkeerd (1.4.1, 3.3.2)

• Foutmeldingen zijn concreet en stellen een oplossing voor (3.3.1, 3.3.3)

• Belangrijke gegevens zijn vóór verzending te controleren en te corrigeren (3.3.4)

• Al ingevulde gegevens worden niet opnieuw gevraagd (3.3.7)

• Inloggen werkt zonder geheugentest of puzzel (3.3.8)

• Video's hebben ondertiteling, audio heeft een transcriptie (1.2.1, 1.2.2)

Alle criteria vind je in de Web Content Accessibility Guidelines (WCAG) 2.2.

Conclusie

Toegankelijke formulieren zijn geen extraatje. Ze zorgen ervoor dat een formulier voor iedereen werkt. Duidelijke labels, een logische structuur, volledige toetsenbordbediening, behulpzame foutmeldingen en eerlijke inlogmethoden maken het mogelijk dat mensen met een beperking, ouderen en mensen met een tijdelijke beperking formulieren zelfstandig invullen. Tegelijk worden formulieren voor alle anderen sneller en minder foutgevoelig. Voor bedrijven betekent elk afgebroken formulier gemiste conversies – een verborgen kostenpost van een ontoegankelijke website.

Hoe toegankelijk zijn de formulieren op jouw website? Start een gratis toegankelijkheidscheck met Eye-Able en ontvang je resultaat binnen 2 minuten, of praat met onze toegankelijkheidsexperts.

FAQ: toegankelijke formulieren

Wat maakt een onlineformulier toegankelijk?

Een toegankelijk formulier kan door iedereen worden ingevuld, ook door mensen die hulpmiddelen gebruiken, ouderen en mensen met een tijdelijke beperking. Het belangrijkst zijn zichtbare, gekoppelde labels bij elk veld, volledige toetsenbordbediening, voldoende contrast, duidelijke foutmeldingen en geen tijdsdruk of puzzels bij het inloggen.

Welke WCAG-criteria gelden voor formulieren?

De belangrijkste zijn 1.3.1 (Info en relaties), 2.1.1 (Toetsenbord), 3.3.1 (Foutidentificatie), 3.3.2 (Labels of instructies) en 3.3.3 (Foutsuggestie). Met WCAG 2.2 kwamen daar 3.3.7 (Overbodige invoer) en 3.3.8 (Toegankelijke authenticatie) bij, die ook direct over formulieren gaan.

Is een placeholder genoeg als label?

Nee. De placeholdertekst verdwijnt zodra iemand typt en heeft meestal te weinig contrast. Gebruik voor elk veld een zichtbaar label-element en de placeholder hoogstens als extra hint.

Heb ik ARIA-attributen nodig voor toegankelijke formulieren?

Meestal niet. Standaard HTML-formulierelementen met een gekoppeld label-element zijn al toegankelijk. ARIA-attributen zoals aria-describedby of aria-required zijn handig om hulpteksten en foutmeldingen te koppelen en voor eigen bedieningselementen die HTML niet biedt.

Zijn CAPTCHA's toegankelijk?

De meeste niet. Beeld- en tekstpuzzels sluiten blinde mensen en mensen met een cognitieve beperking uit, audio-CAPTCHA's sluiten doofblinde mensen uit. Onzichtbare, gedragsgebaseerde botbescherming of een honeypotveld beschermt formulieren zonder gebruikers te testen.

Zijn toegankelijke formulieren wettelijk verplicht?

In veel gevallen wel. In de EU geldt sinds 28 juni 2025 de European Accessibility Act voor veel digitale producten en diensten, zoals webwinkels en bankdiensten. Nederlandse overheidsinstanties zijn al sinds 2018 wettelijk verplicht hun websites toegankelijk te maken. De technische basis is de Europese norm EN 301 549, die naar de WCAG verwijst.

Hoe test ik of mijn formulieren toegankelijk zijn?

Begin met drie snelle tests: vul het formulier alleen met het toetsenbord in, zoom de pagina in tot 200% en probeer het formulier met een gratis schermlezer zoals NVDA. Een automatische toegankelijkheidscheck vindt veel technische problemen, zoals ontbrekende labels of te weinig contrast. Een handmatige audit door toegankelijkheidsexperts dekt af wat tools niet kunnen beoordelen, bijvoorbeeld of foutmeldingen echt helpen.