Decoding EN 301 549 v4.1.1: What the New European ICT Standard Means for Section 508 Vendors

In September 2026, Europe published a new version of its core accessibility standard for information and communication technology (ICT). EN 301 549 v4.1.1 replaces WCAG 2.1 with WCAG 2.2 as the benchmark for websites, software and digital documents. It also drops an obsolete parsing requirement and, for the first time, maps its requirements directly to the European Accessibility Act.

For software and hardware vendors who sell to U.S. federal agencies, this creates an awkward gap. Section 508 still references WCAG 2.0, a standard from 2008. Europe now points to WCAG 2.2, from 2023. If you sell in both markets, the question isn't which standard to follow. It's how to build and test once so you can prove conformance to all of them. This guide covers the EN 301 549 v4.1.1 update, Section 508 vs EAA obligations, and a practical approach to multi-jurisdiction ICT accessibility standards.

What changed in EN 301 549 v4.1.1

EN 301 549 is the European standard for accessibility requirements for ICT products and services. It's broader than WCAG. It also covers hardware, two-way voice and video communication, authoring tools, documentation and support services. Chapters 9, 10 and 11 apply WCAG to web content, non-web documents and software. That's where the most visible change is.

The six WCAG 2.2 criteria are the practical change for product teams. Our WCAG 2.2 AA checklist covers each one in detail. In summary: focus must not be hidden by sticky UI, dragging needs a single-pointer alternative, targets must be at least 24 × 24 CSS pixels, help must appear in a consistent place, users shouldn't have to re-enter the same information, and logins can't depend on memory tests or puzzles.

Removing 4.1.1 Parsing is a small but welcome cleanup. Modern browsers and assistive technologies handle HTML parsing consistently, and the W3C had already noted that the criterion is always satisfied for HTML and XML content in WCAG 2.0 and 2.1. Removing it reduces noise in audit reports without lowering the bar for users.

When v4.1.1 becomes the legal reference

Publication and legal effect are two different steps. A European standard gives a "presumption of conformity" with EU law only when the European Commission cites it in the Official Journal of the European Union. As of late October 2026, that hasn't happened for v4.1.1. The cited version is still EN 301 549 v3.2.1, based on WCAG 2.1 AA, and the EU's AccessibleEU centre has said there's no new compliance deadline linked to the publication.

That doesn't mean you can ignore it. Once cited, v4.1.1 will become the benchmark for both the European Accessibility Act and the Web Accessibility Directive. Public sector buyers in the EU often reference the latest version in tenders before it's formally cited. And any product you design today will still be on the market when the citation happens.

Section 508 vs EAA: the standards gap

The U.S. Access Board's 2017 Section 508 refresh incorporated WCAG 2.0 Level A and AA by reference and applied it to web content, electronic documents and software. It was developed alongside the European standards work of the time, so for a few years the two were close enough that one round of testing covered both markets. Since then, Europe has moved forward twice, and Section 508 hasn't changed its WCAG reference.

The practical effect is that a product that only meets Section 508 may fail any of the 18 Level A and AA criteria added in WCAG 2.1 and 2.2 that EU buyers and regulators expect. These include reflow at 400% zoom, text spacing, orientation, non-text contrast, status messages and the six WCAG 2.2 additions. The reverse isn't a problem. A product that meets WCAG 2.2 AA also meets the WCAG 2.0 AA requirements in Section 508, apart from parsing, which modern HTML satisfies anyway.

How to build once for both markets

The cheapest way to handle multiple standards is to stop treating them as separate projects. Pick the highest common bar, test to it once, and report the results in each market's format.

1. Adopt WCAG 2.2 AA as your internal standard.Put it in your design system, definition of done and pull request templates. Add the EN 301 549 clauses that apply beyond WCAG, such as hardware, real-time text and documentation, if your product needs them.
2. Build a single test plan.Combine automated checks in CI with manual keyboard, screen reader, zoom and voice control testing. Map each test to WCAG criteria, and through them to EN 301 549 and Section 508 clauses.
3. Report with the right template.The ITI VPAT comes in 508, EU, WCAG and INT editions. The INT edition covers Section 508, EN 301 549 and WCAG in one document, which suits vendors selling in both markets.
4. Version your conformance claims.State exactly which standard and version you tested against, such as "EN 301 549 v4.1.1 / WCAG 2.2 AA," and the date. Buyers increasingly reject vague "508 compliant" claims.

Future-proofing your procurement pipeline

On the buying side, the same logic applies. If you're a public sector or enterprise buyer, writing WCAG 2.0 into a new contract today means accepting software that's already two versions behind. Contracts signed this year often run through 2029 or beyond.

• Ask for WCAG 2.2 AA in new solicitations, with EN 301 549 v4.1.1 for EU deployments.
• Require a recent ACR that names the standard version and the testing method, not just a self-declared "supports."
• Include a remediation clause with timelines for fixing reported barriers.
• Plan for re-certification when the Official Journal citation for v4.1.1 happens, so it's an update instead of a surprise.

Frequently asked questions