The European Accessibility Act Is Live. Here’s What It Asks of Your Product.

For most of the web's history, accessibility in Europe was something public bodies owed and private companies promised. That changed on June 28, 2025. From that date the European Accessibility Act applies to a defined list of products and services sold to EU consumers: e-commerce, consumer banking, e-books and readers, passenger transport booking, electronic communications, computers, smartphones, and self-service terminals such as ATMs and ticket machines.

I have shipped consumer flows for telecom and automotive brands with audiences in the tens of millions. The lesson I keep relearning is that accessibility failures rarely look dramatic in a design review. They show up as a checkout that quietly converts worse for a group of people nobody was measuring. The Act turns that quiet loss into a legal exposure. That is the useful way to read it: not as a new compliance chore, but as a deadline that forces a product team to finish work it should already have done.

Who is actually in scope

Three questions settle most cases. Do you sell to consumers in the EU? Is what you sell on the list? And are you a microenterprise? The Act exempts businesses with fewer than ten employees and annual turnover or balance sheet no higher than €2 million, but only for services. A company that makes a covered product gets no such exemption, however small it is.

Being outside the EU does not help if your customers are inside it. A US store shipping to Germany is placing a service on the EU market. And "not on the list" is not a free pass either: enterprise buyers, public-sector tenders and US litigation under the ADA increasingly ask for the same standard anyway.

What “accessible” means in practice

The Act describes outcomes, not code. Information must be perceivable, operable, understandable and robust. In practice, member states and the Commission point to the harmonised standard EN 301 549, whose web requirements map to WCAG 2.1 Level AA. The current W3C recommendation, WCAG 2.2, adds criteria that matter for commerce in particular: focus that is not hidden behind sticky headers, target sizes that a shaking hand can hit, and authentication that does not depend on solving a puzzle or remembering a code.

Two less technical duties catch teams out. Services must publish information about how they meet the requirements, usually as an accessibility statement. And the obligation covers the whole service, including the parts you bought: a third-party payment frame, a booking widget or a chat-only support tool that cannot be used by keyboard is your failure, not your vendor's.

I made the longer argument for treating access as product quality in Accessibility Is a Product Decision, Not a Final Audit. The Act is that argument with a regulator attached.

Why an overlay will not save you

The fastest-selling "solution" is a script that adds a toolbar and promises compliance. It cannot fix a checkout whose error messages are not announced, whose buttons have no names, or whose focus order jumps around the page. Those are properties of the underlying code. Disability advocates have criticised overlays for years, and US plaintiffs have sued sites that had them installed. Spend the money on fixing the journey instead.

A 30-day plan that starts where the money is

Week one: pick the journey. Not the homepage. The path from finding a product to the confirmation email. Run it with a keyboard only, then at 200% zoom, then with a screen reader. Write down every point where you got stuck.

Week two: fix what blocks completion. Missing labels, unannounced errors, focus traps, colour-only cues. These are usually small code changes with a large effect. Use the same habit I describe in The Best Product Decision Might Be a Smaller Bet: fix one step, retest, ship.

Week three: deal with the vendors. Ask every embedded supplier for their conformance report (a VPAT or EN 301 549 statement). Where they cannot provide one, plan a replacement.

Week four: publish and listen. Write an honest accessibility statement: what works, what does not yet, when it will, and how to report a barrier. Then make sure someone reads those reports.

Accessible pages also tend to be better structured for machines. Real headings, labelled controls and text instead of images are exactly what search engines and AI assistants read, a point I make in the AI search guide. Fixing the journey for people improves it for crawlers as well.

Sources

• EUR-Lex: Accessibility of products and services (summary of Directive 2019/882)
• European Commission: European Accessibility Act
• CCPC (Ireland): EAA guidelines for microenterprises
• W3C: WCAG 2.2

Across the series

• Your Visitors Already Said No. Is Your Site Listening?
• Seats, Usage or Outcomes: Pricing an AI Product Without Losing Your Margin
• Your AI Chat Box Is Probably Unusable With a Screen Reader
• Can You Train AI on Your Customers’ Data? Ask Them First
• Roadmapping When the Model Gets Better Every Seven Months
• Accessibility Testing: A Green Scan Is Not a Finished Journey
• AI Data Retention: ‘Not Used for Training’ Does Not Mean Deleted
• Agent Evaluation: The Demo Worked. Can You Ship It?