EN 301 549, the accessibility rulebook Europe actually uses
If you run an online shop, build software for the public sector, or work at an agency whose clients have started asking about accessibility, this will be familiar.
You start by reading a law. The law says your products have to be accessible, so you look for the part that explains what "accessible" actually means. The law doesn't explain it. It points you at a technical standard. You find the standard and it's a 277-page document published by Europe's telecommunications standards body, full of clause numbers and cross-references. So you close the tab and get on with your day.
That document is EN 301 549, officially titled "Accessibility requirements for ICT products and services." A new version arrived on 3 September 2026, its first substantial revision in five years.
Published: 3 September 2026 · Legally operative: not yet, pending the Official Journal · Main change for web teams: WCAG 2.1 AA → WCAG 2.2 AA
What changed, at a glance
| Area | Version 3.2.1 (2021) | Version 4.1.1 (2026) |
|---|---|---|
| Web content | WCAG 2.1 AA | WCAG 2.2 AA |
| European Accessibility Act | Not covered | Full mapping, plus a procedure for working out what applies to you |
| Public sector websites | Covered | Still covered, tables updated |
| Hardware (ticket machines, payment terminals) | Basic requirements | Expanded, including a new contrast rule for physical buttons and labels |
| Apps using webviews | Ambiguous | Explicit: a webview is assessed as software, not as a web page |
| User settings | No rule | New: your page must not override someone's browser accessibility settings |
| Calling and emergency features | Basic real-time text | Significantly expanded, including total conversation |
| Legally operative? | Yes, today | Not yet, pending the Official Journal |
The rest of this post explains what that document is and why any of it matters. Plain language throughout, no clause numbers.
Laws set goals. Standards set details.
Europe splits this into two layers, and the reason explains almost everything else.
A European law has to be agreed between 27 member states and then written into 27 national legal systems, a journey that rarely takes less than two years and usually takes considerably longer. A technical detail like a contrast ratio needs to change at the speed screens and browsers change. Put both in the same document and you have to choose between a law nobody can update and requirements that permanently lag the technology they're meant to govern.
So they're separated.
The law says what has to be achieved. The European Accessibility Act, which has bound much of the private sector since 2025, says an online shop must be perceivable, operable, understandable and robust for people with disabilities. Notice that it names no numbers at all, because a figure written into legislation is frozen there for years.
The standard supplies those details: what "perceivable" means when you sit down to build, how to check it, and the exact threshold. Because it isn't a law, it can be revised without reopening anything in Brussels. Which is precisely what just happened.
EN 301 549 is that second layer. It isn't a law and nobody can fine you for breaching it directly. What it gives you is something lawyers call a presumption of conformity: follow the standard and regulators must treat you as having met the legal requirement unless they can prove otherwise.
That presumption is the whole point of the document. It converts a vague legal obligation into a checkable list, and it shifts the burden of proof onto whoever wants to argue you got it wrong.
Who it actually applies to
Not everyone carries the same obligation. The standard is written, in its own words, for anyone who designs, develops, manufactures, evaluates or buys technology products and services, and it covers websites and mobile apps, desktop software, hardware with a screen or buttons, documents, and customer support services.
In practice there are three situations. If you sell to the public sector, you'll be asked for it by name in the tender. If you sell to consumers in banking, e-commerce, transport or e-books, it reaches you through the European Accessibility Act. If neither applies, it remains the best available reference for what doing this properly looks like.
That first situation is worth picturing, because it explains why the standard exists at all. Imagine you're the person at a city council choosing which of four suppliers gets the contract for a new website. You can't personally test whether each one is accessible, and "yes, our product is accessible" from a salesperson isn't something you can verify. What you can do is name the standard in the contract and ask each supplier to demonstrate how they meet it.
That turns an opinion into something with evidence behind it.
Where it came from
It started with governments buying things
European public bodies buy an enormous amount of technology: the software a hospital runs on, the ticket machines in a metro station, the website you file your tax return through.
In the mid-2000s the European Commission noticed that every country was writing its own accessibility requirements into its own contracts, so a company selling in five countries had to satisfy five different rulebooks for what was essentially the same thing.
To fix it, the Commission issued what's called a mandate (the official instruction to write a standard), known as Mandate 376.
Who writes Europe's standards
The job went to the three standards bodies recognised by the European Union. They're worth knowing by name, because between them they write most of the technical standards Europe runs on.
- CEN handles general standards, from construction to food.
- CENELEC handles anything electrical.
- ETSI handles telecommunications and information technology.
This mandate landed at ETSI, and within ETSI at its Human Factors committee, the group concerned with how people actually use technology. That's why a document about accessibility ended up with a reference number that looks like it belongs to telecoms. It isn't a filing error, it's just where it came from.
The first version arrived in 2014 and was openly a purchasing tool: a shared list so an administration could write "must conform to EN 301 549" into a tender and every supplier would know exactly what that meant. Nothing in it touched the private sector.
How a shopping list became a compliance benchmark
In 2016 the EU passed the Web Accessibility Directive, which required public sector websites and apps to be accessible and pointed at EN 301 549 for the technical detail. A directive, worth clarifying, is a European law that doesn't apply directly: each country writes it into its own legislation, a process called transposition. Spain's is Real Decreto 1112/2018.
The shopping list was now the compliance benchmark for every government website in Europe. Version 3.2.1, published in March 2021, was built for that job and remains the operative version today.
Then in 2019 the European Accessibility Act went considerably further, moving accessibility obligations into the private sector: banking, e-commerce, e-books, passenger transport, ticketing machines. It has applied since June 2025, though as we found when we checked what enforcement actually looks like country by country, the penalties have arrived more slowly than the headlines suggest.
And that created the gap this revision closes. The EAA covers private companies and physical products, but the standard everyone was using had been built around public sector websites, so fitting one to the other was awkward and in places impossible. The Commission commissioned a revision in 2022, and the result is the version just published.
What the new version changes
Four changes matter to most people.
It moves to WCAG 2.2
WCAG 2.2 is the international rulebook for web content, published by the W3C, the consortium that maintains web standards. It comes in three levels of strictness: A, AA and AAA. European law points at AA, the middle one.
EN 301 549 doesn't rewrite those rules. It adopts them wholesale for its web chapters and adds its own requirements around them. The previous version incorporated WCAG 2.1; the new one incorporates WCAG 2.2, which adds criteria on keyboard focus visibility, alternatives to dragging, minimum target sizes, and authentication that doesn't depend on remembering something.
The useful part is that the standard says so explicitly: meeting WCAG 2.2 at level AA is equivalent to meeting all of its web content requirements.
If your team already works to WCAG 2.2 AA, this part asks nothing new of you.
It finally addresses the EAA properly
This is probably the most useful change in the document.
The previous version carried a single mapping table, for the public sector directive. The new one adds a whole block of tables built specifically for the European Accessibility Act, plus a procedure for determining which requirements apply to your particular product or service.
It matters because the EAA's own text describes its requirements in broad terms that are genuinely hard to act on. Until now there was no official route between "the law says this" and "so check these specific things."
Now there is.
It reorganised around products, not just websites
Requirements for authoring tools moved to the general chapter. Requirements for hardware with physical controls, like ticket machines and card readers, expanded considerably, including a new rule about the contrast of printed labels and buttons. Real-time text and emergency calling received significant work.
The software chapter was also renamed to make clear it covers non-web software, and it settles something that has confused mobile teams for years: a webview inside a native app does not count as a web page, and is assessed as software.
It added a rule about respecting user settings
Small, and easy to break without noticing.
You must not override the accessibility preferences someone has configured in their browser or document reader. If a person has set a large font size or a high contrast mode, your page has to let that work. The standard specifically calls out forcing colours in CSS as the thing not to do unless it's essential.
Worth checking your own stylesheets for.
The date nobody should skip
This is where precision matters, and where a lot of what gets written over the next few months will be wrong.
The new version is published, but it is not yet legally operative. That difference isn't a technicality.
For a European standard to grant presumption of conformity, its reference has to appear in the Official Journal of the European Union, the EU's official gazette. That hasn't happened yet.
For the public sector directive, the version that currently carries that status is the one referenced through Commission Implementing Decision (EU) 2018/2048, as amended in 2021. Until an equivalent decision cites v4.1.1, the previous version remains the one that counts for demonstrating compliance.
This doesn't make the new document useless. It tells you where everything is heading and is worth reading now. But anyone assuring you that you've been non-compliant since September 2026 is selling something. You cannot breach a European standard that hasn't been through the Official Journal.
You can check this yourself, which is the useful part. ETSI's work programme record for the standard lists its status as delivered to the Commission, and its Official Journal field is empty.
The standard does include its own transition timetable for national standards bodies, and it's public: member states announce it by the end of November 2026, publish their national versions by 31 May 2027, and withdraw conflicting national standards by 31 May 2028. In Spain, that national version is published as UNE-EN 301 549, and that's the name you'll see cited in tenders.
So the reasonable position is this. Nothing breaks today, WCAG 2.2 AA is the direction of travel, and if you're procuring or building something that will still be alive in two or three years, build to the new version now and save yourself the rework. It's the same logic that applies to the other deadlines arriving through 2026: the work is cheaper before it's urgent.
The part most teams miss
There's a widespread assumption that auditing accessibility in Europe means checking a website against WCAG. It's an understandable shortcut, since WCAG is the best known part and the one with the best tooling. It's also incomplete.
As Olga Carreras puts it in her detailed analysis of the new version, the reference standard in Spain and Europe is EN 301 549, and it contains many requirements beyond WCAG that need to be known, applied and evaluated.
The difference is easy to summarise. WCAG covers web content. The standard also covers hardware, two-way communication, documentation, support services and relay services. For an ordinary website, WCAG 2.2 AA does most of the work. The moment your product has a physical interface, a calling feature or a support channel, there are entire chapters WCAG simply doesn't touch.
Carreras is the most referenced accessibility professional in Spain and has worked with this standard since its first version. Her clause-by-clause comparison of 4.1.1 against 3.2.1 is the most thorough public analysis of this update we've found in any language, and it was the starting point for our own reading of the standard. If you work with this document professionally, read her piece as well as this one. It goes considerably deeper than we do here.
What to do with this
If you work on the web and already target WCAG 2.2 AA, you're in good shape. Keep going, and keep the evidence of what you check.
If you sell to the public sector, the standard's name is literally what appears in the tender. Knowing which version applies and being able to show your work against it is the difference between a qualifying bid and one that falls at the first review.
If your product includes hardware, calling features or documentation, the expanded chapters deserve an afternoon of someone's attention. That's where this version's genuinely new obligations live.
Whatever you build, what turns any of this into something you can hand a regulator or a procurement panel is a record: what was checked, when, against which criterion, and what happened next. A standalone report from last quarter proves very little. A dated trail of findings and verified fixes proves a great deal.
That gap, between finding problems and being able to demonstrate you resolved them, is the one Jeikin was built to close, and it's why we tie every finding to a specific criterion rather than to an overall score.
Standards are intimidating from the outside and usually read better than you expect. This one is available from ETSI at no cost. If European accessibility law touches your work, an hour with the table of contents is an hour well spent.