CAPTCHA verhindert aanvragen: onderzoek de afweging

De toegankelijkheidstutorial over formulieren van W3C (https://www.w3.org/WAI/tutorials/forms/) zet een paar uitgangspunten op een rij. Vraag alleen wat nodig is, want overbodige vragen vergroten de kans op afhaken. Label elk veld, geef instructies, meld fouten met uitleg om ze te herstellen, en leg liever geen tijdslimiet op. Is een limiet nodig, bijvoorbeeld om beveiligingsredenen, dan moet de gebruiker die kunnen uitschakelen of verlengen.

Geen van de bronnen in dit artikel bespreekt CAPTCHA bij naam. Je behandelt de CAPTCHA daarom als één extra formulierbesturing en toetst die aan dezelfde principes. De bronnen bewijzen niet dat een bepaald CAPTCHA-type toegankelijk of ontoegankelijk is. Dat onderzoek je op jouw eigen formulier. Een botvrij formulier of juridische zekerheid kun je met deze procedure niet aantonen.

Werk in volgorde, zodat je achteraf kunt vergelijken wat je gewijzigd hebt.

1. Noem het doel van het formulier, bijvoorbeeld offerteaanvraag of contact, en de pagina's waar het staat.
2. Leg een uitgangssituatie vast uit je eigen bronnen: ontvangen aanvragen, herkende spamberichten en meldingen van mensen die niet konden versturen. Kies de periode vooraf en gebruik later dezelfde.
3. Vul het formulier zelf in op desktop en mobiel, één keer enkel met het toetsenbord.
4. Maak opzettelijk fouten: leeg versturen, ongeldig e-mailadres, de CAPTCHA fout beantwoorden, de pagina een tijd laten staan. Doe dit bij voorkeur in een testomgeving of met duidelijk gemarkeerde testberichten, zodat er geen echte opvolging of dubbele aanvragen ontstaan. Controleer ook of een foutmelding of time-out na het versturen toch een opgeslagen aanvraag betekent, zodat opnieuw proberen geen dubbele aanvraag geeft.
5. Laat een tweede persoon het formulier invullen zonder uitleg, bij voorkeur iemand die een hulpmiddel gebruikt.
6. Noteer elke bevinding in het beslisblad uit sectie 5 en wijzig daarna telkens één ding.

Loop de volgende vragen af en noteer bij elke vraag wat je zag, niet wat je vermoedt.

• Toetsenbord: kun je de CAPTCHA bereiken, bedienen en verlaten zonder muis, en zie je waar de focus staat?
• Label en instructie: staat er bij de CAPTCHA tekst die uitlegt wat je moet doen, zoals de tutorial voor andere velden vraagt?
• Foutmelding: zegt de melding wat er mis ging en hoe je het herstelt? Blijven de al ingevulde velden behouden?
• Tijd: verloopt de controle als iemand traag typt, en kan die dan verlengd of vernieuwd worden?
• Alternatief: bestaat er een tweede route, zoals een telefoonnummer of e-mailadres, als de controle niet lukt?

Een mislukking in één van deze punten bewijst nog niet dat je aanvragen verliest. Ze toont wel waar je het volgende onderzoek richt.

MDN legt in het artikel over clientzijdige validatie (https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/Form_validation) uit dat controle in de browser een eerste check is voor gebruiksgemak. Het is geen volledige beveiliging, want een kwaadwillende kan het netwerkverzoek aanpassen. Voer daarom ook controles op de server uit.

Voor jouw afweging betekent dat: weet in welke laag je spamfilter zit. Een stap die enkel in de browser draait, dekt een rechtstreeks verzoek niet. Maak een lijstje van mogelijke aanvullende maatregelen, zoals een verborgen lokveld, een snelheidslimiet per afzender of een filter op de server. Geen enkele garandeert een spamvrije mailbox, en elke maatregel kan echte berichten blokkeren. Test dus bij elke maatregel ook of een legitiem bericht doorkomt. Controleer bij een verborgen lokveld bovendien dat het niet in de leesvolgorde van een schermlezer terechtkomt.

Fictief overdrachtsvoorbeeld. Invoer: een contactformulier met naam, e-mail, bericht en CAPTCHA. De tester gebruikt enkel het toetsenbord, laat de CAPTCHA fout en verstuurt. Verwachte technische controles: verschijnt een foutmelding bij het juiste veld, krijgt dat veld de focus, zijn naam, e-mail en bericht nog aanwezig en kan het formulier opnieuw verstuurd worden? Noteer per punt ja, nee of onzeker, met datum, browser en apparaat, zodat een collega de test kan herhalen.

Herhaal na elke aanpassing exact dezelfde testlijst. De cursus Learn Forms van web.dev (https://web.dev/learn/forms) bevat modules over het testen van formulieren, toegankelijkheid, beveiliging en het testen op verschillende apparaten en platformen. Gebruik die als ruggensteun voor je eigen testscript: minstens één mobiel toestel, minstens twee browsers en één doorloop met enkel toetsenbord.

Vergelijk daarna de uitgangssituatie met dezelfde periodedefinitie. Het resultaat blijft onzeker, want seizoen, campagnes en spamgolven schuiven mee. Spreek daarom vooraf af bij welke bevinding je de wijziging terugdraait, bijvoorbeeld bij een nieuw toegankelijkheidsprobleem of een legitiem bericht dat geblokkeerd werd.

Wil je weten welke publieke signalen je website nu toont rond formulieren en conversie? Bekijk ze via Marketing Scan. Een publieke scan meet alleen wat zichtbaar is en voert niet alle controles uit deze gids voor je uit.