Guides › EN 301 549 explained: the standard behind the EAA

EN 301 549 explained: the standard behind the EAA

7 min read Reviewed 2026-08-22

The European Accessibility Act never mentions WCAG. EN 301 549 is the document that connects the directive's abstract language to something an engineer can actually implement.

What EN 301 549 is

EN 301 549 is the European harmonised standard for accessibility requirements in ICT products and services. It is published jointly by the three European standards organisations — ETSI, CEN and CENELEC — and it is considerably broader than web content. It covers hardware, software, documentation, support services, two-way voice communication and non-web documents.

For most companies caught by the EAA, only a slice of it is relevant: clause 9, which deals with web content. Clause 10 covers non-web documents such as PDFs, and clause 11 covers software including mobile apps.

Its relationship to WCAG

Clause 9 does not reinvent anything. It adopts the WCAG 2.1 Level A and Level AA success criteria essentially verbatim, restating each one as a numbered requirement. WCAG 1.4.3 Contrast (Minimum) becomes EN 301 549 clause 9.1.4.3, with the same normative text.

So when a lawyer says "EN 301 549" and a developer says "WCAG 2.1 AA", for web content they are talking about the same set of requirements. The difference is entirely one of legal register.

Clause 11, for software and mobile apps, does the same thing with WCAG criteria adapted to a non-web context, plus some additional software-specific requirements around platform accessibility services and user preferences.

Presumption of conformity

Harmonised standards work through a mechanism called presumption of conformity. Where a standard has been cited in the Official Journal of the European Union in support of a piece of legislation, meeting the standard means you are presumed to meet the corresponding legal requirements.

This is worth understanding properly, because it cuts both ways:

• You are not legally obliged to use the harmonised standard. The directive's requirements are functional, and you can meet them another way.
• But if you do use it, the burden shifts. An authority challenging you has to show that the standard itself does not deliver the directive's requirements — a much harder argument than showing you failed a specific criterion.
• If you go your own way, the entire burden of demonstrating equivalence sits with you, for every requirement, at the moment someone asks.

In practice, almost nobody chooses the second path.

The parts that are not WCAG

If your service is only a website, clause 9 is most of your obligation. But EN 301 549 reaches further than teams often expect:

• Clause 10 — non-web documents. Your PDFs. Invoices, terms, product sheets, downloadable guides. An inaccessible PDF behind an accessible page is still a failure, and PDFs are routinely the weakest part of an otherwise decent site.
• Clause 11 — software. Native mobile apps are in scope on their own terms, not via the web clause.
• Clause 12 — documentation and support. Your help centre and your support channels have to be accessible too. A perfectly accessible checkout paired with support that is only reachable by voice call is not a coherent position.
• Clause 6 — two-way voice communication, if you provide it: relay service compatibility, real-time text, caller identification.

Versions and WCAG 2.2

EN 301 549 has been revised several times, and version numbers matter when you are writing a conformance claim. The version that aligns with WCAG 2.1 Level AA is the one that has underpinned European accessibility legislation for the current cycle, and WCAG 2.1 AA remains the practical target for EAA compliance today.

WCAG 2.2 adds a small number of further criteria — notably around focus visibility, target size, authentication that does not depend on memory, and redundant data entry. Standards work to align the European standard with WCAG 2.2 has been underway, and the harmonised reference is expected to move in that direction in due course.

The pragmatic advice: build to WCAG 2.1 AA because that is what you are measured against today, and treat the 2.2 additions as forward-looking. They are sensible improvements and mostly cheap to adopt while you have the code open. Before publishing a formal conformance claim, check which version is currently cited in the Official Journal — that is the authoritative answer, and it changes.

Last reviewed 2026-08-22. Standards references change; verify the currently cited version before relying on it in a formal conformance claim.