The European Accessibility Act, for Developers

For most of the time this site has existed, web accessibility in the private sector was a good idea rather than a legal requirement in most places. That changed across the EU on 28 June 2025.

This is a general orientation written by a developer, not legal advice. National implementations differ and enforcement is still settling. If it applies to your organisation, someone qualified should be reading the actual rules.

What it is

The European Accessibility Act is Directive (EU) 2019/882. It was adopted in 2019, member states had to write it into national law, and it began applying to covered products and services on 28 June 2025.

Because it is a directive rather than a regulation, the law you actually have to comply with is your member state's version. The names differ, the enforcement bodies differ, and the penalties differ. The substance is meant to be consistent.

What it covers

Consumer-facing products and services, including:

• e-commerce
• banking and payment services
• electronic communications
• transport ticketing and information services
• e-books
• audiovisual media services access

If you build a shop, a banking front end, or a booking flow for consumers in the EU, assume it is in scope until someone tells you otherwise.

Whether it reaches you

Two points that surprise people.

It is about the market, not the office. It applies to products and services offered to consumers in the EU, regardless of where the business is based. A company outside the EU selling into it is covered.

There are exemptions. Microenterprises providing services are excluded, and there are provisions about disproportionate burden. These are narrower than people hope and they are not a general escape.

There is also a transition point worth knowing: service contracts concluded before June 2025 have until June 2027.

What standard it actually requires

The Act itself sets out functional requirements rather than technical ones. The technical detail comes through the European standard EN 301 549, which incorporates WCAG.

Practically, that means WCAG conformance at level AA is the target, and the version referenced is moving toward 2.2 as the standard is revised.

Which is the useful news for a developer: you do not need a separate body of knowledge for this. The thing being asked for is the thing this site has always been about.

What a developer can do about it

Not much of this is legal work.

Establish where you stand. An automated scan finds a fraction of the issues, but it finds the mechanical ones quickly. Follow it with a keyboard pass and a screen reader pass on your main flows.

Prioritise the transactional path. Sign-up, log-in, search, checkout, payment. That is where the Act's attention sits and it is where a failure actually stops someone completing a purchase.

Fix the login flow first. Authentication is disproportionately represented in the new WCAG criteria and in complaints, and it is frequently the worst part of an otherwise reasonable site.

Write it down. Being able to show what you assessed, what you found and what you are doing about it is worth a great deal more than an assertion of compliance.

Build it into the process. A remediation project fixes a snapshot. Linting, component-level tests and a check in code review are what stop it regressing.

What not to do

Do not buy an overlay. Accessibility overlay widgets that promise compliance through a script have a poor record, are opposed by disability advocacy organisations, and have themselves been the subject of legal action. They do not fix the underlying markup.

Do not treat a clean automated scan as conformance. Most criteria are not machine-checkable, and the newest ones especially so.

Do not wait for a definitive checklist. Enforcement practice is still forming. The work is the same either way.

The honest framing

Legal deadlines are a poor motivation for this work and a real one. If the deadline is what gets accessibility onto a roadmap, use it.

But the thing that makes a site usable to someone navigating with a screen reader is the same thing it always was: sensible markup, labelled controls, visible focus, and someone having actually tried it with the keyboard.

[Suzanne: this is deliberately written from a UK perspective looking at the EU, since that is where you are. If you have seen the Act land on a real project — a client suddenly caring, a procurement question — a paragraph on that would be worth more than the summary above. I have not invented one.]