EN 301 549, WCAG, and the presumption of conformity
By WCAG Auditor · Published · Updated
EN 301 549 is the European standard for ICT accessibility — harmonised under the Web Accessibility Directive, not (yet) under the EAA. Its v3.2.1 revision is already cited in the Official Journal under the Web Accessibility Directive (EU) 2016/2102, where meeting its applicable clauses confers a presumption of conformity. The European Accessibility Act (Directive (EU) 2019/882) does not yet cite a revision: Final draft EN 301 549 V4.1.0 (2026-06), drafted under the Commission’s standardisation request C(2022) 6456, carries the matching Annex ZB, and the presumption of conformity applies under the EAA once a revision is cited in the Official Journal. Until then, an EN 301 549 report is the strongest evidence available, not an EAA presumption.
This article goes one level deeper than What is the European Accessibility Act?: what the standard actually contains, how a conformance report against it is structured, and what “presumption of conformity” precisely does and does not mean today.
Two Directives, one standard
It helps to keep two separate things apart: the legal instrument that requires accessibility, and the technical standard that spells out what accessibility means in testable terms.
EN 301 549 is developed jointly by ETSI, CEN and CENELEC — the three European standards organizations — and it has served as the technical yardstick for more than one EU accessibility law. Today, its v3.2.1 revision is cited in the Official Journal under the Web Accessibility Directive (EU) 2016/2102, which mainly reaches public-sector websites and mobile applications. Meeting v3.2.1’s applicable clauses confers a presumption of conformity with that Directive, right now.
The EAA is a separate Directive with a separate citation. No revision of EN 301 549 has been cited in the Official Journal under it yet. Final draft EN 301 549 V4.1.0 (2026-06) was prepared under the European Commission’s standardisation request C(2022) 6456 and is the first revision to carry the matching Annex ZB for the EAA — but a final draft is not a citation. It has not been adopted by the ETSI/CEN/CENELEC vote, and the resulting final revision, expected as v4.1.1, is expected to reach the Official Journal around October 2026. Until a revision is actually cited under the EAA, meeting EN 301 549’s applicable clauses is evidence of conformance for the EAA, not a presumption under it.
That distinction is not pedantry. A presumption of conformity is a specific legal effect — it shifts the burden of proof — and it attaches to a cited standard revision under a named Directive, not to the standard’s existence in general. Two organizations can both hold a clean EN 301 549 v3.2.1 report and be in a different legal position depending on which Directive their obligation comes from.
Chapters, not just web
EN 301 549 is organized by surface, not by success criterion. A conformance report against it is chapter-by-chapter, covering all ten chapters in which the standard states requirements:
- Chapter 4 — Functional Performance outcomes that apply across ICT, independent of the technology used to deliver them.
- Chapter 5 — Generic requirements that apply to all ICT, regardless of surface.
- Chapter 6 — ICT with two-way voice communication — real-time text, caller ID, video calling, and the alternatives a voice service has to offer.
- Chapter 7 — ICT with video capabilities — caption and audio-description handling in a player, not in the content.
- Chapter 8 — Hardware — physical products, down to reach ranges and tactile controls.
- Chapter 9 — Web content — the chapter most people mean when they say “web accessibility.”
- Chapter 10 — Non-web documents (PDF, office documents, and similar formats).
- Chapter 11 — Software (desktop and mobile applications, as distinct from documents or web pages).
- Chapter 12 — Documentation and support services — the accompanying material and support channels a product ships with, not just the product itself.
- Chapter 13 — Relay and emergency service access — what a communication service owes a user who reaches it through a relay service, or who is calling an emergency number.
That structure is why a “one report fits everything” approach undersells what the standard actually asks for. Our report is surface-aware instead: audit a website and you get chapters 4 + 5 + 6 + 7 + 9 + 12 + 13; audit a document and you get 4 + 5 + 10 + 12; audit an app and you get 4 + 5 + 6 + 7 + 11 + 12 + 13; chapter 8 appears when the ICT being reported on is hardware. Every normative clause of the revision is in the catalog — everything the standard states as a requirement (“shall”) or a recommendation (“should”). What is deliberately left out is the conformance-claim machinery and the Electronic Programme Guide clauses, neither of which a web, document or software audit can speak to. Clauses with no WCAG equivalent are rendered as explicit “manual review required” rows rather than silently dropped from the report — and in chapters 6, 7, 8 and 13 that is every row, because none of those chapters references WCAG at all.
WCAG-mapped, and what isn’t
A meaningful share of the EN 301 549 clause catalog maps directly to WCAG success criteria and can be determined automatically from an audit: 137 of the 273 v3.2.1 catalog clauses carry a WCAG success-criterion link, rising to 157 of the 316 clauses under the v4.1.0 catalog.
The rest of the catalog is not decoration. Clauses with no WCAG equivalent — things like cognitive accessibility expectations, assistive-technology API conformance, and how a product handles user accessibility preferences — are not silently dropped from the report. They are surfaced as “manual review required”, which is a deliberately unglamorous label: it means the report is telling you, clause by clause, exactly where automation’s reach ends and where a human reviewer has to look. A report that quietly omitted those rows would look more complete and be less honest.
This is also where the limits of the presumption of conformity become concrete. Even a clean automated pass through the WCAG-linked clauses does not by itself close the catalog — the manual-review clauses still need attention, and a conformance report that is honest about that gap is more useful than one that isn’t.
Version-aware, not version-frozen
The WCAG ceiling tracks the EN 301 549 revision directly: v3.2.1 maps to WCAG 2.1 AA, v4.1.0 maps to WCAG 2.2 AA. v3.2.1 is the revision cited in the Official Journal today and is our default; v4.1.0 (2026-06) is the ETSI/CEN/CENELEC final draft — not adopted by the vote and not yet cited in the Official Journal, with final v4.1.1 expected from that ballot — and it remains selectable, labelled as a draft in every artefact it appears in so nobody mistakes a draft citation for a settled one.
You select the revision; the report and the EAA-positioned VPAT follow it. That matters in both directions: picking v3.2.1 today keeps a report aligned with the revision that is actually cited and actionable under the Web Accessibility Directive, while picking the v4.1.0 draft gets ahead of the WCAG 2.2 AA ceiling the EAA is expected to eventually cite, at the cost of resting on a standard that is not yet normative. Neither choice is wrong; they answer different questions, and the version label on the artefact says which one you asked.
What a conformance report contains
In practice, “an EN 301 549 report” is shorthand for a small family of related artefacts, each serving a different reader:
- A full EN 301 549 Accessibility Conformance Report, chapter-by-chapter as above, exported as HTML and XLSX — the artefact procurement teams and internal accessibility reviewers actually read line by line.
- An EAA-positioned VPAT, which states the legal basis (Directive (EU) 2019/882), the EN 301 549 revision the report was generated against, and the presumption-of-conformity note scoped correctly to whichever Directive actually cites that revision today.
- An accessibility statement, the kind of accompanying disclosure the EAA expects economic operators to make available alongside a covered product or service.
None of these documents is a substitute for the others, and none of them is a certification — they are evidence, generated from a real audit, that a reviewer or an authority can inspect rather than take on faith.
Reading the standard itself
EN 301 549 is a public ETSI deliverable, and it is worth reading directly rather than only through summaries like this one:
- v3.2.1 (2021-03) — etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf
- v4.1.0 (2026-06) final draft — etsi.org/deliver/etsi_en/301500_301599/301549/04.01.00_30/en_301549v040100va.pdf
What this means in practice
The short version: EN 301 549 v3.2.1 is a live, cited standard today under the Web Accessibility Directive, with a real presumption of conformity attached to it there. The v4.1.0 final draft is where WCAG 2.2 AA and the EAA’s own Annex ZB are heading, but it is not yet a citation, and treating it as one would overstate what it currently is. A version-aware report — one that names which revision it was generated against and states the presumption accurately for that revision — is what lets you act on the standard without overclaiming what it gives you.
This article is informational only, not legal advice; whether a specific report satisfies a specific legal obligation is a determination for your organization. To see what a report against either revision actually looks like, read how we help, check whether you’re in scope for the EAA in the first place, or get in touch.