De toegankelijke enquête: formulieren die iedereen kan invullen

Je kunt nette vragen schrijven en toch het antwoord kwijtraken. Als een respondent het label niet kan zien, of niet kan zien welk keuzerondje hij net heeft geselecteerd, stuurt hij je geen slechte data. Hij stuurt niets. En hij is weg voor het eerste diagram laadt. Toegankelijkheid is het deel van enquêteontwerp dat bepaalt wie überhaupt kan antwoorden.

Een ontoegankelijke enquête vertekent je resultaten

Ongeveer één op de zes mensen leeft met een beperking. Nog meer lezen je formulier op een telefoon in fel zonlicht, of vullen het met één hand in de trein. Elk van hen is een respondent die jij hebt uitgenodigd. Als het formulier alleen werkt met een muis en behoorlijk zicht, haakt de groep die afhaakt niet willekeurig af. Die mensen verschillen van de mensen die wél doorkomen, dus hun afwezigheid buigt het resultaat in een richting die je niet kunt zien of achteraf corrigeren. Dat heet non-responsvertekening. Het zit precies naast de antwoorden van lage kwaliteit die je al uitfiltert: allebei zijn ze redenen waarom een netjes ogend exportbestand toch misleidend kan zijn.

Er is ook een juridische kant. De Europese Toegankelijkheidsrichtlijn geldt sinds 28 juni 2025 en trekt veel digitale diensten in de richting van een technische standaard die de rest van het veld al gebruikt: WCAG, de Web Content Accessibility Guidelines. Section 508 en de ADA doen hetzelfde in de Verenigde Staten. De huidige versie is WCAG 2.2, een W3C-aanbeveling herzien in december 2024. Niveau AA is wat bijna iedereen bedoelt als ze "toegankelijk" zeggen. Je hoeft het niet uit je hoofd te leren. De controles hieronder sluiten erop aan.

Geef elk veld een echt label

De meest voorkomende fout in enquêteformulieren is de placeholder als label gebruiken: een veld met vage grijze tekst "Jouw e-mail" en niets erboven. Het ziet er opgeruimd uit. Dan begint de respondent te typen, de hint verdwijnt, en iedereen die even pauzeerde heeft de enige aanwijzing verloren over wat het veld wilde. Het grijs op wit haalt het contrastminimum ook zelden. Sommige schermlezers kondigen placeholdertekst helemaal niet aan. Het veld klinkt dan als "bewerken, leeg".

Een label is een zichtbaar stuk tekst dat aan zijn invoerveld is gekoppeld. Klikken erop focust het veld, en een schermlezer leest de twee samen voor. Zet het boven het vak. Wil je een formaat of voorbeeld tonen, doe dat dan in aparte hulptekst bij het veld. Dit is WCAG 3.3.2, en het kost één regel opmaak.

Matrixvragen zijn waar schermlezers vastlopen

Een raster met stellingen aan de zijkant en een beoordelingsschaal bovenaan werkt goed op een breed scherm en is een nachtmerrie via een schermlezer. Ziende respondenten kijken één keer naar de kolomkoppen, dan werken ze de rijen af. Een schermlezer kijkt niet. Hij belandt op het derde keuzerondje in rij vier en kondigt, tenzij je het raster zorgvuldig hebt gebouwd, aan "keuzerondje, niet geselecteerd" zonder enige aanwijzing over welke stelling of welk punt op de schaal dat is.

Elke optie in het raster heeft een toegankelijke naam nodig die beide stukken bevat: de rij waartoe hij behoort en de waarde die hij vertegenwoordigt. "Het dashboard is gemakkelijk te navigeren, helemaal mee eens" kan worden beantwoord. Een kaal keuzerondje niet. Als je dat niet kunt garanderen, splits de matrix dan in losse vragen, één stelling per keer. Dat leest ook beter op een telefoon, waar het raster toch al zou instorten. Meer scrollen, veel minder misverstanden. Duidelijke formulering helpt hier ook: een matrix gebouwd uit vragen die elk op één beslissing gericht zijn is al korter van zichzelf.

