EN 301 549 v3.2.1 → v4.1.1: what actually changes

EN 301 549 has a new line in the pipeline, and “v4” already gets used loosely — to mean the final draft published in June 2026, the eventual final revision, or just “the next version” in general conversation. Only one of those is real today: Final draft EN 301 549 V4.1.0 (2026-06). This article is about what changes between v3.2.1, the revision our reports default to, and that draft — clause by clause, not vibes.

Status first: draft, not standard

Final draft EN 301 549 V4.1.0 (2026-06) is titled a “Harmonised European Standard”, prepared under the European Commission’s standardisation request C(2022) 6456 for Directive (EU) 2019/882 (the European Accessibility Act), and submitted for the ETSI/CEN/CENELEC vote. As of this writing it has been adopted by no ballot and is not cited in the EU Official Journal. The revision that ballot is expected to produce carries the version number v4.1.1, expected to reach the Official Journal around October 2026 — “expected”, because a standardisation vote can still amend text before publication, and because publication dates for harmonised standards slip.

Two consequences follow directly from that status. First, nothing in v4.1.0 confers a presumption of conformity under the EAA today: the presumption that exists right now runs through v3.2.1, cited in the Official Journal under the Web Accessibility Directive (EU) 2016/2102, not under the EAA. Second, whatever eventually ships as v4.1.1 could still differ from v4.1.0 in wording, even where the clause numbers and success-criteria mappings below hold — a final draft is exactly that, a draft.

What the catalogs contain, and what they leave out

Both of our EN 301 549 catalogs now carry every normative clause of their revision — every requirement the standard states as a “shall”, and every recommendation it states as a “should”. For v3.2.1 that is 273 clauses, of which 137 carry a direct WCAG success-criterion link and are determined automatically from an audit; the rest are surfaced honestly as manual-review items rather than silently dropped. The v4.1.0 catalog is 316 clauses, 157 of them WCAG-linked.

What is deliberately absent from both: container headings, clauses the standard itself marks “(informative)” or “Void”, the conformance-claim machinery (clause 9.6 and its v4 siblings), and the Electronic Programme Guide clauses v4 numbers 12.4 and 12.5 — an EPG is not something a web, document or software audit can speak to. Every number in this article describes the catalogs on that basis, not a count of every numbered line in the published deliverable.

Six new success criteria arrive in chapter 9

The headline content change is in chapter 9 (Web): v4 folds in six WCAG 2.2 success criteria that v3.2.1, built against WCAG 2.1, does not carry.

None of these six replace an existing v3.2.1 row; they are pure additions. An audit scored clean against v3.2.1 chapter 9 has said nothing about any of them, one way or the other.

Mirrored into chapter 10, not fully into chapter 11

EN 301 549’s structure repeats web-content requirements into chapter 10 (non-web documents) and chapter 11 (software) wherever they still make sense off the web. All six of the new criteria are mirrored into chapter 10. Chapter 11 gets only five: v4 marks 11.3.2.6 Consistent Help as Void, because the requirement is written in terms of a set of web pages sharing a help mechanism, and a single piece of software isn’t that. There is no chapter-11 row for Consistent Help in v4, and there shouldn’t be — don’t go looking for one, and don’t add one to a local tracker expecting it to reconcile against the catalog.

4.1.1 Parsing is Void in v4 — and it was never in our catalogs

The other direction of travel: v4 marks 9.4.1.1 Void, and its mirrors 10.4.1.1 and 11.4.1.1 with it. The standard states why in a note of its own — earlier revisions referenced the 4.1.1 Parsing success criterion from WCAG 2.0 and WCAG 2.1, and WCAG 2.2 removed that criterion “because the accessibility problems it was intended to prevent ‘either no longer exist or are addressed by other criteria’”.

Worth being straight about what that means for our reports, because it cuts against the version you asked for: neither of our catalogs carries Parsing, not even the v3.2.1 one, where the published standard does state it normatively. That is a deliberate call, not an omission — the criterion is retired upstream, and a row whose own standards body says the problem it tested is gone is not a row we will ask a reader to remediate. The consequence is visible in the artefact: an ACR generated against v3.2.1 has no Parsing line. If you need a literal clause-for-clause v3.2.1 report for a procurement checklist that still enumerates it, that is the one row you will have to account for by hand.

