EN 301 549 Explained in Plain English
If you've read anything about the European Accessibility Act, you've probably seen EN 301 549 mentioned as "the standard" businesses need to meet. It sounds bureaucratic, and the full document is genuinely dense — but the part that matters for a typical website or app is narrow and well defined. Here's what it actually says.
What EN 301 549 is
EN 301 549 is a European standard — "Accessibility requirements for ICT products and services" — jointly maintained by three European standards bodies (ETSI, CEN, and CENELEC). It was originally written to cover public procurement, giving EU governments a common accessibility bar for the technology they buy. When the European Accessibility Act was drafted, it adopted EN 301 549 as the technical standard used to demonstrate legal conformance — so a standard originally built for procurement now doubles as the practical compliance benchmark for private businesses too.
The standard is broad by design, because "ICT products and services" covers everything from websites and mobile apps to hardware like ATMs, ticket machines, and set-top boxes. Most clauses in the document deal with hardware, real-time communication (video relay, captioning), and documents — none of which apply to a typical commercial website. The clauses that matter for a website or web app are a much smaller, well-scoped subset.
Relationship to WCAG
This is the part that makes EN 301 549 manageable: for web content, EN 301 549 doesn't invent its own rules — it incorporates WCAG 2.1 at the AA conformance level by reference. Clause 9 of the standard ("Web") maps directly onto WCAG 2.1's success criteria, level A and AA.
Practically, this means:
- If your website meets WCAG 2.1 AA, you meet the web-content portion of EN 301 549.
- Native mobile apps are covered too, under a related clause ("Software") that applies the same underlying success criteria to non-web software.
- You don't need to separately learn a distinct "EN 301 549 checklist" for your website — our WCAG 2.1 AA checklist covers the substance of what's required.
This is a deliberate design choice: EU regulators wanted a technical standard tied to an internationally recognised, actively maintained benchmark (WCAG) rather than a separate EU-only rulebook that would need constant upkeep.
Which clauses matter for websites
Out of a lengthy standard, the sections a website operator actually needs to care about are:
- Web (clause 9): the core clause for website and web application accessibility, mapping to WCAG 2.1 A/AA. This is the one to focus on for a marketing site, e-commerce store, or web app.
- Software (clause 11): relevant if you ship a native mobile or desktop app rather than, or in addition to, a website.
- Documentation and support services (clause 12): relevant if you publish user guides, help documentation, or support content that needs to remain accessible.
- Generic requirements and relay/emergency service access (clauses 5 and 13): mostly relevant to hardware and telecoms providers rather than a typical website, but worth a scan if you offer real-time communication features like live chat.
If you're running an e-commerce store, SaaS product, or content site, the Web clause — and by extension, WCAG 2.1 AA — is where nearly all of your practical work will be.
It's also worth knowing that EN 301 549 is periodically revised to track updates to WCAG. When WCAG gains a new version, the standard is amended to reference it, which is one reason regulators favour this approach: the technical bar keeps pace with current best practice instead of freezing at whatever was current when the directive was written. For a business, this means treating accessibility as an ongoing practice rather than a box you tick once — the same posture you'd take with any other evolving compliance requirement, like data protection or product safety.
How conformance is claimed
EN 301 549 doesn't come with an official EU certificate you apply for. Conformance is a self-declared, evidence-backed claim, similar to how CE marking works for product safety: you test against the standard, keep records of what you tested, fix what fails, and publish, or be ready to produce, a statement of conformance.
A defensible EN 301 549 / WCAG 2.1 AA conformance record typically includes:
- An automated scan report covering your key pages and user flows.
- Manual test notes for keyboard navigation, screen reader behaviour, and forms.
- A dated log of issues found and fixed.
- A public accessibility statement, which several member states expect as part of demonstrating good-faith compliance.
This is exactly the record you'll want if a national market surveillance authority ever asks questions — see our guide on how to check if your website is EAA compliant for a step-by-step process, or get a free automated baseline scan to see where your site currently stands against EN 301 549 and WCAG 2.1 AA.