The European Accessibility Act is in force: what it means for your software

The European Accessibility Act (EAA) has applied across the EU since 28 June 2025. For many digital products and services, accessibility moved from 'nice to have' to legal requirement, with national enforcement and real fines. Here's the practical view for software teams. (This is an orientation, not legal advice.)

What the EAA is

The EAA (Directive (EU) 2019/882) is an EU-wide law that requires certain products and services to be accessible to people with disabilities. Member states transposed it into national law (in Germany as the BFSG, in Austria as the BaFG), each with its own market surveillance and penalties. The obligations apply to services provided to consumers after 28 June 2025, with transition periods for existing services and legacy contracts running until 28 June 2030 at the latest; self-service terminals already in use may continue to operate for up to 20 years after being put into service.

Who is affected

The act targets consumer-facing digital services and products, including e-commerce (any webshop selling to EU consumers), consumer banking services, e-books and readers, electronic communications, elements of passenger transport (ticketing, check-in), plus hardware like ATMs, terminals, smartphones and operating systems. Pure B2B software is not directly in scope, but B2B vendors feel it indirectly: their customers must comply, and accessibility clauses are appearing in procurement. Micro-enterprises (fewer than 10 employees and under 2 million euro turnover) are exempt for services.

The technical bar: WCAG 2.1 AA

In practice, conformity is assessed against the European standard EN 301 549, which for web and mobile content points to WCAG 2.1 level AA. The updated edition of the standard for the EAA will reference WCAG 2.2; if you are building today, it is worth aiming for that right away. Typical failures we see in audits: insufficient colour contrast, interfaces that can't be operated by keyboard alone, missing focus indicators, form fields without programmatic labels, images without meaningful alternative text, videos without captions, and custom widgets that are invisible to screen readers.

Why automated scans aren't enough

Automated checkers (axe, Lighthouse, WAVE) are a good start, but depending on the study they detect only 30 to 57 percent of WCAG issues (GOV.UK tool comparison, Deque study). Whether a page is genuinely usable reveals itself only in manual testing: keyboard-only walkthroughs, screen-reader sessions (NVDA, JAWS, VoiceOver), zoom to 200 percent, and checking reading order and error handling in real flows. Accessibility testing is a discipline, not a plugin.

How to start pragmatically

Audit the critical journeys first (login, search, checkout, forms), not every page at once.
Classify findings by user impact, not by tool severity; a broken keyboard trap in checkout outweighs a dozen contrast warnings in the footer.
Fix patterns, not pages: most issues live in shared components; one fixed component heals fifty screens.
Embed checks in the pipeline: automated rules on every commit, manual audits per release.

Our take

Accessibility is the rare compliance topic that genuinely improves the product for everyone: clearer focus states, better forms, more robust markup. If the EAA applies to you (or your customers), a scoped audit tells you within days where you stand. That's exactly what our QA Health Check or a dedicated accessibility audit delivers. Or talk to us about your specific case.