EN 301 549 is about to move to WCAG 2.2. Six criteria, one date, and one requirement that disappears.

Published 21 August 2026.

If you are working to the European Accessibility Act, the standard you are working to is EN 301 549 V3.2.1 (2021-03), and it adopts WCAG 2.1. That is true today. It is scheduled to stop being true near the end of 2026.

Here is what changes, what does not, and the one thing worth doing about it now.

The date, and why it is the only date that matters

A standard becomes a legal obligation in the EU when it is cited in the Official Journal, not when the body that wrote it publishes it. That distinction is the whole story here.

So the standard itself now exists in final form. What is left is the step that carries the legal weight: delivery to the European Commission and citation in the Official Journal. Published estimates for the citation date currently sit between 30 November and 16 December 2026, and they have already moved by weeks as the standard worked through review. For one point of comparison, V3.2.1 was published in March 2021 and cited about five months later; on that precedent alone the date could slip into 2027. Treat the quarter as the plan and the day as provisional.

Until that citation happens, V3.2.1 is the yardstick and WCAG 2.2 criteria are good practice rather than obligations. Anyone selling you WCAG 2.2 remediation as a legal requirement today is ahead of the law. Anyone telling you to ignore 2.2 is setting you up to do the work twice.

What actually changes

Clauses 9, 10 and 11 — web, non-web documents and software — move from WCAG 2.1 to WCAG 2.2 Level AA. For clause 9, that is six new success criteria at A and AA.

3.2.6 Consistent Help (Level A)

If you offer a help mechanism — contact details, a chat widget, a help link — it has to appear in the same relative order across pages. In practice this is a layout consistency rule, and most sites with a stable header already pass it. The ones that fail are the ones where help moves into a hamburger on some templates and not others.

3.3.7 Redundant Entry (Level A)

Do not ask for the same information twice in one process. If the user typed their address at step two, step four either pre-fills it or offers it for selection. Checkout flows and multi-step onboarding are where this bites.

2.4.11 Focus Not Obscured, Minimum (Level AA)

When something receives keyboard focus, it must not be entirely hidden behind sticky headers, cookie bars or floating chat bubbles. This is the criterion most likely to fail on a modern site, because sticky elements are everywhere and almost nobody tabs through their own page to check.

2.5.7 Dragging Movements (Level AA)

Anything you can do by dragging must also be doable with a single pointer action that is not a drag. Sliders, kanban boards, reorderable lists, map panning. Add a click alternative or a set of buttons.

2.5.8 Target Size, Minimum (Level AA)

Interactive targets must be at least 24 by 24 CSS pixels, with exceptions for inline links in text and for targets with enough spacing around them.

This is the one people get wrong when they read old advice. WCAG 2.1 had a target size criterion — 2.5.5 — but it was Level AAA at 44 pixels, so it was never in scope for EAA conformance. WCAG 2.2 adds a different, smaller criterion at AA. If your design system standardised on 44px because a consultant said so, you were never obliged to and you still are not. Twenty-four is the number that is about to matter.

3.3.8 Accessible Authentication, Minimum (Level AA)

No cognitive function test in your login unless there is an alternative. That means: do not require the user to solve a puzzle, transcribe a code from an image, or remember something, without offering another route. Copy and paste must work in one-time-code fields. Password managers must not be blocked.

This one has teeth, because a lot of authentication is deliberately hostile to automation, and hostility to automation is usually hostility to assistive technology as well.

The requirement that disappears

4.1.1 Parsing is obsolete in WCAG 2.2. Duplicate id attributes and unclosed tags are no longer a conformance failure on their own — browsers recover from them predictably and the criterion no longer described a real barrier.

But it is still in force right now, because V3.2.1 adopts WCAG 2.1, and 2.1 still contains it. So a duplicate id is a failure of the currently harmonised standard today and will quietly stop being one after citation.

This is the only place where the new version makes your life easier, and it is worth knowing about mostly so that you do not spend an afternoon close to citation fixing something that no longer counts.

Two changes nobody mentions

Clause 6 gets much bigger. Real-time communication requirements broaden from two-way voice to real-time bidirectional communication, formally taking in Total Conversation — voice, real-time text and video together — with substantially revised RTT requirements. If your product includes calling, messaging or support chat, clause 6 deserves a read on its own, separately from anything WCAG says.

Annexes ZA and ZB are new, and they matter more than they sound. Annex ZB maps the technical clauses onto the actual articles of the European Accessibility Act, and Annex ZA does the same for the Web Accessibility Directive. V3.2.1 had no such mapping, which is why demonstrating a presumption of conformity against the EAA has been awkward: you were citing a technical standard at a legal instrument and hoping the join was obvious. V4.1.1 makes the join explicit.

For anyone who has had to assemble a conformance argument by hand, that is the most useful thing in the release.

What to do before citation

Do not remediate WCAG 2.2 as though it were law today. It is not, and you will have spent budget ahead of the obligation.

Do not ignore it either. Six new criteria with citation expected around the turn of the year is a plannable piece of work, and the two that usually require real design changes — focus not obscured, and dragging movements — are cheaper to fix while you are already touching a component than as a year-end emergency.

Measure the gap now, separately. You want two numbers: what fails against the standard that binds you today, and what would additionally fail after citation. One is a compliance obligation. The other is a roadmap item. Reporting them as a single red total is how tools inflate a problem into a panic.

That separation is why Curbcut is built the way it is. It reports findings as EN 301 549 clauses, and it keeps WCAG 2.2 criteria in their own band — visible, counted, and explicitly marked as not currently obligatory.

npx curbcut https://example.com --crawl

Or check a single page in your browser with nothing installed, which is the faster way to find out whether this is a problem you have at all.

It is MIT licensed, runs on your machine, and uploads nothing. When the citation lands, the mapping updates and the same criteria move bands, which is exactly the event I would rather have handled in software than in a spreadsheet.

The honest caveat

Automated testing finds roughly a third of accessibility barriers, and several of these new criteria are barely testable by machine at all. Consistent Help and Redundant Entry are judgements about a flow. Accessible Authentication needs somebody to actually try logging in with a password manager and a screen reader.

Curbcut prints the clauses it could not evaluate rather than omitting them, because a silent pass is the most expensive kind of wrong answer in this field. A scanner is where this work starts. It is not where it finishes.

If you want the longer argument about why rule identifiers are not a conformance claim, that is the other piece. If you would rather just find out where your own site stands, the readiness page lists which of the six a machine can check and what the other five cost in human time.

This article reflects EN 301 549 V4.1.1 as published on 2 September 2026 and ETSI's schedule for Official Journal citation as of September 2026; the citation date in particular may still move. Nothing here is legal advice.