Europe's accessibility standard now points at WCAG 2.2. It isn't the legal reference yet

EN 301 549 v4.1.1 was published in September 2026 and moves the European accessibility standard from WCAG 2.1 to WCAG 2.2. If you read only the headlines you would conclude that WCAG 2.2 is now required in the EU. It is not, yet — and the gap between publication and legal citation is the most useful thing to understand about this update, because it tells you exactly how much time you have.

What changed in v4.1.1

EN 301 549 is the European standard for accessibility requirements in information and communication technology. It is the document that turns "your service must be accessible" into a testable list, and it is what auditors, procurement teams and enforcement bodies work from. Version 4.1.1 was published in September 2026 and announced by AccessibleEU on 7 September 2026. Five changes matter for a commercial website.

1. WCAG 2.2 replaces WCAG 2.1 as the benchmark for websites, software and digital documents.
2. Six new success criteria come in with it, at Levels A and AA — the levels EN 301 549 requires.
3. Success criterion 4.1.1 Parsing is removed, having been formally obsoleted in WCAG 2.2.
4. A new annex, Annex ZB, plus clause A.2, map the standard's requirements directly onto the European Accessibility Act, so an organisation can show which clause satisfies which legal obligation.
5. Real-time communication requirements are expanded, and mappings are added to support both the Web Accessibility Directive and the EAA.

The standard also strengthens the expectation that websites and documents respect a user's own accessibility preferences rather than overriding them — text sizing, contrast and motion settings the user has already chosen at the operating system or browser level.

The legal status, stated precisely

This is where most coverage of the update goes wrong, and the distinction is the single most decision-relevant fact in this article.

A harmonised standard only carries legal weight once the European Commission cites it in the Official Journal of the European Union. Until v4.1.1 is cited there, the reference standard for demonstrating conformity with the European Accessibility Act and the Web Accessibility Directive remains EN 301 549 v3.2.1 (2021), which is built on WCAG 2.1 Level AA. Publication of a new version and citation of a new version are separate events, and only the second changes what you are formally measured against.

So the accurate summary is: WCAG 2.2 is now the direction of travel in the European standard, and WCAG 2.1 AA is still the compliance floor. Neither half of that sentence is safe to drop.

WCAG 2.2 at Levels A and AA is additive: it keeps the 2.1 criteria and adds to them, with the single exception of the removed 4.1.1 Parsing. There is no scenario in which building to 2.2 now makes your 2.1 position worse. That asymmetry is the whole argument for treating this as a scheduling question rather than a wait-and-see question.

This is a summary of a technical standard and its status, not legal advice. Obligations under the EAA depend on your sector, your size and the member states you sell into, and national implementations differ. Confirm your position with counsel before relying on any exemption.

The six new criteria, and the component each one breaks

These are the WCAG 2.2 additions at Levels A and AA. WCAG 2.2 also added three Level AAA criteria — Focus Not Obscured (Enhanced), Focus Appearance and Accessible Authentication (Enhanced) — which sit outside the A and AA scope EN 301 549 requires. The six below are the ones that become mandatory when the citation lands, and in our experience each one has a predictable failure point on a commercial site.

Two patterns are worth drawing out of that table. First, four of the six bite hardest at exactly the points where money changes hands: checkout, login and lead forms. That is not a coincidence — those are the flows with the most steps, the most state and the most third-party widgets. Second, the blocking-paste failure is usually a deliberate decision someone made for security reasons, which means fixing it is a policy conversation rather than a code change. Start that one early.

What removing 4.1.1 Parsing does not let you stop doing

Success criterion 4.1.1 Parsing required markup to be well formed: correctly nested elements, complete start and end tags, no duplicate IDs. It was removed because modern browsers and assistive technologies handle malformed markup consistently, so the criterion no longer corresponded to a real barrier. Automated testing tools generated a large share of their findings from it.

The practical consequence is narrower than it sounds. Your automated scan will report fewer issues, and some of that reduction is genuine noise removal. But duplicate IDs and broken nesting still break things, and they now break them under other criteria instead: 1.3.1 Info and Relationships, 4.1.2 Name, Role, Value, and 3.3.2 Labels or Instructions all depend on markup that parses the way you intended. A duplicate ID that detaches a label from its input is still a failure. It is simply reported somewhere else.

So treat the removal as a change in where a defect gets reported, not as permission to ship invalid markup. If your accessibility score improves on the day you adopt the new standard without any code changing, that improvement is an artefact.

Sequencing: what to do in the next ninety days

You do not need a WCAG 2.2 programme. You need the six criteria prioritised against legal exposure, user impact and cost to fix, because they differ enormously on the last one. Here is how they actually sort.

Notice that the two cheapest items are also the two with the clearest commercial payoff. A 24-pixel minimum target and a focus ring you can always see are mobile usability fixes that happen to be accessibility criteria, which is the pattern across most of this work: the overlap between accessibility and conversion optimisation is far larger than either discipline usually admits. We have written about that overlap specifically in accessibility as a conversion problem.

Who this actually applies to

