What the European Accessibility Act Actually Requires From Your Website

The European Accessibility Act (Directive (EU) 2019/882, "EAA") has applied since 28 June 2025. It is the first EU-wide law that pushes accessibility requirements onto private-sector digital products and services — not just government websites. If you sell to consumers in the EU, it very likely reaches you.

Who it covers

The EAA targets a defined list of products and services rather than "every website". On the digital side, the ones most businesses need to worry about are:

• E-commerce — consumer-facing online shops and checkout flows.
• Banking and payment services — consumer banking, and the payment terminals and apps around it.
• E-books and their reading software.
• Transport — websites, apps and ticketing for air, bus, rail and waterborne travel.
• Electronic communications and access to audiovisual media services.

There is a narrow exemption for microenterprises (fewer than 10 people and under €2m turnover) that provide services — but it does not extend to microenterprises that manufacture or sell covered products, and it is narrower than most people hope. Do not assume you are exempt without checking.

What "accessible" means here

The EAA itself is written in terms of functional outcomes, but in practice conformance is demonstrated against the harmonized European standard EN 301 549. For the web, EN 301 549 maps to the Web Content Accessibility Guidelines (WCAG) at Level AA — currently WCAG 2.1, with WCAG 2.2 alignment progressing. Meeting WCAG 2.2 AA is the pragmatic target that keeps you ahead of the standard.

That covers the familiar four principles: content that is perceivable (text alternatives, contrast, captions), operable (keyboard access, visible focus, no traps), understandable (clear labels, predictable navigation), and robust (valid markup, correct ARIA, assistive-technology compatibility).

The paperwork regulators expect

Compliance is not only about the code. The EAA regime expects an evidence trail:

• An accessibility statement describing how the service meets the requirements, which parts do not yet, and why.
• A feedback mechanism so users can report barriers and request content in an accessible form.
• Internal records showing you assessed the service and are maintaining it over time.

Market-surveillance authorities in each member state can request this documentation. "We think it's fine" is not a defence; a dated, specific record is.

What to do now

Start by scoping which of your services are in scope, run a baseline audit against WCAG 2.2 AA, fix the highest-impact issues first, and publish an honest accessibility statement. Then keep it current — accessibility regresses every time you ship.

This article is general information, not legal advice. And a note we repeat everywhere: automated testing reliably catches roughly 30–40% of WCAG issues. It is the fast, repeatable floor — full conformance still needs manual review and assistive-technology testing.