On 2 September 2026, the European Telecommunications Standards Institute (ETSI) published EN 301 549 V4.1.1. This is the final published version of the latest European standard on accessibility requirements for information and communication technology (ICT) products and services.
For digital teams, the headline is not that Europe has suddenly discovered WCAG 2.2. The World Wide Web Consortium (W3C) published WCAG 2.2 in October 2023. Mature accessibility programs have already had almost three years to study, adopt, and test against its added criteria.
The real change is wider. EN 301 549 V4.1.1 brings WCAG 2.2 into the latest European ICT accessibility standard. It also revises user-preference requirements, expands provisions for real-time communication, and introduces mappings designed to support two major European directives.
However, one important legal step remains. Publication by ETSI and citation in the Official Journal of the European Union (OJEU) are not the same event.
What changed on 2 September 2026?
WCAG 2.2 is not new. Its formal integration into Europe’s latest ICT accessibility standard is. That distinction should shape how organizations respond to EN 301 549 V4.1.1.
The version history matters because several draft documents circulated before publication. V4.1.0 identified the approval-stage drafts used during the standards process. V4.1.1 is the final publication version.
ETSI’s official work item shows that the standard was adopted on 24 August 2026 and published on 2 September 2026. The published document is 276 pages and is now the latest technical edition of EN 301 549, following V3.2.1.
That makes this a genuine implementation milestone. Teams can now review one stable text, update internal requirements, and plan against the final clauses rather than a draft.
Publication does not yet create OJEU presumption of conformity
At the time of writing, EN 301 549 V4.1.1 has been published but has not yet been cited in the OJEU. That distinction is central to any accurate compliance discussion.
For the Web Accessibility Directive, V3.2.1 remains the version cited through the current European Commission implementing decision. V4.1.1 was also prepared to support the European Accessibility Act. Yet it will not provide OJEU-based presumption of conformity for the EAA until the European Commission cites it.
Presumption of conformity is also narrower than a blanket guarantee. It applies only to the legal requirements covered by the cited clauses and only within the standard’s scope. The directives remain the law. A harmonized standard provides a voluntary technical route for demonstrating that covered requirements have been met.
ETSI’s project schedule currently lists 7 September 2026 as the target for delivery to the European Commission. It lists 30 November 2026 as the target for OJEU citation. These are useful planning dates, but they are provisional. They should not be presented as a confirmed Commission timetable.
Why EN 301 549 V4.1.1 is more than a WCAG version update
WCAG alignment will attract the most attention because it affects familiar digital experiences. Still, the foreword to V4.1.1 identifies five significant changes from V3.2.1:
- Clause 6.2 on Real-Time Text (RTT) is substantially revised, with related support for total conversation.
- Clauses 9, 10, and 11 are updated to align with WCAG 2.2 for web content, non-web documents, and software.
- A new Annex ZA maps relevant requirements to the Web Accessibility Directive.
- A new Annex ZB maps relevant requirements to the European Accessibility Act.
- A new Clause A.2 supports product- and service-specific assessment against EAA requirements.
This scope is why organizations should not reduce the update to a simple instruction to “test six new success criteria.” Those criteria matter, but EN 301 549 governs a wider accessibility system.
The six WCAG 2.2 additions that web teams will notice
For web pages, Clause 9 now reflects all Level A and Level AA requirements in WCAG 2.2. Six success criteria are new compared with the WCAG 2.1 baseline used by V3.2.1:
- 2.4.11 Focus Not Obscured (Minimum): A focused control must not be entirely hidden by author-created content such as sticky headers, banners, or dialogs.
- 2.5.7 Dragging Movements: Functionality that uses dragging needs a non-dragging alternative, unless dragging is essential.
- 2.5.8 Target Size (Minimum): Interactive targets must meet minimum size or spacing conditions, subject to stated exceptions.
- 3.2.6 Consistent Help: Repeated help mechanisms must appear in a consistent relative order across relevant pages.
- 3.3.7 Redundant Entry: Users should not have to re-enter information already provided in the same process, subject to limited exceptions.
- 3.3.8 Accessible Authentication (Minimum): Authentication should not rely on a cognitive-function test unless an accessible alternative or assistance is available.
The update also reflects WCAG 2.2’s removal of Success Criterion 4.1.1 Parsing. Clause 9.4.1.1 is therefore marked “Void.” That does not make malformed interfaces acceptable. Other requirements still depend on programmatically determinable names, roles, states, values, and relationships.
Teams should also avoid assuming identical applicability across every digital surface. Clause 10 adapts WCAG requirements for non-web documents. Clause 11 adapts them for non-web software. Some provisions differ. For example, Consistent Help is void in Clause 11 rather than a universal software requirement.
Websites, apps, and documents require different mappings
EN 301 549 is organized by the type and functionality of the ICT under review. That structure is more precise than treating every digital product as a website with a different screen size.
- Web pages, including mobile web pages, are primarily assessed under Clause 9.
- Non-web documents, including many PDFs and office files, are addressed under Clause 10.
- Non-web software, including native applications, is addressed under Clause 11.
There is an important edge case. A web view embedded inside non-web software is assessed under Clause 11, not Clause 9. The standard states that Clause 11 takes precedence if there is doubt. This is one reason an EN 301 549 review requires product architecture, not only a WCAG checklist.
User preferences move from a feature request to a cross-surface requirement
One of the most consequential changes is the reworking of user-preference requirements across Clauses 9.7, 10.7, and 11.7. The earlier structure concentrated this issue mainly in software. V4.1.1 distributes the requirement across web pages, documents, and software.
In practice, digital content should not block user-agent modes that honor accessibility preferences. Software with a user interface should follow documented platform accessibility settings unless a deviation is essential. The standard gives examples such as color filters, contrast settings, text size, pointer size, and text-cursor settings.
This deserves attention from design-system owners. A component can pass a static color-contrast check and still undermine accessibility when it suppresses platform scaling or overrides a user’s chosen display settings. Testing must therefore include how the experience responds to preferences, not only how it appears in its default state.
The WAD and EAA mappings make applicability more explicit
V4.1.1 includes separate annexes for the two European directives. Annex ZA maps the standard to the Web Accessibility Directive. Annex ZB maps it to the European Accessibility Act. Clause A.2 offers a product- and service-oriented route for EAA assessment, which can be more practical when one offering spans several legal categories.
The standard is also self-scoping. Many requirements begin with a condition such as “Where ICT…”. A requirement applies when its stated precondition is true. Therefore, a credible assessment must document why each clause applies, does not apply, or cannot be tested.
This is a major governance point. Organizations should not use one generic pass-or-fail template for every product. A public website, a banking app, an e-commerce service, a PDF statement, and a self-service terminal may share requirements, but they do not share an identical conformance map.
Real-time communication also receives a substantial update
The changes are not limited to visual interfaces and content. Clause 6.2 substantially revises Real-Time Text requirements. ICT that provides real-time, bidirectional voice communication must also provide RTT where the relevant conditions apply. The standard also addresses concurrent voice and RTT.
Clause 6.7 extends the communication model toward total conversation. Where ICT provides two-way voice and video communication, it must support the combination of RTT, voice, and video when the clause’s conditions are met.
This will not be the first priority for every website team. It may be central, however, for communications platforms, customer-service systems, emergency services, and products that combine voice, video, and text.
WCAG 2.2 was already the maturity signal
Should organizations have waited for EN 301 549 V4.1.1 before addressing WCAG 2.2? In most cases, no. Standards and legislation move on different timelines. A mature accessibility program watches both.
Some organizations stayed on WCAG 2.1 because contracts, procurement rules, or cited legal standards still named that version. That explains a formal compliance baseline. It does not justify ignoring known barriers in focus visibility, dragging interactions, target size, repeated data entry, or authentication.
The sensible approach is staged adoption. Teams can preserve evidence against the standard that applies today while also using the latest stable guidance for design and engineering. That is not premature compliance. It is ordinary product-risk management.
EN 301 549 V4.1.1 now narrows the gap between those two tracks. Organizations already working to WCAG 2.2 can focus on the wider EN requirements. Organizations still anchored to WCAG 2.1 need both a WCAG transition and an EN-specific gap analysis.
What digital accessibility teams should do now
The period before OJEU citation is an implementation window. It is a chance to prepare with less disruption and better evidence. A practical program can start with eight actions:
- Separate current obligations from the target state. Record the laws, contracts, and cited standards that apply today. Then document V4.1.1 as the technical target for readiness.
- Inventory the digital estate. Include websites, mobile and desktop software, embedded web views, PDFs, office documents, authentication journeys, support tools, and relevant communication features.
- Build an applicability map. Map each product’s features to the standard’s conditional clauses. Record the rationale for requirements marked applicable or not applicable.
- Run a clause-level gap analysis. Do not stop at the six new web criteria. Review user preferences, documents, software behavior, communication features, and the relevant WAD or EAA mappings.
- Update design-system rules. Add patterns for visible focus, unobscured focus, target size, alternatives to dragging, accessible authentication, consistent help, and platform preference support.
- Revise testing and acceptance criteria. Combine automated checks with keyboard, screen-reader, zoom, reflow, input, preference, and task-based manual testing. Test documents and embedded content separately where needed.
- Strengthen procurement and supplier evidence. Update accessibility clauses, test expectations, remediation responsibilities, and conformance-reporting requirements. Ask suppliers which EN edition and clauses their evidence actually covers.
- Train the people who make release decisions. Product, design, engineering, content, QA, procurement, and legal teams need a shared view of the difference between WCAG conformance, EN 301 549 conformance, and legal compliance.
Four mistakes to avoid
- Do not relabel an old WCAG 2.1 audit as evidence against V4.1.1.
- Do not assume WCAG 2.2 AA alone equals full EN 301 549 conformance.
- Do not treat a provisional OJEU target date as a guaranteed legal deadline.
- Do not claim conformity from an automated scan. Many decisive requirements need human evaluation and product context.
The strategic takeaway
Publication of EN 301 549 V4.1.1 gives organizations a stable technical destination. OJEU citation will determine when the new version can provide presumption of conformity for covered legal requirements. The work between those milestones should be deliberate, documented, and cross-functional.
For leaders, the question is no longer whether WCAG 2.2 is too new to consider. The question is whether the organization can show how accessibility requirements move from policy into design systems, product backlogs, document workflows, supplier controls, and release evidence.
EN 301 549 V4.1.1 does not make WCAG 2.2 new. It makes the cost of continuing to treat it as optional increasingly difficult to justify.
Pivotal Accessibility helps organizations assess digital products, prioritize remediation, improve accessible development practices, and build team capability. Explore our digital accessibility services or contact Pivotal Accessibility to plan a V4.1.1 readiness review.