The European Accessibility Act has been enforceable since 28 June 2025 across all 27 member states, and it covers services sold to EU consumers including e-commerce, consumer banking, transport booking, e-books and telecommunications. Selling into the EU from outside it does not exempt you; the obligation follows the market, not your registered address.

There is a microenterprise exemption, and it is narrower than most people assume:

• It applies to services only, not to products. A microenterprise placing a covered product on the market still has product obligations.
• Both thresholds must be met: fewer than 10 persons employed and annual turnover or balance sheet total not exceeding €2 million. Exceeding either one removes it.
• It applies to the undertaking as a whole, not to an individual shop or brand within a group.
• There is no grace period when you grow past the thresholds.

If you are close to those limits, do not build a compliance strategy that depends on staying under them. The remediation you would need after crossing the line is the same work, done under time pressure.

What to ask your agency or in-house team

1. Which version are we currently tested against, and when was the last audit? If the answer is WCAG 2.0 or an automated scan only, that is the finding.
2. Do we have a keyboard-only and screen reader pass in our release process, or only an automated scan? The six new criteria are mostly invisible to automated tools.
3. Where in our design system do target size and focus visibility live? If the answer is "per component", the fix will recur forever.
4. Which third-party widgets would fail 2.5.7 and 3.3.8? Cookie tools, chat, review widgets, payment fields and CAPTCHAs are the usual suspects, and you do not control their code.
5. Are we using an accessibility overlay? Overlays do not create conformance with the underlying standard and have been a recurring feature of litigation rather than a defence against it.
6. What is our accessibility statement, and is it accurate? An inaccurate statement is worse than a candid one that names known gaps and a remediation timeline.

Frequently asked questions

What changed in EN 301 549 v4.1.1?

It adopts WCAG 2.2 as the benchmark for websites, software and digital documents in place of WCAG 2.1, bringing in six new success criteria at Levels A and AA. It removes success criterion 4.1.1 Parsing, which WCAG 2.2 obsoleted. It adds Annex ZB and clause A.2, which map the standard's requirements onto the European Accessibility Act so organisations can show which clause satisfies which obligation. It also expands real-time communication requirements and strengthens the expectation that sites respect users' own accessibility preferences.

Is WCAG 2.2 now legally required in the EU?

Not yet. A harmonised standard carries legal weight once the European Commission cites it in the Official Journal of the European Union. Until v4.1.1 is cited there, the reference standard for demonstrating conformity with the European Accessibility Act and the Web Accessibility Directive remains EN 301 549 v3.2.1 (2021), which is based on WCAG 2.1 Level AA. WCAG 2.2 is the direction of travel; WCAG 2.1 AA is still the floor.

Which six WCAG 2.2 criteria does EN 301 549 v4.1.1 add?

At Levels A and AA: 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.2.6 Consistent Help, 3.3.7 Redundant Entry and 3.3.8 Accessible Authentication (Minimum). WCAG 2.2 also added three Level AAA criteria (Focus Not Obscured (Enhanced), Focus Appearance and Accessible Authentication (Enhanced)) which fall outside the Level A and AA scope that EN 301 549 requires.

Should we build to WCAG 2.2 now or wait for the citation?

Build to it now, on a schedule. WCAG 2.2 at Levels A and AA is additive: it keeps every 2.1 criterion and adds six, with the single exception of the removed 4.1.1 Parsing. There is no scenario in which meeting 2.2 worsens your position against 2.1, and waiting compresses the same remediation into whatever notice period the citation gives you. Two of the six criteria, target size and focus visibility, are inexpensive CSS-level fixes that improve mobile usability regardless of compliance.

What does removing 4.1.1 Parsing mean for our site?

It means fewer findings in automated scans, not permission to ship invalid markup. Parsing was removed because browsers and assistive technologies now handle malformed markup consistently. But duplicate IDs and broken nesting still cause real failures, and those failures are now reported under other criteria instead, including 1.3.1 Info and Relationships, 4.1.2 Name, Role, Value and 3.3.2 Labels or Instructions. A duplicate ID that detaches a label from its input is still a failure.

Are small businesses exempt from the European Accessibility Act?

Only microenterprises providing services, and the test is strict. Both conditions must hold: fewer than 10 persons employed and annual turnover or balance sheet total not exceeding 2 million euros. Exceeding either removes the exemption, with no grace period. The exemption covers services only, so a microenterprise placing a covered product on the market still has product obligations, and the headcount applies to the undertaking as a whole rather than to an individual shop or brand. Confirm your position with counsel rather than relying on a summary.

The takeaway

Treat this as a scheduling problem with a known direction. The European standard now points at WCAG 2.2, the legal reference is still WCAG 2.1 AA until the Official Journal citation lands, and WCAG 2.2 at A and AA adds six criteria to what you already owe. Do target size, focus visibility and consistent help this month, because they are cheap and they pay for themselves in mobile completion rates. Put redundant entry and accessible authentication in this quarter, and start the password-manager conversation early because it needs a decision outside the web team. Batch dragging alternatives with your next component work. And do not let your automated scan's improved score after the Parsing removal be mistaken for progress, because nothing about your site changed that day.