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.
The sequence, from ETSI's work programme and what has been published so far:
| Milestone | When |
|---|---|
| V4.1.0 public-enquiry draft | November 2025 - done |
| V4.1.0 final draft | June 2026 - done |
| V4.1.1 published by ETSI, CEN and CENELEC | 2 September 2026 - done |
| Cited in the Official Journal, replacing V3.2.1 | Provisional: late November to mid-December 2026 |
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 criterion2.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 I built Curbcut the way I did. 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
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.
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.
Top comments (1)
Some comments may only be visible to logged-in visitors. Sign in to view all comments.