The European Accessibility Act Has Teeth Now

The European Accessibility Act stopped being a deadline in June 2026. It became a court order.

For most of 2025 the Act read like a compliance memo. Member states had transposed it, the June 2025 date had passed, and a lot of teams filed it under "we will get to it". Then in June 2026 a French court ordered Carrefour to make both its e-commerce site and its mobile app fully accessible, gave the company six months, and attached a daily fine for every day past that. The case had been brought not by a regulator but by four national disability organisations, in July 2025, alongside notices to Auchan, E. Leclerc and Picard.

That is the shift. Accessibility law in Europe is now being enforced by people who use the products, in court, with money attached.

What the Act actually covers

The European Accessibility Act sets minimum accessibility requirements for consumer-facing products and services sold in the EU. E-commerce, banking and payment services, ticketing, e-books, transport information, telephony, and the hardware they run on. If you sell to European consumers, the origin of your company does not exempt you.

Penalties are set nationally, which is why the numbers look so uneven. Ireland caps around 60,000 euro. Sweden runs to roughly 900,000. A common structure is up to 100,000 euro for placing a non-compliant product or service on the market, and a separate penalty, often around 10,000 euro, for misstating the accessibility of what you sell. That second one catches more teams than the first, because an over-confident accessibility statement is easy to write and easy to disprove.

The commercial pressure arrived before the fines

Ask a European enterprise sales team what changed in 2026 and they will not mention regulators first. They will mention procurement.

Accessibility documentation is now a standard line in vendor selection and in renewal. Buyers ask for a conformance report, they ask when it was produced, and they ask who audited it. A vendor who cannot answer is not usually rejected in a dramatic way. The deal simply moves slower, and then it moves to someone else.

This is the part worth internalising if you are building B2B or public-sector software. The fine is a tail risk. The lost renewal is a Tuesday.

An accessibility statement is a claim, not a shield

The most common failure we see is a statement written from intent rather than from evidence. It says the product conforms to WCAG 2.1 Level AA. Nobody has tested it against WCAG 2.1 Level AA. Somebody ran an automated scan, got a green score, and wrote the sentence.

Automated tooling catches a minority of real barriers. It cannot tell you whether a focus order makes sense, whether an error message explains what to do, whether a custom component announces its state, or whether a keyboard user can finish the task at all. Those are the failures that stop somebody using the service, and they are the ones a complaint will name.

If you publish a statement, write it from a manual audit, date it, name the standard and the version, and list what does not yet conform along with when it will. A statement with honest gaps is defensible. A statement that overclaims is evidence.

Where to actually start

Three moves, in this order, get most teams out of the danger zone.

Audit the journeys, not the pages. Pick the tasks that carry consequence: sign up, sign in, search, checkout, payment, and account recovery. Test each one end to end with a keyboard alone and with a screen reader. A homepage that passes and a checkout that fails is a failing product.

Fix at the source. The barriers that matter live in markup, focus management, and copy. They get fixed in components, which means they get fixed once and stay fixed. Anything bolted on at runtime is discussed in the next section, and it does not end well.

Put it in the pipeline. Accessibility checks belong in code review and CI next to your other quality gates. Teams that treat it as a periodic audit spend the same money every year and never improve. Teams that treat it as a build constraint pay once and then hold the line.

The part nobody wants to hear

Retrofitting accessibility into a mature product is expensive because it is not a layer. It is markup semantics, component behaviour, content structure, and error handling, which is to say it is most of the front end.

Designed in from the start it costs very little. It changes which component you reach for, how you write a label, and what you check before merging. That is the whole difference between a constraint and a crisis, and it is decided long before any regulator shows up.

We build software for regulated environments where this is not optional. If accessibility has moved from your backlog to your risk register, we should talk.