Accessible contact forms and the European Accessibility Act

A contact form is often the only door between a visitor and your business. If that door can only be opened with a mouse, good eyesight and the patience to solve a blurry picture puzzle, some people simply stay outside. Since mid-2025 this is no longer just a usability question: for many businesses selling to consumers in the EU, it has become a legal one.

What the European Accessibility Act covers

The European Accessibility Act (Directive (EU) 2019/882) has applied since 28 June 2025. It sets accessibility requirements for certain products and services offered to consumers – among them e-commerce, consumer banking services, e-books, electronic communications and parts of passenger transport. For a website, that means the online shop or banking service as a whole, including the forms customers use to contact you, ask questions or complain. Micro-enterprises that provide services are exempt: businesses with fewer than ten employees and an annual turnover or balance sheet total of no more than EUR 2 million. Offers aimed purely at other businesses are generally outside its scope.

Each member state has transposed the directive into national law. In Germany it is the Barrierefreiheitsstärkungsgesetz (BFSG), in Poland a 2024 act on ensuring that certain products and services meet accessibility requirements. Supervisory authorities and penalties differ from country to country, but the technical yardstick is broadly the same: in practice the European standard EN 301 549, which in turn builds on the Web Content Accessibility Guidelines (WCAG).

Why it pays off even without a legal duty

Maybe your business is exempt, or you only serve other companies. Accessible forms are still worth it, for a simple reason: every person who gives up halfway is an enquiry you never receive. The fixes that help a screen reader user also help someone filling in the form on a phone on a train, in bright sunlight, with a broken wrist or in a second language. Clear labels and helpful error messages mean fewer abandoned forms for everyone – and none of them make your spam protection weaker.

A practical checklist with WCAG 2.2 references

• Visible labels tied to their inputs (1.3.1, 3.3.2): every field has a visible label connected to it via for/id. A placeholder alone is not a label – it disappears as soon as someone starts typing.
• Error messages that explain the fix (3.3.1, 3.3.3): name the field, say what is wrong and how to correct it – in text, not only with a red border. “Please enter an e-mail address like name@example.com” beats “Invalid input”.
• Full keyboard operation (2.1.1, 2.1.2): every field, checkbox, CAPTCHA and the submit button can be reached and used with Tab, Space and Enter, without keyboard traps.
• Visible focus (2.4.7): you can always see which field is active. Removing the browser’s focus outline without a replacement fails this criterion.
• Sufficient contrast (1.4.3): text, labels and error messages have a contrast ratio of at least 4.5:1 against the background (3:1 for large text).
• Target size (2.5.8): buttons, checkboxes and links are at least 24 × 24 CSS pixels, or have enough spacing around them.
• CAPTCHA alternatives (1.1.1) and accessible authentication (3.3.8): 1.1.1 requires a text alternative and the CAPTCHA in more than one sensory form; 3.3.8 strictly covers log-in steps, but its idea carries over – a puzzle such as retyping distorted letters or solving a sum should not be the only way through. Offer an alternative or use a method that needs no puzzle at all.
• Honeypots hidden from assistive technology: the trap field gets aria-hidden="true" on its wrapper and tabindex="-1", so screen reader and keyboard users never land in it.

CAPTCHAs and honeypots: where spam protection meets accessibility

Strictly speaking, criterion 3.3.8 is about log-in and authentication steps, not contact forms. The idea behind it carries over well, though: typing distorted letters, solving a sum or picking traffic lights from a grid of images shuts some people out completely. Options that usually work without any puzzle – such as Cloudflare Turnstile, Friendly Captcha, a honeypot combined with a time check, or server-side filtering like Akismet – keep spam out without asking visitors to prove anything. A honeypot is only friendly if it is truly invisible, to screen readers and keyboard users as well:

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

Test your own form in fifteen minutes

1. 1Put the mouse aside and fill in the whole form using only the keyboard. Can you reach every field and the submit button, and can you always see where you are?
2. 2Submit the form empty, then with a wrong e-mail address. Do the errors appear as text next to the right field, and is it clear what to do?
3. 3Open the page on a phone or zoom the browser to 200%. Is everything readable, are the buttons easy to tap, and does a cookie banner or chat widget cover the submit button?
4. 4Turn on a screen reader (VoiceOver, NVDA or TalkBack) and listen: is every field announced with its label, and does the honeypot stay silent?
5. 5Run an automated check such as axe-core. It finds missing labels and contrast problems quickly, but not everything – the manual steps above are still needed.

If you would rather start with an overview, formexposed looks at your public forms from the outside, without submitting anything. Its accessibility checks run axe-core on each form, flag CAPTCHAs without an accessible alternative and honeypots that screen readers announce, and look at the form on a phone – tap targets, overlays covering the submit button, horizontal scrolling. The free check shows the overall level; these details are in the full report. It is a good starting point for the list above, not a replacement for testing with real people.