Toegankelijke contactformulieren en de Europese toegankelijkheidswet

Een contactformulier is vaak de enige deur tussen een bezoeker en uw bedrijf. Als die deur alleen open kan met een muis, goede ogen en het geduld om een wazige beeldpuzzel op te lossen, blijven sommige mensen gewoon buiten staan. Sinds medio 2025 is dat niet langer alleen een kwestie van gebruiksvriendelijkheid: voor veel bedrijven die aan consumenten in de EU verkopen, is het een juridische kwestie geworden.

Wat de Europese toegankelijkheidswet omvat

De Europese toegankelijkheidswet (Richtlijn (EU) 2019/882) is sinds 28 juni 2025 van toepassing. Zij stelt toegankelijkheidseisen aan bepaalde producten en diensten die aan consumenten worden aangeboden – waaronder e-commerce, bancaire diensten voor consumenten, e-books, elektronische communicatie en delen van het personenvervoer. Voor een website betekent dat de webwinkel of de bankdienst als geheel, inclusief de formulieren waarmee klanten contact met u opnemen, vragen stellen of klagen. Micro-ondernemingen die diensten verlenen, zijn vrijgesteld: bedrijven met minder dan tien werknemers en een jaaromzet of balanstotaal van niet meer dan 2 miljoen euro. Aanbiedingen die uitsluitend op andere bedrijven zijn gericht, vallen in de regel buiten het toepassingsgebied.

Elke lidstaat heeft de richtlijn in nationaal recht omgezet. In Duitsland is dat het Barrierefreiheitsstärkungsgesetz (BFSG), in Polen een wet uit 2024 die waarborgt dat bepaalde producten en diensten aan toegankelijkheidseisen voldoen. Toezichthouders en sancties verschillen per land, maar de technische maatstaf is grotendeels dezelfde: in de praktijk de Europese norm EN 301 549, die op zijn beurt voortbouwt op de Web Content Accessibility Guidelines (WCAG).

Waarom het ook zonder wettelijke plicht loont

Misschien is uw bedrijf vrijgesteld, of bedient u alleen andere bedrijven. Toegankelijke formulieren zijn toch de moeite waard, om een eenvoudige reden: elke persoon die halverwege afhaakt, is een aanvraag die u nooit ontvangt. De verbeteringen die een schermlezergebruiker helpen, helpen ook iemand die het formulier invult op een telefoon in de trein, in fel zonlicht, met een gebroken pols of in een tweede taal. Duidelijke labels en behulpzame foutmeldingen betekenen voor iedereen minder afgebroken formulieren – en geen ervan maakt uw spambescherming zwakker.

Een praktische checklist met WCAG 2.2-verwijzingen

• Zichtbare labels die aan hun invoervelden zijn gekoppeld (1.3.1, 3.3.2): elk veld heeft een zichtbaar label dat er via for/id mee is verbonden. Een placeholder alleen is geen label – die verdwijnt zodra iemand begint te typen.
• Foutmeldingen die de oplossing uitleggen (3.3.1, 3.3.3): noem het veld, zeg wat er mis is en hoe het te corrigeren – in tekst, niet alleen met een rode rand. “Voer een e-mailadres in zoals naam@voorbeeld.nl” is beter dan “Ongeldige invoer”.
• Volledige bediening met het toetsenbord (2.1.1, 2.1.2): elk veld, elk vakje, de CAPTCHA en de verzendknop zijn met Tab, spatiebalk en Enter te bereiken en te bedienen, zonder toetsenbordvallen.
• Zichtbare focus (2.4.7): u kunt altijd zien welk veld actief is. De focusrand van de browser verwijderen zonder vervanging voldoet niet aan dit criterium.
• Voldoende contrast (1.4.3): tekst, labels en foutmeldingen hebben een contrastverhouding van ten minste 4,5:1 ten opzichte van de achtergrond (3:1 voor grote tekst).
• Doelgrootte (2.5.8): knoppen, vakjes en links zijn ten minste 24 × 24 CSS-pixels groot, of hebben voldoende ruimte eromheen.
• CAPTCHA-alternatieven (1.1.1) en toegankelijke authenticatie (3.3.8): 1.1.1 vereist een tekstalternatief en de CAPTCHA in meer dan één zintuiglijke vorm; 3.3.8 gaat strikt genomen over inlogstappen, maar het idee is overdraagbaar – een puzzel zoals vervormde letters overtypen of een som oplossen mag niet de enige weg zijn. Bied een alternatief aan of gebruik een methode die helemaal geen puzzel nodig heeft.
• Honeypots verborgen voor hulptechnologie: het valveld krijgt aria-hidden="true" op zijn omhulsel en tabindex="-1", zodat schermlezer- en toetsenbordgebruikers er nooit in terechtkomen.

CAPTCHA’s en honeypots: waar spambescherming en toegankelijkheid elkaar raken

Strikt genomen gaat criterium 3.3.8 over inlog- en authenticatiestappen, niet over contactformulieren. Het onderliggende idee is echter goed overdraagbaar: vervormde letters overtypen, een som oplossen of verkeerslichten aanklikken in een raster van afbeeldingen sluit sommige mensen volledig buiten. Opties die meestal zonder puzzel werken – zoals Cloudflare Turnstile, Friendly Captcha, een honeypot gecombineerd met een tijdcontrole, of filtering aan de serverkant zoals Akismet – houden spam buiten zonder bezoekers te vragen iets te bewijzen. Een honeypot is alleen vriendelijk als hij echt onzichtbaar is, ook voor schermlezer- en toetsenbordgebruikers:

<div class="hp" aria-hidden="true">
  <label for="hp-website">Laat dit veld leeg</label>
  <input type="text" id="hp-website" name="website"
         tabindex="-1" autocomplete="off">
</div>
<!-- CSS: .hp { position: absolute; left: -10000px; } -->

Test uw eigen formulier in een kwartier

1. 1Leg de muis weg en vul het hele formulier alleen met het toetsenbord in. Kunt u elk veld en de verzendknop bereiken, en ziet u altijd waar u bent?
2. 2Verzend het formulier leeg, en daarna met een onjuist e-mailadres. Verschijnen de fouten als tekst naast het juiste veld, en is duidelijk wat u moet doen?
3. 3Open de pagina op een telefoon of zoom de browser in tot 200%. Is alles leesbaar, zijn de knoppen makkelijk aan te tikken, en bedekt een cookiebanner of chatwidget de verzendknop?
4. 4Zet een schermlezer aan (VoiceOver, NVDA of TalkBack) en luister: wordt elk veld met zijn label voorgelezen, en blijft de honeypot stil?
5. 5Voer een geautomatiseerde controle uit, zoals axe-core. Die vindt ontbrekende labels en contrastproblemen snel, maar niet alles – de handmatige stappen hierboven blijven nodig.

Begint u liever met een overzicht, dan bekijkt formexposed uw openbare formulieren van buitenaf, zonder iets te verzenden. De toegankelijkheidscontroles draaien axe-core op elk formulier, signaleren CAPTCHA’s zonder toegankelijk alternatief en honeypots die schermlezers voorlezen, en bekijken het formulier op een telefoon – tikdoelen, overlays die de verzendknop bedekken, horizontaal scrollen. De gratis controle toont het algemene niveau; deze details staan in het volledige rapport. Het is een goed uitgangspunt voor de lijst hierboven, geen vervanging voor testen met echte mensen.