EN 301 549 V4.1.1 adopts WCAG 2.2: what web teams must change

Europe’s accessibility standard now points to WCAG 2.2. EN 301 549 V4.1.1, dated September 2026, aligns its web, document and software requirements with WCAG 2.2 and is the first version built for the European Accessibility Act ^{[1, 2]}. If you design or build digital products for European users, this EN 301 549 WCAG 2.2 update sets the bar you will be measured against.

There is one catch. The new version is not yet the legal reference, and that timing matters for how you plan your next releases ^[2].

Key takeaways

• EN 301 549 V4.1.1 replaces WCAG 2.1 with WCAG 2.2 as its benchmark for websites, software and digital documents ^[2].
• It adds six new requirements from WCAG 2.2 and drops the obsolete 4.1.1 Parsing criterion ^[2].
• A new annex maps the standard to the European Accessibility Act, which has applied since 28 June 2025 ^{[1, 4]}.
• Until the Commission cites V4.1.1 in the Official Journal, V3.2.1 (based on WCAG 2.1 AA) remains the legal reference ^[2].
• The new criteria are mostly design decisions, so they are cheapest to meet inside the design system.

What the EN 301 549 WCAG 2.2 update changes

EN 301 549 is the harmonised European standard that sets accessibility requirements for ICT products and services, with test procedures suitable for procurement ^[1]. It is published jointly by CEN, CENELEC and ETSI, and the cover of V4.1.1 lists an adoption date of 24 August 2026 ^[1].

ETSI lists the significant changes since V3.2.1 in the document’s foreword ^[1]:

• Clauses 9, 10 and 11 have all been updated to align with the WCAG 2.2 recommendation ^[1].
• A new Annex ZB shows how the standard relates to the essential requirements of Directive (EU) 2019/882, the European Accessibility Act ^[1].
• A new clause A.2 lets teams evaluate whether specific products and services conform with that Directive ^[1].
• Annex ZA, covering the Web Accessibility Directive for the public sector, has been updated ^[1].
• Real-Time Text requirements have been significantly revised and extended to include total conversation ^[1].

AccessibleEU, the European Commission’s accessibility resource centre, summarises the practical effect: six new requirements from WCAG 2.2, the removal of 4.1.1 Parsing, and a push for websites and documents to better respect users’ accessibility preferences ^[2].

The six WCAG 2.2 criteria you now need to meet

WCAG 2.2 became a W3C Recommendation on 5 October 2023 and added nine success criteria ^[3]. Six of them sit at Level A or AA, which is the level EN 301 549 builds on ^[3]:

• 2.4.11 Focus Not Obscured (Minimum), AA: when an item gets keyboard focus, it must be at least partially visible, not hidden behind sticky headers or banners ^[3].
• 2.5.7 Dragging Movements, AA: anything done by dragging also needs a single-pointer alternative ^[3].
• 2.5.8 Target Size (Minimum), AA: pointer targets are at least 24 by 24 CSS pixels, with exceptions such as enough spacing or inline text links ^[3].
• 3.2.6 Consistent Help, A: help options appear in the same place across pages ^[3].
• 3.3.7 Redundant Entry, A: users are not asked for the same information twice in the same session ^[3].
• 3.3.8 Accessible Authentication (Minimum), AA: people should not have to solve, recall or transcribe something to log in, and support for password managers and copy and paste is one accepted way to meet it ^[3].

“People who can't use a mouse need to see what has keyboard focus.”

W3C also confirms that 4.1.1 Parsing is obsolete and removed from WCAG 2.2 ^[3]. Modern browsers and assistive technology handle markup errors well enough that the criterion no longer protected users. Valid HTML is still good practice, but it is no longer a separate pass or fail.

Timing: when V4.1.1 becomes the legal reference

The European Accessibility Act is Directive (EU) 2019/882, adopted on 17 April 2019, and its measures apply from 28 June 2025 ^[4]. A harmonised standard is how a company shows it meets the Act’s essential requirements in practice.

Right now that standard is still EN 301 549 V3.2.1 from 2021, which is based on WCAG 2.1 Level AA ^[2]. V4.1.1 only takes over once the European Commission formally cites it in the Official Journal of the European Union ^[2]. ETSI’s foreword says the same: after citation, compliance with the relevant clauses confers a presumption of conformity with the Directive’s essential requirements ^[1].

“Once the standard is formally cited, meeting EN 301 549 v4.1.1 will give organisations a presumption of conformity with both the European Accessibility Act and the Web Accessibility Directive.”

In plain terms, WCAG 2.1 AA keeps you compliant today, and WCAG 2.2 AA is where the legal bar is going. AccessibleEU advises organisations to start reviewing digital content against WCAG 2.2 and updating their testing processes now ^[2]. We agree. Anything you design to the older standard this year is work you will reopen next year.

One scope note. The Act exempts microenterprises that provide services from its accessibility requirements ^[4]. That exemption is narrow, and it does not cover the larger retailers, banks and platforms that most often commission product work.

Why it matters for teams outside Europe

Many of our clients in Indonesia sell to European customers, partner with European companies or plan to expand there. For them, WCAG 2.2 AA is becoming the practical bar whether or not a regulator ever looks at their site.

There is a simpler reason too. The new criteria describe things users notice on every screen: a focus ring hidden behind a sticky header, a close button too small to hit on a phone, a checkout that asks for the same address twice, a login that blocks password managers. Fixing them helps every user, not only people with a disability.

How your design and development team should act

• Audit the component library first. Check focus styles, sticky headers, icon buttons and sliders against the six new criteria before you audit individual pages.
• Update design tokens. Set a minimum hit area and a focus style token so designers cannot ship a component that fails by default.
• Review forms and login. Remove repeated fields, allow paste in password and code fields, and support password managers.
• Put help in one place. If you offer chat, a phone number or a help link, keep it in the same spot on every page.
• Add WCAG 2.2 to QA. Extend your release checklist and automated tests so every release is checked, not only the launch.
• Track the Official Journal. When the Commission cites V4.1.1, update your accessibility statement and conformance claims to reference it.

FAQ

Is EN 301 549 V4.1.1 legally required today? Not yet. Until the Commission cites it in the Official Journal, V3.2.1 based on WCAG 2.1 AA remains the legal reference for the Accessibility Act and the Web Accessibility Directive ^[2].

Does WCAG 2.2 AA conformance cover everything in EN 301 549? No. The standard also covers hardware, software, documents and services such as Real-Time Text ^[1]. For a website or web app, though, the web clauses aligned with WCAG 2.2 are the core of the work ^[1].

Do the new criteria need a redesign? Rarely. Most are fixed at component level: bigger targets, focus that stays visible, and simpler login and form flows. That is why we treat them as design system work.