Zorg dat elke schaal met het toetsenbord werkt

Sterrenwaarderingen en emoji-schuifregelaars zijn meestal de mooiste bedieningselementen in een enquête. Ze zijn ook het minst bruikbaar. Te vaak zijn het klikbare afbeeldingen of kale div-elementen met een klikverwerker, dus ze werken met een muis en verder niets. Een toetsenbordgebruiker tabt er gewoon langs.

WCAG 2.1.1 is duidelijk: alles moet met het toetsenbord werken. De betrouwbare manier om een beoordelingsvraag te bouwen is met echte keuzerondjes die eruitzien als sterren of cijfers. De browser geeft je dan toetsenbordfocus en pijltjestoetsselectie gratis. Schuifregelaars zijn het moeilijkst goed te krijgen, want de waarde moet worden aangekondigd terwijl hij verandert en in enkele stappen bereikbaar zijn. Voor een aanbevelingsscore van 0 tot 10 zijn gewone keuzerondjes altijd beter. Haal je hand van de muis en probeer de vraag zelf uit.

Groepeer de opties zodat de vraag meereist

Keuzerondjes en selectievakjes zijn een set, en ze moeten als één worden aangekondigd. Als een groep opties niet aan zijn vraag is gekoppeld in de opmaak, leest een schermlezer elke keuze op zichzelf voor: "Jonger dan 18. 18 tot 24. 25 tot 34." De persoon hoort een lijst met leeftijden zonder idee wat er wordt gevraagd. Wikkel elke set zo in dat de vraagtekst de groepsnaam wordt en de opties erin zitten. Elke optie wordt dan voorgelezen als "Hoe oud bent u, 25 tot 34" en de vraag reist mee met het antwoord. Dit is de mechanica achter WCAG 1.3.1: onzichtbaar, totdat iemand de lay-out niet kan zien die de betekenis droeg.

Kleur mag nooit het enige signaal zijn

Kleur is een aanvulling op de boodschap, en voor veel mensen valt die aanvulling weg. Een verplicht veld met alleen een rood sterretje bestaat niet voor een kleurenblinde respondent. Een fout die alleen door een rode rand wordt aangeduid ook niet. Rood-groen kleurenblindheid alleen al treft ongeveer één op de twaalf mannen. Zet een woord naast de kleur: schrijf "verplicht" en markeer een geselecteerde optie met een vinkje naast de kleurwisseling. Controleer ook het contrast. Broodtekst heeft een verhouding van minimaal 4,5 op 1 nodig ten opzichte van de achtergrond onder WCAG 1.4.3, en dat vage grijze placeholder-grijs haalt die drempel bijna nooit.

Schrijf foutmeldingen die zeggen wat er moet worden opgelost

Het ergste moment in een ontoegankelijk formulier: je kunt niet verder en je weet niet waarom. Een verplichte vraag is overgeslagen, je drukt op volgende, en de pagina staat er, of hij scrolt ergens naartoe waar je niet naar kijkt. Voor een schermlezergebruiker die geen aankondiging hoorde, is de enquête nu kapot zonder uitleg.

Verschuif de focus naar het eerste veld dat niet klopte. Een toetsenbordgebruiker belandt dan op het probleem in plaats van ernaar te zoeken. Noem het veld en de oplossing in de foutmelding zelf: "Vraag 4 moet worden beantwoord voordat je verder kunt" is beter dan "ongeldige invoer". Dat is wat WCAG 3.3.1 en 3.3.3 vragen: identificeer de fout, stel de oplossing voor.

Geef onthulde vragen een stem

