Skip to content
LUIGI MICCA

Published

4 min read

The European Accessibility Act is being enforced. Is your website in scope?

The EAA stopped being a future problem in June 2025 — 2026 is the year of inspections, warning letters and the first fines. Who's actually in scope, what compliance really means, and why accessibility overlays won't save you.

For years, web accessibility in Europe lived in a comfortable limbo: everyone agreed it mattered, almost nobody was forced to act. That limbo ended on 28 June 2025, when the European Accessibility Act became applicable — and 2026 is turning out to be the year the machinery actually starts moving. Market surveillance authorities are running inspections, advocacy groups are filing complaints, law firms are sending warning letters, and the first fines are landing: Germany allows fines of up to €100,000 per violation; in France they range from €5,000 to €250,000, plus €25,000 per year for a missing accessibility statement.

If you sell to EU consumers, this is now an engineering deadline that has already passed.

Who is actually in scope

The EAA covers businesses with 10 or more employees or more than €2 million in annual turnover that sell covered products or services to EU consumers. In practice, that includes most of the web that takes money: e-commerce shops, banking and payment flows, booking systems, transport ticketing, consumer SaaS.

Microenterprises providing services are formally exempt — but don't relax yet: if a larger company is your client, their compliance obligations flow down into what you supply them. I've already seen accessibility clauses appear in procurement checklists the same way GDPR clauses did in 2018.

What compliance actually means

The standard behind the law is EN 301 549, which in web terms boils down to WCAG at level AA. Strip away the acronyms and it's a concrete engineering checklist:

  • Keyboard. Every flow — menu, filters, checkout — works without a mouse, with a visible focus indicator and no traps.
  • Forms. Real labels, and error messages that say what to fix, not just "invalid input".
  • Contrast and text. Sufficient contrast ratios, text that scales to 200% without breaking the layout.
  • Structure. Semantic HTML: headings that outline the page, buttons that are buttons, links that are links. Screen readers navigate structure, not pixels.
  • Media. Alt text that describes function, captions on videos.
  • A published accessibility statement and a feedback channel — the absence of this document is the single easiest violation for a regulator to spot, and in France it has its own recurring fine.

None of this is exotic. It's the same discipline as performance work: measurable, testable and mostly invisible when done right.

Honesty corner: the overlay shortcut

There's a whole industry selling one-line JavaScript widgets that promise compliance overnight. They don't deliver it. Overlays can't fix missing labels, broken keyboard flows or divs pretending to be buttons — and several enforcement actions and lawsuits have explicitly named sites with overlays installed. If a vendor promises EAA compliance for €49 a month and one script tag, you're buying a false sense of security, and the regulator knows it.

The upside nobody mentions

Accessibility work overlaps almost perfectly with things you already want. Semantic structure is what search engines parse. The faster, lighter pages it pushes you towards help everyone. Clear forms with described errors convert better for everyone, not just for the roughly 87 million people in the EU living with some form of disability — a market larger than Germany.

In my experience, teams that treat accessibility as a quality attribute — like performance, like security — end up with better front-ends across the board. Teams that treat it as a box-ticking exercise do it twice: once badly, once properly after the complaint.

Where I'd start

  1. Audit honestly. Automated scanners catch maybe a third of real issues; the rest requires a human with a keyboard and a screen reader walking your critical flows.
  2. Prioritise by user impact. A broken checkout matters more than a decorative image in the footer.
  3. Fix in normal sprints. Most fixes are small; the expensive part is finding the problems, not fixing them.
  4. Publish the statement and wire accessibility checks into your definition of done, so the work doesn't rot.

The EAA didn't invent any of this — it just attached a price tag to ignoring it.

I'm an independent software architect focused on front-end work, and accessibility reviews are part of every audit I run. If you're not sure where your site stands, let's talk: a 30-minute intro call is free.