What has not gone away is the underlying defect class. Duplicate id attributes and broken nesting are still reported by the engine — as the rule violations they are, under the criteria that do still exist — rather than under a criterion neither WCAG 2.2 nor v4 recognises.

2.5.5 is still Void — don’t confuse it with 2.5.8

It’s easy to see “Target Size” land as a v4 addition and assume the older, stricter WCAG 2.1 criterion — 2.5.5 Target Size (Enhanced), the 44×44-pixel one — came along with it. It didn’t. 9.2.5.5 and 11.2.5.5 are marked Void in both revisions, v3.2.1 and v4.1.0 alike. What v4 adds is only the Minimum variant, 2.5.8, at the smaller 24×24 threshold and AA rather than AAA. If you were tracking 2.5.5 as “coming in v4”, stop — it was never in scope for either revision of this catalog, and it isn’t in scope now.

Chapter 6 is rewritten around real-time text

The largest structural change outside chapter 9 is one that no WCAG-driven summary will mention, because none of it maps to a success criterion: chapter 6, two-way voice communication, goes from 17 normative clauses to 38 in our catalogs. If you ship calling, meetings, a contact-centre client or anything that carries a conversation, this is the chapter that changed under you.

Three shifts, all at once:

• A new 6.0 block defines what the chapter applies to. v4 opens with eight applicability clauses — 6.0.2 Communication client, 6.0.3 Communication system, 6.0.4 System connecting to another communication system, 6.0.5 System with roaming visiting client, and 6.0.6 to 6.0.9, which carry the same distinctions into emergency communications. v3.2.1 left the reader to infer which of its requirements attached to the client, the network, or both.
• Voice splits into four leaves. v3.2.1’s single 6.1 becomes v4’s “Real-time bidirectional voice communication”, with 6.1.1 Voice communication interoperability, 6.1.2 Audio bandwidth for capture and presentation, and two recommendations: 6.1.3, audio presentation in attached listening devices, and 6.1.4, synchronization of subtitles.
• RTT stops being a corner of the chapter and becomes the bulk of it. v3.2.1 states real-time text in 6.2.1.1, 6.2.1.2, 6.2.2.1 to 6.2.2.4, 6.2.3 and 6.2.4. v4 keeps that spine, adds 6.2.1.3 (single user action) and 6.2.2.5 (review of RTT communication contents), and then adds six top-level clauses that did not exist at all: 6.2.5 adding and erasing of RTT input, 6.2.6 processing rate, 6.2.7 character representation, 6.2.8 RTT input methods, 6.2.9 RTT media establishment and use, and 6.2.10 RTT interoperability. Total conversation gains two of its own — 6.7.1 provision and 6.7.2 interoperability.

None of chapter 6 carries a WCAG success criterion, in either revision. That is not a gap in the catalog; it is what the chapter is. Every one of those 38 rows reaches an ACR as an explicit manual review required row, which is the honest answer for a requirement no page-level scan can determine — and a reason a v4 ACR for a communication product is a materially longer document to work through than its v3.2.1 predecessor.

Chapter 12 is rebuilt, not patched

Chapter 12 (Documentation and support services) doesn’t get a delta in v4 — it gets replaced. v3.2.1’s four leaf requirements — 12.1.1, 12.1.2, 12.2.2, 12.2.3, 12.2.4, nested under “12.1 Product documentation” and “12.2 Support services” — are gone. v4 restructures the chapter into three flat clauses that our catalog carries: 12.1 Accessible Information About Products, 12.2 Accessible Information About Services, and 12.3 Accessibility and Compatibility Features. If you’re diffing an old chapter-12 finding against a new one, match by subject, not by clause number — the numbering scheme changed underneath it.

v4 also adds 12.4 and 12.5, covering Electronic Programme Guides. Those two sit outside our catalog’s subset scope on purpose: an EPG isn’t a web page, a document, or installed software, so none of our three audit surfaces can speak to it, and we’re not going to add rows we can’t determine, or flag as anything but permanently “manual review required” for a surface we don’t audit at all.

Authoring tools move to clause 5.10

