EN 301 549 v4.1.1 Moved European Accessibility to WCAG 2.2: What to Ship Now vs. What the Law Says Today

EN 301 549 v4.1.1 was published on September 2, 2026 and moves Europe's technical accessibility benchmark from WCAG 2.1 Level AA to WCAG 2.2 Level AA — but it is not the legal reference yet. Until the European Commission cites it in the Official Journal of the EU, the version that still counts is v3.2.1 from 2021, built on WCAG 2.1 AA. The correct read is a split: audit and report against WCAG 2.1 AA today, build and test against WCAG 2.2 AA plus the new clause 9.7 starting this sprint.

Both halves of the confusion are already circulating. Vendors announce that "the EAA now requires WCAG 2.2." Product teams keep filing WCAG 2.1 audits as if nothing moved. Each is partly right and neither is complete. Here is what changed, what already binds you, and what does not.

What changed on September 2, 2026

ETSI, CEN and CENELEC adopted the text on 24 August 2026 and published it on September 2: 276 pages that become the current technical edition of EN 301 549, following v3.2.1. Four changes matter if you build websites:

• Clauses 9 (web), 10 (non-web documents) and 11 (software) now reference WCAG 2.2. For web pages that means every Level A and AA criterion in WCAG 2.2 — six criteria beyond the 2.1 baseline.
• Success Criterion 4.1.1 Parsing is marked "Void" because WCAG 2.2 removed it. That does not make broken markup acceptable; it means it is no longer an audited criterion.
• User preferences are restructured into three parallel clauses: 9.7 (web pages), 10.7 (documents) and 11.7 (software). It is a requirement WCAG does not have.
• Mapping annexes are added: ZA to the Web Accessibility Directive and ZB to the European Accessibility Act, plus a new Clause A.2 for product- and service-level assessment. Clause 6.2 on real-time text is substantially revised — that part lands on telecom and hardware, not marketing sites.

We last covered standards evolution looking forward, in WCAG 3.0 in draft. WCAG 3.0 still has no date. This, by contrast, is already published.

Two timelines your team must not merge

This is the line between a serious compliance conversation and a mistranslated headline. Engineering and law are running on different clocks:

The milestones, as the standard itself states them: adoption 24 August 2026, publication 2 September 2026, national announcement (doa) 30 November 2026, national publication or endorsement 31 May 2027, withdrawal of conflicting national standards 31 May 2028.

On the Official Journal citation, be honest about the evidence. Deque states v4.1.1 is "on track to be cited around November 30, 2026" — exactly the standard's own doa date. Skeptical legal analysis has spent months pointing out that no EAA citation date has a primary source behind it, and that fourteen months after the Directive became applicable there was not a single harmonised standard cited in the Official Journal in its support. Practical conclusion: treat the date as a probable scenario, not a release deadline to hang a plan on.

There is also a detail that pulls the other way: in some member states national law references EN 301 549 without a version number. When that happens, a newly published version can become the operative standard with no new legislation. Waiting for the citation is not the conservative position it looks like.

The six new criteria, translated into code changes

This is where the standard stops being a legal document and enters your backlog. Patterns we have fixed again and again in audits:

None of the six is exotic. All of them attack the same endemic disease: interfaces drawn with divs and JavaScript that ignore what the user already brought to the page. That is why the path of least resistance is still the one we described in goodbye ARIA, native HTML: native elements first, JavaScript only where it earns its place.

Clause 9.7: the rule that is not in WCAG

This is what almost everyone misses when they read the press release. v4.1.1 does not merely absorb the six WCAG 2.2 criteria; it adds a web-specific requirement with no WCAG equivalent: do not block or override the user agent modes that present your page according to the user's accessibility settings, unless that is essential to the function.

NOTE 5 of the clause gives the concrete list: colour filters, contrast, text size, pointer size, text cursor. And the standard explicitly warns against specifications that override user settings by name — it calls out the CSS property forced-color-adjust, limiting it to essential cases.

In plain terms: you are not asked to build anything, you are asked to stop breaking what the user already switched on. It is the cheapest requirement in the entire standard if your CSS is written in rem and free of !important collisions.

What already binds you, citation or not

Here is the part that surprises clients waiting for the citation before acting. The obligation does not come from the technical standard; it comes from the Directive, and it has been in force since 28 June 2025. The standard only defines how conformity is presumed. While v3.2.1 remains cited, what you must pass today is WCAG 2.1 AA plus the WCAG 2.2 criteria already part of everyday practice: 1.4.4 Resize Text (200% without loss), 1.4.10 Reflow (320 CSS px without two-dimensional scrolling) and 1.4.12 Text Spacing.

The regulatory climate does not allow sleeping on it. The Dutch regulator ACM found in its March 2026 market scan that placing an order with assistive technology was impossible on 61% of the largest online shops tested, and expects to move to formal enforcement in the second half of 2026. Penalties are set member state by member state, with published ranges from €60,000 in Ireland to €100,000 in Germany and up to €300,000 per violation in France. For the failure patterns that show up most often, see our EAA enforcement piece with its prioritization framework.

How we sequence it on real projects

Our rule — an opinion, not a citation: do not buy a WCAG 2.1 audit and present it as 2027-ready evidence. The four phases we run:

1. Inventory and applicability map (1 week). Web, apps inside web views, PDFs and Office documents, authentication journeys and support channels. Record why each clause applies or does not apply: the standard is conditioned on "Where ICT…", and a credible assessment justifies every case.
2. Clause-level gap analysis against the final text (2 weeks). Do not stop at the six criteria: 9.7, 10.7, Annex ZB and Clause A.2 belong in the same analysis.
3. Design system rules (ongoing). Visible, unobscured focus, target size, alternatives to dragging, consistent help, redundant entry, accessible authentication and platform preference support. This is system work, not page work.
4. Acceptance criteria and testing (every release). Automated plus keyboard, screen reader, zoom, reflow and a one-at-a-time preferences pass. An automated scan validates none of the new criteria — the standard says so itself by requiring task-based evaluation.

The output of phases 1 and 2 is what lets you defend a position with date, reviewer and archived evidence — the format that matters when someone asks "are we covered?". And if the business case interests you, accessibility as competitive advantage explains why the cost of waiting always exceeds the cost of moving early.

Frequently asked questions

Should I migrate everything to WCAG 2.2 now? Yes for construction and design; not yet for compliance claims. Building to 2.2 AA is the cheap decision today and becomes mandatory on citation. Claiming "conforming with v4.1.1" early is a statement you cannot support.

Does this replace WCAG 3.0? No. WCAG 3.0 is still a draft with its graduated scoring model and Bronze/Silver/Gold levels. V4.1.1 is the jump from 2.1 to 2.2; 3.0 is a different conversation, and having it too early only dilutes the work that has to happen this quarter.