Conditionele logica is een van de beste dingen die je voor de responsekwaliteit kunt doen, en een van de gemakkelijkste om ontoegankelijk te maken. Wanneer een antwoord een vervolgvraag onthult, ziet een ziende respondent die inschuiven. Een schermlezergebruiker ziet dat standaard niet: de focus blijft waar hij was, er wordt niets aangekondigd, en een hele vraag gaat ongehoord voorbij. Als je een enquête vertakt, laat de nieuwe vraag zichzelf dan aankondigen en verplaats de focus ernaar. Houd verborgen vragen buiten de tabvolgorde totdat ze van toepassing zijn, zodat niemand naar een veld buiten beeld tabt. Dezelfde conditionele logica en feedback die de responsekwaliteit verhoogt, is precies wat mensen vasthoudt als de onthulling stil is.

Houd de focus zichtbaar en in volgorde

De tabvolgorde moet de leesvolgorde volgen, zodat de focus het formulier afgaat zoals het oog dat doet, niet naar een losstaande knop ergens. En het gefocuste element heeft een zichtbare omlijning nodig. Browsers geven die standaard mee, en te veel ontwerpen verwijderen hem, waardoor een toetsenbordgebruiker geen cursor heeft. WCAG 2.2 voegde een verwante regel toe (2.4.11): wat je ook focust, het mag niet achter een vaste koptekst of een cookiebanner verdwijnen. Heeft je enquête een vaste bovenbalk, zorg dan dat een gefocust veld er vrij van scrolt.

Respecteer de tijd en de duimen van mensen

Sommige enquêtepanels plaatsen een timer op een pagina of laten de sessie na een bepaalde tijd verlopen. Een harde time-out straft mensen die meer tijd nodig hebben: iemand die een schakelaaronderdeel gebruikt, of iemand die elke regel via een schermlezer leest. WCAG 2.2.1 vraagt je te waarschuwen voordat de tijd om is en mensen het te laten verlengen. Op telefoons is er ook een fysiek probleem. Een dicht raster van kleine keuzerondjes is een doel dat geen duim goed kan raken. WCAG 2.2 stelde een ondergrens in van 24 bij 24 CSS-pixels voor een interactief doel in criterium 2.5.8. Geef de opties ruimte. Gebruik je een sleep-om-te-rangschikken-vraag, voeg dan een alternatief toe voor mensen die niet kunnen slepen, want een sleepbeweging is een drempel op zichzelf.

Laat de browser de saaie velden invullen

Demografische vragen vragen om dezelfde dingen als elk formulier: naam, e-mail, postcode, land. WCAG 1.3.5 zegt die velden te voorzien van hun doel, zodat de browser en elk hulpinstrument ze automatisch kunnen invullen en echt typen besparen voor iemand die dat moeilijk vindt. WCAG 2.2 voegde een begeleidende regel toe, 3.3.7, tegen het opnieuw laten invoeren van informatie die je al in hetzelfde proces hebt verzameld. Als je enquête op pagina één een e-mailadres heeft opgehaald, vraag er dan niet opnieuw om op pagina vier. Elk veld dat je vooraf kunt invullen of weglaten, is één ding minder om doorheen te worstelen.

Test het zoals een respondent dat zou doen

Dit werkt alleen als je het echt probeert.

• Koppel de muis los en bereik elke vraag, elke optie en de verzendknop met Tab en de pijltjestoetsen.
• Zet VoiceOver aan op een Mac of NVDA op Windows en doorloop één complete run met het scherm uit.
• Zoom de pagina naar 200 procent en kijk wat overstroomt of verborgen raakt.
• Voer axe of Lighthouse uit voor de mechanische controles, maar vertrouw daarna de handmatige pass meer dan de geautomatiseerde score.

Geautomatiseerde tools vangen misschien een derde van de problemen op. De rest heeft een mens aan het toetsenbord nodig. Doe dit vóór de lancering, want als een enquête eenmaal live is, zijn de formulering en structuur feitelijk bevroren, en een correctie halverwege splits je data.