Toegankelijke digitale formulieren maken: zo doe je het goed
Een toegankelijk digitaal formulier heeft permanente labels bij elk invoerveld, foutmeldingen die specifiek beschrijven wat er fout is en hoe je het oplost, volledige toetsenbordnavigatie door alle velden en knoppen, voldoende kleurcontrast op veldgrenzen en een logische focusvolgorde. Die vijf dingen samen maken een formulier bruikbaar voor iedereen, van mensen die voorleessoftware gebruiken tot mensen die snel iets invullen op hun telefoon in de trein.
Waarom formulieren zo vaak misgaan
Stel je voor dat je een zorgverzekering wil overstappen. Je vult het formulier in, klikt op Verzenden en ziet een melding in het rood. Maar je snapt niet wat er mis is. De melding zegt: "Controleer je invoer." Welk veld? Wat is er fout? Hoe moet het dan wel?
Dit scenario speelt zich elke dag miljoenen keer af op Nederlandse websites. Niet alleen voor mensen met een beperking. Voor iedereen die haast heeft, aandacht tekortkomt of gewoon snel een formulier invult op zijn telefoon.
Formulieren zijn de conversiepunten van je website. Een contactformulier, een aanvraagformulier, een bestelflow, een inlogpagina. Als die niet werken voor een deel van je bezoekers, verlies je leads, klanten en vertrouwen. En als je onder de EAA of de Wet digitale overheid valt, verlies je ook nog eens de juridische dekking.
In onze WCAG-onderzoeken bij gemeenten, webwinkels en zorginstellingen zijn formulieren consistent de categorie met de meeste bevindingen. Niet omdat formulieren zo ingewikkeld zijn. Maar omdat ze zelden goed worden getest vanuit het perspectief van iemand die hulpsoftware gebruikt.
We kennen het allemaal wel: je bent lekker bezig met het invullen van een formulier en dan verschijnt er een foutmelding die je niks zegt
De zeven WCAG-criteria die voor formulieren tellen
WCAG heeft meerdere succescriteria die specifiek op formulieren van toepassing zijn. Dit zijn de zeven die het vaakst worden geschonden en het meeste impact hebben op gebruikers.
1.3.1: Info en relaties
Niveau A: Verplicht
| Wat het betekent | Hoe je het toepast |
|---|---|
| Labels moeten programmatisch aan hun invoerveld zijn gekoppeld. Het is niet genoeg dat het label er visueel naast staat. De code moet die relatie ook bevatten, zodat voorleessoftware de koppeling kan maken. | Gebruik het for-attribuut op je label in combinatie met het bijbehorende id op het invoerveld. Of gebruik aria-labelledby of aria-label als een zichtbaar label niet mogelijk is. <label for="email">E-mailadres</label> <input type="email" id="email"> |
1.4.3 / 1.4.11: Contrast van tekst en niet-tekstuele content
Niveau AA: Verplicht
| Wat het betekent | Waar het misgaat |
|---|---|
| Tekst in formulieren (labels, instructies, ingevoerde tekst) heeft een contrastverhouding van minimaal 4,5:1 nodig. Veldgrenzen, radiobuttons en checkboxen hebben een contrastverhouding van minimaal 3,0:1 ten opzichte van de achtergrond nodig. | Lichtgrijze placeholder-tekst op een witte achtergrond. Dunne veldgrenzen die nauwelijks zichtbaar zijn. Radiobuttons zonder voldoende contrast. Dit zijn de meest voorkomende contrastfouten in formulieren. |
2.1.1: Toetsenbord
Niveau A: Verplicht
| Wat het betekent | Waar het misgaat |
|---|---|
| Alle functionaliteit in je formulier moet bedienbaar zijn met alleen het toetsenbord. Dat betekent: elk invoerveld bereikbaar via Tab, elke knop activeerbaar via Enter of Spatie en geen toetsenbordfocus die vastloopt in een veld of component. | Custom dropdowns, datumkiezers, bestandsupload-knoppen en betaalmethode-selectors worden regelmatig gebouwd als custom JavaScript-componenten die niet toetsenbord-bedienbaar zijn. Test je formulier altijd volledig zonder muis. |
3.3.1: Foutidentificatie
Niveau A: Verplicht
| Wat het betekent | Goed voorbeeld |
|---|---|
| Als een formulier automatisch een fout detecteert, wordt dat foutieve veld benoemd in tekst en beschreven wat de fout is. Alleen een rood kader is niet genoeg. De fout moet ook in tekst worden aangegeven. | Niet: "Ongeldige invoer." Wel: "E-mailadres is ongeldig. Vul een e-mailadres in zoals naam@voorbeeld.nl." |
3.3.2: Labels of instructies
Niveau A: Verplicht
| Wat het betekent | Waarom placeholder geen label is |
|---|---|
| Elk invoerveld waarbij een gebruiker informatie moet invoeren heeft een zichtbaar label of een duidelijke instructie. Dat label blijft zichtbaar, ook als het veld al is ingevuld. | Placeholder-tekst verdwijnt zodra je begint te typen. Iemand die halverwege het invullen twijfelt, heeft geen manier meer om te zien wat er in het veld moet staan. Gebruik altijd een zichtbaar, permanent label. |
3.3.3: Foutoplossing
Niveau AA: Verplicht
| Wat het betekent | Praktisch verschil |
|---|---|
| Als er een invoerfout wordt gedetecteerd, wordt niet alleen de fout beschreven maar ook een suggestie gegeven voor hoe het correct ingevuld kan worden. Tenzij dat de beveiliging of het doel van het formulier in gevaar brengt. | 3.3.1 zegt: vertel dat er een fout is. 3.3.3 zegt: vertel ook hoe je het kunt oplossen. Beide zijn nodig voor een echt toegankelijk formulier. |
3.3.7: Redundant Entry (nieuw in WCAG 2.2)
Niveau A: Verplicht
| Wat het betekent | Voorbeeld |
|---|---|
| Informatie die eerder in een meerstapsproces is ingevoerd, mag niet opnieuw worden gevraagd. Tenzij dat essentieel is of de gegevens inmiddels verlopen zijn. | Iemand die in stap 1 van een checkout naam en bezorgadres heeft ingevuld, moet in stap 3 bij het factuuradres een optie krijgen zoals "Zelfde als bezorgadres". Die keuze niet aanbieden, is een schending van dit criterium. |
De vijf meest voorkomende fouten in formulieren
Op basis van onze WCAG-onderzoeken bij Nederlandse organisaties zijn dit de problemen die we het vaakst tegenkomen, bij kleine contactformulieren én grote bestelflows.
| Fout | Goed |
|---|---|
| Placeholder-tekst als enig label. Zodra je begint te typen, verdwijnt de aanduiding wat er in het veld moet staan. | Zichtbaar, permanent label boven of naast elk invoerveld, ook als het veld al is ingevuld. |
| Foutmelding alleen in rood, zonder tekst die uitlegt wat er fout is. | Specifieke foutmelding per veld: "Voer een geldig e-mailadres in, zoals naam@voorbeeld.nl." |
| Verplicht veld alleen aangegeven met een sterretje, zonder uitleg wat dat sterretje betekent. | Verplicht veld aangegeven met een sterretje én een legenda bovenaan: "* = verplicht veld." |
| Datumkiezer of dropdown niet bereikbaar met Tab of Enter. | Alle formulierelementen bereikbaar en bedienbaar met Tab, Enter en Spatie. |
| Focus springt na het klikken op Verzenden naar boven in de pagina, zonder duidelijke melding van wat er misgegaan is. | Na een mislukte verzending springt de focus naar een foutoverzicht bovenaan, met links naar de foutieve velden. |
CAPTCHA: het toegankelijkheidsprobleem dat iedereen kent maar niemand oplost
CAPTCHA's zijn bedoeld om bots te weren. Dat begrijpen we. Maar de manier waarop ze doorgaans worden ingezet, maakt formulieren ontoegankelijk voor een grote groep mensen.
De traditionele "selecteer alle verkeerslichten"-CAPTCHA is een visuele puzzel die blinde gebruikers simpelweg niet kunnen oplossen. Dat is een directe barrière, geen ongemak. En er is goed nieuws: WCAG 3.3.8 (nieuw in WCAG 2.2, niveau AA) stelt nu expliciet dat authenticatieprocessen geen cognitieve test mogen vereisen tenzij er een alternatief beschikbaar is.
WCAG 3.3.8 en CAPTCHA
Gebruik je nog een visuele CAPTCHA? Dan heb je minimaal een audio-alternatief nodig. Maar de meest toekomstbestendige route is een overstap naar een methode die helemaal geen cognitieve test vereist. Denk aan een magic link via e-mail, een SMS-verificatiecode of een moderne honeypot-oplossing die bots filtert zonder de gebruiker te hinderen. Dat is beter voor iedereen en voldoet direct aan WCAG 2.2.
Hoe je een formulier stap voor stap toegankelijk maakt
Voeg een zichtbaar label toe aan elk invoerveld
Niet als placeholder, maar als een vaste tekst boven of naast het veld. Koppel het label programmatisch aan het veld via het for-attribuut. Controleer dit door het label te klikken: springt de cursor naar het juiste veld? Dan is de koppeling goed.
Markeer verplichte velden duidelijk
Gebruik een sterretje of het woord "verplicht" en leg bovenaan het formulier uit wat dat teken betekent. Markeer liever optionele velden als "optioneel" als de meeste velden verplicht zijn. Geef nooit verplichte velden alleen aan via kleur.
Test het formulier volledig zonder muis
Leg je muis weg. Navigeer door het volledige formulier met de Tab-toets. Bereik je elk veld? Kun je de datumkiezer, dropdown en bestandsupload ook met het toetsenbord gebruiken? Kun je het formulier versturen met Enter op de verzendknop?
Schrijf foutmeldingen die het probleem en de oplossing beschrijven
Voor elk veld waarbij automatische validatie plaatsvindt: schrijf een foutmelding die het veld noemt, beschrijft wat er fout is en aangeeft hoe het moet worden opgelost. Test of die melding ook wordt voorgelezen door NVDA of VoiceOver.
Controleer het kleurcontrast van alle formulierelementen
Labels en ingevoerde tekst hebben 4,5:1 nodig. Veldgrenzen, radiobuttons en checkboxen hebben 3,0:1 nodig ten opzichte van de achtergrond. Gebruik een contrastmeter zoals de Colour Contrast Analyser van TPGi om dit te meten.
Test met een schermlezer
Zet NVDA (Windows, gratis) of VoiceOver (Mac en iPhone, ingebouwd) aan en vul het formulier in. Hoor je elk label correct? Worden foutmeldingen aangekondigd? Weet je na het afspelen van het formulier welk veld actief is? Pas aan waar nodig.
Formulieren in meerderestappenprocessen
Een checkout, een aanvraagproces of een inschrijfformulier verspreid over meerdere stappen vraagt extra aandacht. Er zijn drie dingen die snel misgaan.
Geen voortgangsindicator. Iemand die een formulier invult, wil weten hoe ver hij is en hoeveel er nog volgt. "Stap 2 van 4" is een kleine toevoeging met grote impact. Zorg dat die indicator ook programmatisch beschikbaar is voor schermleessoftware.
Gegevens opnieuw invoeren die al zijn ingevuld. WCAG 3.3.7 regelt dit nu expliciet: als iemand zijn naam en adres al heeft ingevoerd in stap 1, mag je dat in stap 3 niet opnieuw vragen zonder een manier te bieden om die gegevens over te nemen. "Zelfde als bezorgadres" is een verplichte optie als het factuuradres los staat van het bezorgadres.
Timeout zonder waarschuwing. Als een sessie verloopt terwijl iemand een formulier invult, verliest die persoon zijn ingevulde gegevens. WCAG 2.2.1 vereist dat gebruikers worden gewaarschuwd voordat de sessie verloopt en de mogelijkheid krijgen om die sessie te verlengen.
Tip voor developers
Gebruik standaard HTML-formulierelementen waar mogelijk. Een gewone input, select, textarea en button zijn al toegankelijk in de basis. Je hebt dan geen extra ARIA-attributen nodig. Custom-gebouwde dropdowns, datumkiezers of toggles vereisen altijd handmatig toegankelijkheidswerk. Hoe meer je afwijkt van de HTML-standaard, hoe meer werk je voor jezelf creëert.
Veelgestelde vragen over toegankelijke formulieren
Mijn formulier is kort. Geldt WCAG dan ook?
Ja. WCAG maakt geen onderscheid op basis van de lengte van een formulier. Een contactformulier met twee velden en een verzendknop moet net zo goed toegankelijk zijn als een bestelflow van tien stappen. Juist korte formulieren zijn snel goed te maken.
Wij gebruiken een externe formulierentool. Zijn wij dan verantwoordelijk?
Ja. Als het formulier op jouw website staat, ben jij verantwoordelijk voor de toegankelijkheid ervan. Dat geldt ook als de tool van een externe leverancier komt. Controleer de toegankelijkheid van de tool die je gebruikt en leg toegankelijkheidseisen vast in contracten met leveranciers.
Hoe geef ik een verplicht veld aan zonder sterretje?
Je kunt ook het woord "verplicht" achter het label plaatsen, of bij optionele velden het woord "optioneel" toevoegen als de meeste velden verplicht zijn. Beide werken. Het sterretje is prima zolang je bovenaan het formulier uitlegt wat het betekent. Geef het in elk geval nooit alleen aan via kleur.
Hoe test ik of mijn foutmelding ook wordt voorgelezen?
Zet NVDA of VoiceOver aan, vul het formulier bewust fout in en klik op Verzenden. Een toegankelijke foutmelding wordt direct voorgelezen zonder dat je er handmatig naartoe hoeft te navigeren. Dit werkt alleen goed als de foutmelding via aria-live of focus-management wordt aangekondigd. Als de schermlezer niets zegt, is er iets mis met de implementatie.
Formulieren zijn de plekken waar toegankelijkheid of werkt of niet werkt. Er is geen tussenweg: als het toetsenbord de betaalknop niet bereikt, is de transactie onmogelijk. Als de foutmelding niets zegt, blijft het formulier onaf. Kleine technische keuzes hebben hier een directe menselijke impact.
Meer lezen? Bekijk ook onze praktische formuliertips van Sacha, onze blog over afbeeldingen met tekst en de content-checklist voor webredacteuren. Of volg de training Toegankelijke Formulieren van Cardan.
-1776695356.jpg&w=768&q=80)
.jpg&w=480&q=80)