The European Accessibility Act is here: a developer's field guide

What the EAA actually is

The European Accessibility Act (Directive (EU) 2019/882) is an EU directive that harmonizes accessibility requirements for a defined set of products and services sold to consumers in the EU. Each member state transposed it into national law, and those national laws have applied to new products and services since 28 June 2025.

Two things make it different from earlier EU accessibility rules:

• It targets the private sector. The earlier Web Accessibility Directive covered public-sector bodies. The EAA covers banks, shops, publishers, and transport operators.
• It applies regardless of where you're based. A US or UK company selling an in-scope service to EU consumers is in scope, the same way GDPR reached across borders.

Who is in scope

The directive lists the covered services explicitly. The ones most relevant to software teams:

• E-commerce — any website or app through which consumers conclude contracts. This is the catch-all that pulls in most companies.
• Consumer banking services — online banking, payment interfaces, identification methods.
• E-books and reading software.
• Electronic communications — messaging and calling services.
• Audiovisual media services — streaming platform interfaces.
• Passenger transport services — booking sites, e-ticketing, real-time travel information.

What "accessible" means: EN 301 549 and WCAG

The EAA's annexes describe functional requirements — perceivable, operable, understandable, robust — but don't name WCAG. The practical bridge is the harmonized European standard EN 301 549. Conforming to a harmonized standard gives you a presumption of conformity with the directive.

For web content and most app UIs, EN 301 549's requirements incorporate WCAG 2.1 Level AA. So the working translation for a development team is:

If your product meets WCAG 2.1 AA, you have a defensible, standards-backed claim of EAA conformity for its digital interface.

Note the version: the legal baseline today is WCAG 2.1 AA, not 2.2. But WCAG 2.2 is backwards-compatible — everything that passes 2.2 AA passes 2.1 AA — so targeting 2.2 AA future-proofs you for the expected update of EN 301 549.

What enforcement looks like

Because the EAA is a directive, enforcement is national. Member states designate market surveillance authorities, and penalties vary — fines in the tens of thousands of euros in some states, with the possibility of orders to withdraw a non-conforming service from the market. Beyond regulators, the directive explicitly allows consumers and disability organizations to take action under national law.

The realistic near-term risk for most companies isn't a surprise raid — it's a complaint-driven investigation, a procurement requirement you can't satisfy, or a competitor's accessibility statement making yours look absent.

A practical first-90-days plan

1. Establish your baseline. Run an automated WCAG 2.1 AA scan across your main user flows. Automated checks catch roughly a third of WCAG issues — but it's the third that's cheapest to fix and the fastest way to see the shape of your debt.
2. Fix the structural offenders first. Missing form labels, missing alt text, keyboard traps, and contrast failures are high-frequency, high-impact, and largely mechanical to fix.
3. Put checking in the development loop. A violation that never reaches a pull request never reaches an auditor. Real-time IDE scanning plus a CI gate keeps the baseline from eroding.
4. Do a manual pass on critical flows. Checkout, login, account management — test with keyboard only and with a screen reader. Automated tools can't judge whether your alt text is useful or your focus order makes sense.
5. Write your accessibility statement. The EAA expects you to document how your service meets the requirements. An honest statement with a known-issues list beats a perfect-sounding one you can't defend. If you'd rather have it drafted by a specialist from audited evidence, that's a service we offer.

The part nobody says out loud

Most teams treat the EAA the way they treated GDPR in 2018: panic, a consultant, a PDF, silence. The teams that came out of GDPR well were the ones that turned the requirement into engineering practice. Accessibility is the same shape of problem — and unlike cookie banners, the work genuinely improves your product for every user with a temporary injury, an aging parent's tablet, or bright sunlight on a phone screen.