EN 301 549 explained plainly for web teams
Somewhere in almost every European accessibility conversation, the string "EN 301 549" appears, usually without explanation. It is cited in procurement documents, referenced by two EU directives, and named in accessibility statements, yet very few people who build websites have read it. The good news: for web work, you only need to understand its structure and one chapter.
What the document is
EN 301 549, formally "Accessibility requirements for ICT products and services", is a European harmonized standard produced jointly by ETSI, CEN, and CENELEC. Harmonized is a term of art: when EU law says a product or service must be accessible, conforming to the harmonized standard creates a legal presumption that you meet the law. The standard is the bridge between legislative language ("services shall be perceivable, operable, understandable and robust") and something an engineer can test.
The current version relevant to most obligations is EN 301 549 v3.2.1 (2021). It is freely downloadable from ETSI, which is unusual and welcome; most standards live behind paywalls.
What it covers, beyond the web
The scope is all of ICT, which explains the document's size. Its chapters cover, among other things:
- Hardware, from payment terminals to laptops (chapter 8)
- Web content (chapter 9)
- Non-web documents such as PDFs (chapter 10)
- Software, including native mobile apps (chapter 11)
- Documentation and support services (chapter 12)
- Two-way communication and video capabilities (chapters 6 and 7)
This breadth is why the standard backs both the Web Accessibility Directive for the public sector and the European Accessibility Act for consumer products and services: one reference document, many product types.
Chapter 9, the only chapter most web teams need
Chapter 9 does something pragmatic: rather than inventing European web rules, it incorporates the WCAG 2.1 success criteria at Levels A and AA, nearly verbatim. Requirement 9.1.4.3 is WCAG 1.4.3 Contrast. Requirement 9.2.1.1 is WCAG 2.1.1 Keyboard. The numbering simply prefixes a 9.
Two consequences follow. First, if your site conforms to WCAG 2.1 Level AA, you conform to chapter 9. There is no secret extra European web requirement hiding in the standard. Second, all the practical knowledge, tooling, and documentation built around WCAG applies directly. An audit against WCAG 2.1 AA is an audit against EN 301 549 chapter 9.
The subtlety worth knowing: chapters 10 and 11 apply the same WCAG-derived requirements to documents and software. If you publish PDFs or ship a mobile app, those chapters bring them into scope too, which pure WCAG conformance claims about "web pages" can quietly miss.
Annex A, the compliance map
For anyone preparing formal documentation, Annex A is the most useful part of the standard. Its tables map each requirement to the legal obligations of the Web Accessibility Directive, stating which requirements are necessary for presumption of conformity. When a public tender asks you to declare EN 301 549 conformance, Annex A tells you exactly which rows you are declaring.
Where you will encounter the standard in practice
- Public sector work. Every EU public body's website must conform, and their accessibility statements cite the standard by name. Agencies with government clients inherit the requirement.
- The EAA. Since June 2025, in-scope private services (e-commerce above the microenterprise threshold, banking, transport, and more) get their presumption of conformity from this standard.
- Procurement. Both public tenders and, increasingly, large private RFPs name EN 301 549 as a technical specification. Suppliers sign contracts promising it.
- VPATs and ACRs. The international edition of the Voluntary Product Accessibility Template includes an EN 301 549 section, so software vendors selling into Europe document against it.
Testing against it without drowning
Treat the standard as a citation, and WCAG as the working document. A defensible testing approach for a website:
- Run automated detection for the criteria software can verify, which covers roughly half of the AA set: contrast, missing labels, name and role of controls, structure.
- Review the human-judgment criteria manually: focus order, error handling quality, consistency, meaningful sequence.
- Record results per criterion, with dates and the engine version, so your conformance claim traces to evidence.
- Repeat on a cadence, because conformance decays as sites change.
That loop is what Complaudax automates the bookkeeping for: audits run in your own browser session, including on authenticated pages, results persist per client and site, the manual criteria live in a tracked checklist, and the resulting report cites what was tested and when. If a client contract names EN 301 549, that report is your Annex A story in plain language, and the free plan is enough to produce your first one.
The standard's reputation for impenetrability is mostly undeserved page count. For the web, the summary fits in a sentence: EN 301 549 means WCAG 2.1 AA, formally cited, with your documents and apps included.