Een bezoeker heeft een vraag, vult je contactformulier in en drukt op verzenden. Er gebeurt niets. Of er verschijnt een rode rand, zonder uitleg over wat er misging. Voor het team achter de website lijkt het formulier misschien af: de velden zijn gebouwd, de validatie werkt en de berichten worden verwerkt. Voor deze bezoeker is de route naar contact juist afgesloten.
Toegankelijkheid wordt daarom pas echt zichtbaar wanneer je de volledige handeling volgt: van het eerste veld tot de bevestiging dat het bericht is ontvangen. De zeven controles hieronder helpen ontwerpers, developers en productteams om die route te beoordelen. Het is een praktische test, geen volledige WCAG-audit.
Begin bij wat je de bezoeker vraagt
Stel je een eenvoudige contactvraag voor. Is een naam, e-mailadres en bericht voldoende, of moet iemand eerst een telefoonnummer, functie en organisatie invullen? Elk extra veld vraagt aandacht en kan een reden zijn om af te haken. Het W3C adviseert bij formulieren alleen informatie te vragen die nodig is om de taak af te ronden.
Dat is de eerste controle: vraag alleen wat nodig is en geef vooraf aan welke velden verplicht zijn. De tweede volgt direct. Ieder invoerveld heeft een blijvend, begrijpelijk label nodig. Een placeholder met ‘E-mailadres’ verdwijnt zodra iemand typt en is geen vervanging voor een zichtbaar en technisch gekoppeld label.
Wat gebeurt er zonder muis?
De bezoeker gaat naar het eerste veld en gebruikt alleen Tab, Shift+Tab en het toetsenbord. Volgt de focus een logische route? Is steeds zichtbaar welk onderdeel actief is? Kan iemand een keuze wijzigen en het formulier verzenden zonder ergens vast te lopen? Dit is controle drie.
Test niet alleen de invoervelden. Een cookiebanner, spambeveiliging of ingebouwde keuzecomponent kan de route alsnog blokkeren. En wat op een groot scherm overzichtelijk lijkt, kan op een telefoon bij vergrote tekst een heel andere ervaring opleveren. Controle vier is daarom om het formulier op een smal scherm en met vergroting te doorlopen, zonder dat labels, uitleg of de verzendknop onbruikbaar worden.
De foutmelding is onderdeel van de interface
Stel dat de bezoeker het e-mailadres verkeerd invoert. De boodschap ‘Ongeldige invoer’ zegt nauwelijks wat er moet veranderen. ‘Vul een geldig e-mailadres in, bijvoorbeeld naam@organisatie.nl’ geeft wel richting.
Dat is controle vijf: toon fouten als begrijpelijke tekst, verbind de melding met het juiste veld en maak duidelijk hoe iemand verder kan. Vertrouw niet alleen op een rode rand. De W3C-richtlijnen beschrijven dat automatisch gedetecteerde fouten herkenbaar en tekstueel moeten worden toegelicht. Bewaar andere, correct ingevulde gegevens wanneer het verzenden mislukt.
Voor de technische uitwerking van labels, foutmeldingen en focusgedrag heeft Dogteam een afzonderlijke tutorial over toegankelijke formuliervalidatie.
Verzonden is niet hetzelfde als ontvangen
De bezoeker corrigeert het adres en probeert het opnieuw. De knop verandert in een laadindicator. Maar is het bericht nu daadwerkelijk aangekomen? Niet noodzakelijk. De server kan het verzoek afwijzen, een koppeling kan uitvallen of een notificatie kan blijven hangen.
Controle zes is daarom de bevestiging: toon pas een succesbericht nadat de verwerking de inzending heeft geaccepteerd. Maak onderscheid tussen ontvangen, verwerkt en beantwoord. Beloof geen reactietermijn die de organisatie niet kan waarmaken. Controleer bij een end-to-end-test ook of de inzending in het bedoelde systeem terechtkomt.
Test juist de route die mis kan gaan
De zevende controle is niet één extra scherm, maar een verzameling uitzonderingen. Verzend een leeg formulier, probeer een ongeldig adres, gebruik een lang bericht en simuleer een tijdelijke serverfout. Herhaal belangrijke handelingen met toetsenbord en schermlezer. Noteer browser, apparaat, gebruikte hulpmiddelen en de problemen die openblijven.
Een geautomatiseerde toegankelijkheidsscan is hierbij nuttig, maar laat niet zelfstandig zien of een bezoeker zijn vraag zonder hulp kan verzenden. Betrek waar mogelijk mensen met verschillende beperkingen bij gebruikerstests.
Maak de complete route onderdeel van oplevering
Een formulier is niet af omdat de frontend, het ontwerp en de backend ieder afzonderlijk hun taak hebben afgerond. Het is af wanneer de volledige gebruikersroute aantoonbaar werkt: duidelijke vragen, gekoppelde labels, toetsenbordbediening, herstelbare fouten en betrouwbare terugkoppeling na verzending.
Leg die eigenschappen vast als acceptatiecriteria en herhaal de tests na wijzigingen aan formulieren, plugins, spambeveiliging en externe koppelingen. De centrale vraag is niet of de verzendknop werkt, maar of iedere bezoeker het contactmoment zelfstandig kan afronden.
Wanneer inzendingen naar een CRM of ander proces moeten worden doorgestuurd, hoort ook aflevercontrole bij het ontwerp. Onze sponsor BlazeForce beschrijft integraties en automatisering; een koppeling vervangt de toegankelijkheidscontroles uit dit artikel niet.
Bronnen
- W3C WAI — Forms Tutorial
- W3C WAI — Labeling Controls
- W3C WAI — User Notifications
- W3C WAI — Validating Input
- WCAG 2.2 — Error Identification
Neem contact met ons op
Vertel ons waarmee we kunnen helpen; we reageren binnen twee werkdagen.
