The European Accessibility Act: What It Means If You Sell Online in the EU
Who it applies to
The European Accessibility Act covers a defined set of products and services offered to consumers in the EU, including e-commerce, consumer banking, e-books, transport ticketing and telecoms. It applies whether or not your company is based in the EU, so a US or Gulf business selling to European consumers is in scope. Micro-enterprises have relief for services under the directive, and national implementations vary in detail, so the specifics for your situation are worth checking with counsel in your main markets rather than assumed.
The standard in practice
Compliance in practice means meeting the harmonised European standard for accessibility, which for websites aligns closely with WCAG level AA. That is a concrete, testable target rather than a vague aspiration. It covers perceivable content such as text alternatives and contrast, operability including full keyboard access, understandable interfaces with clear labels and error messages, and robustness so assistive technologies can interpret your markup. Anyone quoting you for accessibility work should be talking in those terms.
The five failures we find on almost every audit
Insufficient colour contrast, usually on placeholder text, disabled buttons and brand-coloured links. Form inputs without programmatically associated labels, where a visual label sits next to an input with no connection in the markup. Keyboard traps and invisible focus indicators, often introduced by custom dropdowns and modals. Images carrying meaning with empty or auto-generated alt text. And dynamic content — cart updates, validation errors, filter results — that changes silently without announcing itself to a screen reader. None of these are exotic and all of them are cheap to fix during development.
Automated testing catches maybe a third
Tools like axe and Lighthouse are worth running in CI and they will find contrast issues, missing labels and structural problems. They cannot tell you whether your alt text is meaningful, whether the focus order makes sense, or whether a screen reader user can actually complete checkout. Budget for manual testing on the critical journeys with a keyboard and a screen reader, and ideally with users who rely on assistive technology. That is where the findings that matter come from.
Third-party components are your responsibility too
Cookie consent banners, chat widgets, payment iframes, review embeds and video players are common sources of failure, and 'the vendor's widget is inaccessible' is not a defence to a regulator or a customer. Ask vendors for their accessibility conformance documentation before integrating, and test the component in your own page rather than trusting the datasheet. Consent banners are worth special attention because they sit in front of everything else on the site.
Making it stick after the remediation project
A one-off audit and fix decays within a year as new features ship. What keeps it from regressing: automated accessibility checks in the build pipeline, accessibility acceptance criteria in the definition of done, an accessible component library so patterns are right by default, and someone named as owner. Publishing an accessibility statement with a contact route is also required in most implementations and it is a good forcing function, because it means someone has to answer when a user reports a problem.
Have a project that needs this kind of thinking?
Let's talk through what you're building — free consultation, no commitment.
Get in Touch