Most conversations about the European Accessibility Act reach for WCAG, but WCAG is not the standard the EAA actually points to. That role belongs to EN 301 549, the European harmonised standard for accessibility of ICT products and services. Conforming to it is what gives a business the practical presumption that it has met the directive’s requirements. And EN 301 549 is on the move: the version that grants that presumption is shifting from one built on WCAG 2.1 to one built on WCAG 2.2.
The current published version, v3.2.1 from March 2021, incorporates WCAG 2.1 Level AA. The next version, v4.1.1, is expected during 2026 and updates the web content requirements to WCAG 2.2 Level AA, alongside significant changes to real-time text. It is anticipated to be cited as the harmonised standard in the Official Journal of the EU later in the process. When that citation lands, the reference point for European accessibility quietly becomes WCAG 2.2, and any programme still measuring itself against 2.1 has a defined gap to close.
Why the standard, not the guidelines, is the thing to track
EN 301 549 wraps WCAG rather than replacing it. Chapters 9, 10 and 11 pull the WCAG success criteria into web, non-web document and software contexts, so when EN 301 549 updates its WCAG baseline, the web criteria you are held to move with it. But the standard also covers a great deal that WCAG never addresses: hardware, two-way voice and video communication, real-time text, biometrics, and requirements for the documentation and support that ship with a product. Treating "EAA compliance" as "pass WCAG" quietly ignores those chapters.
The version number matters because the presumption of conformity is version-specific. A business audited against v3.2.1 was measured against WCAG 2.1. Once v4.1.1 is the referenced standard, the benchmark is WCAG 2.2, and the delta between them is real work, not a rounding error.
The WCAG 2.2 criteria your 2.1 audit never checked
WCAG 2.2 kept everything in 2.1 and added new success criteria. At Level A and AA, the additions that a 2.1-era audit would have skipped are these:
- 2.4.11 Focus Not Obscured (Minimum), AA: when an element receives keyboard focus, it must not be entirely hidden behind sticky headers, cookie bars or chat widgets. Fixed page furniture is the usual culprit.
- 2.5.7 Dragging Movements, AA: anything you operate by dragging, sliders, reorderable lists, map panning, needs a single-pointer alternative that does not require a drag.
- 2.5.8 Target Size (Minimum), AA: interactive targets must be at least 24 by 24 CSS pixels, or have enough spacing around them. This is one of the most common new failures on dense mobile layouts.
- 3.2.6 Consistent Help, A: if you offer help such as contact details or a chat, it must appear in a consistent place across pages.
- 3.3.7 Redundant Entry, A: do not make people re-enter information they already gave you in the same process, unless it is essential.
- 3.3.8 Accessible Authentication (Minimum), AA: log-in must not depend on a cognitive function test such as remembering a password or solving a puzzle, unless an alternative or a mechanism like a passkey is provided. This one quietly implicates a lot of checkout and account flows.
Two of these, target size and accessible authentication, tend to surface real defects on production sites rather than edge cases, so they are the ones worth checking first. WCAG 2.2 also removed the old 4.1.1 Parsing criterion, so a handful of legacy findings simply disappear.
The parts of EN 301 549 that are not WCAG at all
If your product does anything beyond static web content, v4.1.1’s non-web chapters deserve attention. The real-time text updates matter for any service with live chat or voice and video calling, where text has to be transmitted character by character rather than message by message so that a deaf or hard of hearing user can follow a conversation as it happens. There are also functional performance statements, which describe outcomes for users with particular needs, and documentation requirements that mean your help content and support channels are in scope, not just the interface.
What to do before the citation lands
You do not need to wait for the Official Journal to act, and waiting is the wrong move. The safe posture is simple: treat WCAG 2.2 AA as your target now.
- Re-run your audit against WCAG 2.2, not 2.1, and treat the six new A and AA criteria as first-class findings.
- Prioritise target size and accessible authentication, which most often produce genuine defects.
- If you build a mobile app, a kiosk, or anything with live communication, read EN 301 549’s non-web chapters rather than assuming WCAG covers you.
- Check that your accessibility statement names the version of the standard you actually tested against, so it does not go stale the day v4.1.1 is cited.
None of this is speculative. WCAG 2.2 has been a finished W3C Recommendation for a while, the new criteria are stable, and the direction of the European standard is set. Auditing to 2.2 today is not getting ahead of the rules, it is meeting the ones that are about to be written down.
- Work through every criterion, including the 2.2 additions, with the WCAG 2.2 checklist.
- See how the standard fits the wider obligation in our European Accessibility Act guide.
- Run a 2.2-level review end to end with the website accessibility audit guide.
- Read any criterion in plain language in the WCAG reference.