Europe published a new accessibility standard that is not yet the legal one

A new version of the European accessibility standard EN 301 549 was published this month, and the most useful thing about it for anyone writing specifications is not what changed. It is that two versions are now live and only one of them is enforceable.

That gap is a specification problem before it is a compliance problem.

What was published

Per AccessibleEU — the Commission-supported centre managed by DG Justice and Consumers — EN 301 549 v4.1.1 was published in September 2026. The headline change is that it adopts WCAG 2.2 as the accessibility benchmark for websites, software and digital documents, replacing WCAG 2.1.

Concretely, the update:

• adds six new accessibility requirements from WCAG 2.2
• removes the obsolete 4.1.1 Parsing criterion
• requires websites and documents to better respect users' accessibility preferences

It is also the first version of the standard developed specifically with the European Accessibility Act in mind, and it includes a new annex mapping the standard's requirements directly to the Act — which is a genuinely practical addition for anyone who has tried to trace one to the other.

The part people will miss

AccessibleEU states it plainly:

Until the European Commission formally cites EN 301 549 v4.1.1 in the Official Journal of the European Union, the current reference remains EN 301 549 v3.2.1 (2021), which is based on WCAG 2.1 Level AA.

So the published standard is not the binding standard. There is no new compliance deadline attached to this release. Once v4.1.1 is cited, meeting it will give a presumption of conformity with both the European Accessibility Act and the Web Accessibility Directive — but that citation has not happened.

This is a normal part of how European standards work and it is reliably misreported. It is worth being precise, because the cost of getting it wrong runs in both directions: a team that adopts v4.1.1 as though it were binding spends effort ahead of schedule, and a team that reads "new standard published" as "deadline moved" may relax against a requirement that has not changed.

Why this lands on the spec

Accessibility is a non-functional requirement, and non-functional requirements are the section most PRDs either omit or fill with adjectives.

"The interface should be accessible" cannot pass or fail. It is the accessibility equivalent of "the page should be fast" — a sentiment in the shape of a requirement, and one that will be satisfied by whatever the implementer decided when they hit it.

What is testable is a standard and a version:

WCAG 2.1 Level AA, per EN 301 549 v3.2.1 — the current legal reference

WCAG 2.2, per EN 301 549 v4.1.1 — the announced direction, not yet cited

Writing the version is what forces the decision. A spec that says only "accessible" has quietly left it to somebody to pick between two live standards, under deadline, with no stated reason.

What the Act actually covers

Worth restating, because the scope is wider than many product teams assume. Per the Commission, the EAA applies to computers and operating systems; ATMs, ticketing and check-in machines; smartphones; TV equipment for digital television services; telephony services and related equipment; access to audio-visual media services; air, bus, rail and waterborne passenger transport services; banking services; e-books; and e-commerce.

That last one catches a great many products that do not think of themselves as regulated. The Act is Directive (EU) 2019/882, and the Commission states that Member States had to incorporate it into national law by June 2022; enforcement is a national matter, with each Member State running its own procedures.

I have not verified individual national penalty regimes against primary sources, and the secondary coverage disagrees on both dates and amounts — so if the number matters to you, read your own Member State's transposition rather than a summary.

What to do about it

AccessibleEU's own guidance is short and sensible: review sites and digital documents against WCAG 2.2, update testing and audit checklists, review procurement and supplier requirements, and make sure PDFs and Office documents meet the new expectations.

For specs specifically, three things follow:

Name the version. In the non-functional requirements section, every time. "Accessible" is not a requirement and never was.

Decide which target you are building to, and say why. Building to v4.1.1 now is defensible — it is the announced direction and the work is not wasted. Building to v3.2.1 is also defensible — it is what is enforceable. What is not defensible is not having decided.

Check what 4.1.1 Parsing removal means for your test suite. If your accessibility checklist still tests against a criterion that has been withdrawn as obsolete, that is effort going somewhere that no longer counts — a small thing, and exactly the kind of small thing that accumulates in an audit process nobody has re-read in two years.

The rest of it is the ordinary discipline: a requirement with a number and a named standard beats a requirement with an adjective, and regulation is simply the case where somebody else eventually checks.

FAQ

What changed? v4.1.1 moves to WCAG 2.2 — six new requirements, 4.1.1 Parsing removed, plus new expectations around user accessibility preferences and an annex mapping to the EAA.

Is it binding? Not yet. Until the Commission cites it in the Official Journal, EN 301 549 v3.2.1 (WCAG 2.1 AA) remains the reference.

What does the EAA cover? Ten categories including banking, e-books and e-commerce.

What should a spec say? The standard and version, not the adjective.