One renumbering is worth calling out on its own, because it moves chapters, not just clause numbers: v3.2.1’s 11.8.2 (authoring-tool requirements, filed under chapter 11 Software) becomes v4’s 5.10.2, under a new clause 5.10 “Authoring tools” (5.10.1–5.10.5) in chapter 5 (Generic). The content the clause tests doesn’t change; where it lives in the document — and therefore which chapter’s report section it shows up in — does.

Terminology: captions become subtitles, and some titles get more specific

A handful of retitles carry no scoring change but are worth knowing before they surprise you in a diff:

• v4 renames “Captions” to “Subtitles” throughout (9.1.2.2 and its mirrors), aligning EN 301 549’s vocabulary with EU usage rather than the US-inflected “captions”.
• 5.1.2.2 gains “and closed functionality” in its title.
• 10.3.1.1 and 11.3.1.1 spell out the surface in their titles rather than leaving it implicit.

None of these change what the clause tests. They change what it’s called, which matters the moment you’re grepping an old report for a phrase that no longer appears in the new one.

Annex ZA vs Annex ZB — the legally interesting part

This is the part of the v4 story that actually matters for compliance, as opposed to test scope. EN 301 549 v3.2.1 carries Annex ZA, which maps its clauses to the Web Accessibility Directive (EU) 2016/2102 — that annex is what makes v3.2.1’s citation in the Official Journal do legal work, conferring a presumption of conformity with that Directive. Final draft EN 301 549 V4.1.0 (2026-06) is the first revision in the v4 line to carry an Annex ZB, mapping its clauses to the EAA’s essential requirements instead.

Having the annex is not the same as having legal effect. A revision only starts conferring a presumption of conformity once it is actually cited in the Official Journal under the relevant Directive — for v3.2.1 that citation exists today, under the Web Accessibility Directive; for any v4-line revision, EAA-scoped, it doesn’t yet. Annex ZB is the mapping that would make a future citation useful; it is not the citation itself. Meeting v4.1.0’s applicable clauses today is reasonable, well-documented evidence of conformance with the EAA’s essential requirements — but it is not a presumption under the EAA, and it won’t be until a v4-line revision is actually cited.

You audited against v3.2.1 in 2025 — what do you actually re-test?

If you already hold an EN 301 549 v3.2.1 report, the honest answer is: less than the clause count difference makes it look like. The renumbering (11.8.2 → 5.10.2) and the retitles (captions/subtitles, the closed-functionality and surface-specific titles) don’t change what was tested — a finding against the old clause ID maps cleanly onto the new one. The chapter 12 restructure is informational rather than WCAG-linked, so there’s no automated score to re-run there either; it’s a matter of re-mapping existing documentation-and-support findings onto the three new headings.

What’s genuinely new work is the six WCAG 2.2 success criteria in chapter 9, mirrored into chapters 10 and 11 as described above. If your product wasn’t built with dragging alternatives, redundant-entry avoidance, or non-cognitive authentication paths in mind — and most products built before WCAG 2.2 existed weren’t — that’s real re-testing, not paperwork. Budget for it as six new checks per applicable surface, not as a wholesale re-audit.

One exception to the “less than it looks” rule: if your product carries a conversation — calling, meetings, a contact-centre client — chapter 6 is not a re-map, it is 21 additional clauses to answer, none of which any scan can determine for you. The Parsing row, meanwhile, moves the other way: whatever a v3.2.1 checklist said about 9.4.1.1 stops being a finding you owe anyone.

Timing, and what to do now

Today, v3.2.1 remains the revision cited in the Official Journal and our default. v4.1.0 is a final draft: real enough to test against, not yet normative anywhere, and labelled as a draft in every artefact it appears in. The ETSI/CEN/CENELEC ballot is expected to produce v4.1.1, expected in the Official Journal around October 2026 — at which point the presumption-of- conformity question above gets a real answer, one way or another, and this article gets an update.

Until then, the sensible move is to know the delta rather than wait for it. You can generate a report against v3.2.1 today, with the v4.1.0 catalog already available to select alongside it — so you can see, clause by clause, which of your existing findings survive the renumbering and which six new checks you’d need to close before a v4-line revision becomes the one that matters. See How we help for what that report contains, or get in touch if you want to talk through which revision makes sense for your timeline.

Informational only — not legal advice.