European Accessibility Act: Preparing for June 2025

The European Accessibility Act (EAA, Directive 2019/882) enters force on 28 June 2025. Approved in 2019, transposed by member states over recent years, it’s an imminent reality. Many companies have it on the radar but haven’t acted. Others don’t know it applies to them. This article is a practical summary: who’s obligated, what it requires, and how to plan with margin.

What the EAA Is

The EAA harmonises accessibility requirements for products and services across the EU. The goal: people with disabilities can access digital and physical products and services without disproportionate barriers. Member States have adapted national legislation; in Spain, Real Decreto 193/2023.

It’s not new in spirit — regulation on the public sector (WAD, Directive 2016/2102) already existed. The EAA extends obligations to the private sector.

Which Products and Services It Covers

The list is extensive and sometimes surprising:

Products:

Computers, smartphones, tablets and their operating systems.
Self-service terminals: ATMs, ticket machines, check-in kiosks.
Routers, set-top boxes, smart TVs.
E-book readers.

Services:

E-commerce.
Electronic banking.
Telecoms (calls, messaging, 112 emergency access).
Transport (online booking, info displays, e-tickets).
E-books and software to read them.
Audiovisual-media services — Netflix, Prime Video interfaces, etc.

If your company has consumer e-commerce in Europe, EAA affects you. If you have a banking app, it affects you. If you sell a SaaS consumers use in browsers, probably too.

Important Exceptions

Not all companies are equal:

Micro-enterprises (fewer than 10 employees and <€2M turnover) are exempt in services (not products).
Disproportionate burden: adjustments that would be unjustifiably costly vs benefit can be excepted, but with documented analysis.
Legacy infrastructure with limited scope may be partially excepted with solid justification.

“Disproportionate” isn’t “I don’t want to do it” — it requires documented calculation.

Technical Requirements

Specific technical requirements are in EN 301 549, the European standard incorporating WCAG 2.1 AA as base reference (WCAG 2.2 is now available).

Pillars:

Perceivable: content accessible across senses (alt text, captions, contrast).
Operable: keyboard navigation, no forced timing, no seizure-inducing content.
Understandable: clear language, predictable behaviour, error assistance.
Robust: compatible with present and future assistive tech.

For most digital products this means: semantic HTML, correct ARIA roles, minimum 4.5:1 contrast for normal text, visible keyboard focus, video captions, etc.

Penalties

Penalties depend on the member state. In Spain, Royal Decree 193/2023:

Minor infractions: up to €50,000.
Serious: €50,001 to €400,000.
Very serious: €400,001 to €1,000,000.

Plus reputational risk from public audits. We’re already seeing consumer-association complaints over accessibility — this will grow in volume after June 2025.

The Most Common Mistake

Waiting until May 2025. Fixing deep accessibility issues takes months:

Auditing is 2-4 weeks for a mid-size product.
Refactoring non-accessible components: 2-6 months.
Re-testing and certification: 2-4 weeks.

To June 2025 there are ~16 months. Not excessive if you haven’t started.

A Realistic 16-Month Plan

By quarter:

Q1 2024: complete audit with automated tools + manual review. – Tools: axe DevTools, WAVE, Lighthouse, pa11y. – Manual review of critical flows with real assistive tech (NVDA, JAWS, VoiceOver). – Output: prioritised issue list with effort estimate.

Q2-Q3 2024: fix critical issues. – Custom components without correct ARIA support. – Keyboard navigation across the app. – Text and UI contrast. – Forms with labels, errors, helpers.

Q4 2024: secondary flows and content. – Images, videos, PDFs. – Documentation and help. – Accessible transactional emails.

Q1 2025: re-audit, testing with real users with disabilities, compliance documentation.

Q2 2025: margin for unforeseen items and team training.

Practical Tooling

Recommended stack:

axe-core: audit library that integrates into automated tests.
WAVE: browser extension for visual review.
Lighthouse: included in Chrome DevTools, useful for CI.
pa11y: CLI for pipelines.
Manual testing: NVDA + Firefox on Windows, VoiceOver + Safari on Mac/iOS, TalkBack on Android.

Automated audit covers ~30-40% of issues; the rest needs a human. Budget both.

Impact Beyond Compliance

Accessibility done well delivers:

SEO: semantic structure improves indexing.
General UX: accessible designs are better designs.
Market: ~15% of users have some relevant disability. Accessible product = bigger TAM.
Resilience: accessibility forces technical discipline.

It’s not just compliance; it’s investment with return.

Typical Mistakes

What we see repeatedly:

Adding “aria-label” everywhere without understanding it. Bad ARIA is worse than no ARIA.
Depending only on automated tools. They cover a third.
Ignoring PDFs. If you distribute commercial PDFs, they’re in scope too.
Not training the team. Without awareness, new development re-introduces problems.
“Accessibility button” as solution. Overlay widgets don’t meet EAA and are being sued.

Conclusion

The European Accessibility Act enters force in 16 months and affects more companies than realise it. Preparation cost is manageable if started now; non-preparation cost scales exponentially near the date. The practical approach: audit early, prioritise by severity, train the team so accessibility is part of how they build — not a final layer. Companies that do this well will have better products in all senses, not just law-compliant ones.