The European Accessibility Act Is Live. Is Your App in Scope?

The European Accessibility Act, usually shortened to the EAA, has applied since June 28, 2025. For a lot of app teams it slipped by quietly, because there was no App Store rejection email and no broken build to force the issue. That is exactly why it is dangerous. The obligation is already live, enforcement sits with national authorities that are now staffing up, and 2026 is the year the first complaints and audits start landing. If your app sells something, handles money, or delivers a covered service to users in the EU, you are very likely in scope, whether or not your company is based in Europe. This guide explains who the law covers, what standard you actually have to meet, the failures that trip up most apps, and a practical way to audit before someone files a complaint.

What the European Accessibility Act actually is

The EAA is Directive (EU) 2019/882. It is a single piece of EU law that sets common accessibility requirements for a defined list of products and services, so that a person with a disability gets a comparable experience across the whole single market instead of 27 different national rules. Member states wrote it into their own national laws, and those national laws are what enforce it.

The important shift for software teams is that the EAA does not just talk about hardware or physical access. It explicitly covers digital services and the apps that deliver them. A banking app, a shopping app, an e-book reader, a ticketing app: these are services delivered through software, and the law treats the software as part of the service that has to be accessible.

Is your app in scope?

This is the question that matters, so it is worth being precise. The EAA covers a specific set of services, and the rule of thumb is simple. If your app is the way a user reaches one of these services, the app has to be accessible.

The covered services include consumer banking and payment services, e-commerce, electronic communications, e-books, ticketing and check-in for passenger transport, and access to audiovisual media services. Plenty of mainstream apps fall into at least one of these buckets without their makers ever thinking of themselves as an accessibility case.

A few things widen the net further than people expect. The law applies to non-EU companies too. If you are a US or UK developer selling into the EU market, you are covered the same as a company in Berlin. It also applies regardless of how the app is distributed, so going through the App Store or Google Play does not change anything.

There is one meaningful carve-out. Microenterprises, meaning businesses with fewer than 10 staff and an annual turnover or balance sheet under 2 million euro, are exempt when they provide services. Note that this exemption is narrower for products than for services, and it is not a free pass. If you grow past the threshold, the obligation arrives with you, so building accessibility in early is cheaper than retrofitting it later.

The standard you have to meet: EN 301 549 and WCAG

The EAA itself is written in terms of outcomes rather than line-by-line technical rules. The practical standard that regulators point to is EN 301 549, the European standard for accessibility of ICT products and services. EN 301 549, in turn, leans on the Web Content Accessibility Guidelines, the WCAG, which is the same body of guidance the rest of the world uses.

The level to aim for is WCAG conformance at AA. That covers the four principles at the heart of WCAG, often remembered as perceivable, operable, understandable and robust. In plain terms: a user has to be able to perceive the content (so text alternatives, contrast, captions), operate the interface (keyboard and assistive-technology navigation, no traps), understand it (clear labels, predictable behavior) and rely on it working with assistive tech (clean, well-structured markup and accessibility metadata).

EN 301 549 currently references WCAG 2.1, and it is being updated to fold in WCAG 2.2. If you build to WCAG 2.2 AA now, you are ahead of the standard rather than chasing it.

The accessibility failures that show up most in apps

Auditors and assistive-technology users tend to find the same handful of problems over and over. These are the ones worth checking first.

Unlabeled controls. Icon-only buttons with no accessibility label are invisible to a screen reader, which announces them as "button" with no idea what they do. This is probably the single most common mobile failure.

Poor color contrast. Light grey text on white, or thin coloured text on a busy background, fails the contrast thresholds and is unreadable for many users.

Touch targets that are too small or too close together, which makes the app unusable for people with motor impairments.

Content that only works one way. Information conveyed by color alone, error states shown only with a red border, or audio with no captions all exclude a slice of users.

Dynamic content that does not announce itself. A loading spinner, a toast message or a validation error that updates visually but never reaches the screen reader leaves some users stuck without knowing why.

Forms without proper labels and grouping, which turns a simple sign-up into a guessing game for anyone not using the screen.

How to audit your app for EAA compliance

You can get a long way with a structured pass before bringing in any specialist tooling. Here is a sequence that works.

1. Confirm scope first. Write down which covered service your app delivers. If you genuinely deliver none of them and you are not a covered product, document why. If you do, treat the rest of this list as mandatory.

2. Run the platform accessibility scanners. Both Apple and Google ship accessibility inspectors and audit tools that catch a meaningful share of issues automatically, including missing labels, contrast problems and small touch targets.

3. Test with the real assistive technology. Turn on VoiceOver on iOS and TalkBack on Android and try to complete your core flows using only the screen reader. If you cannot finish a purchase or a login by ear, neither can your users.

4. Check keyboard and switch navigation. Make sure every interactive element is reachable and operable without touch, in a logical order, with no traps.

5. Verify dynamic announcements. Trigger your loading states, errors and confirmations and confirm the screen reader announces them.

6. Document conformance. The EAA expects you to be able to show your reasoning. Keep an accessibility statement and a record of what you tested and fixed.

What enforcement looks like and why 2026 matters

Because the EAA is enforced through national law, the exact mechanism and the size of penalties vary by member state. The common shape is that a national market-surveillance authority can investigate, often triggered by a user complaint, require you to fix the issue, and impose fines or, in serious cases, restrict the service if you do not.

The reason 2026 is the year to act is timing. The obligation became live in June 2025, but enforcement bodies do not flip a switch overnight. They publish guidance, set up complaint channels and build up cases. The apps that get caught first are usually the high-traffic ones in obvious scope, banking and e-commerce above all, where a single complaint from a frustrated user is enough to start the process.

Where automated scanning fits

Accessibility is partly a human-testing problem, and nothing fully replaces a real person using a screen reader. But a large share of EAA-relevant failures are detectable automatically and, crucially, they regress. A new screen ships, a label gets dropped, contrast slips below threshold, and you are non-compliant again without anyone noticing.

This is where continuous scanning earns its place. A tool like AppCompliance can check your app against accessibility rules as part of every build, alongside the other regulatory checks you need for the EU market, and flag a missing label or a contrast failure before it ships rather than after a complaint. It turns accessibility from a one-off project into a standing gate, which is the only way it stays fixed.

If you want to see how this connects to the wider EU picture, accessibility sits next to the obligations we cover in our pieces on DSA trader status and the Cyber Resilience Act. Together they are reshaping what it means to put an app on the EU market.

FAQ

Does the European Accessibility Act apply to my mobile app?

If your app delivers a covered service to users in the EU, yes. Covered services include consumer banking, e-commerce, electronic communications, e-books, passenger-transport ticketing and access to audiovisual media. It applies to non-EU companies selling into the EU too.

When did the EAA come into force?

Its requirements have applied since June 28, 2025. The obligation is already live, and national enforcement is ramping up through 2026.

What accessibility standard do I need to meet?

In practice, WCAG conformance at the AA level, as referenced by the European standard EN 301 549. EN 301 549 currently points to WCAG 2.1 and is being updated toward WCAG 2.2.

Is there an exemption for small companies?

There is a microenterprise exemption for service providers with fewer than 10 staff and turnover or balance sheet under 2 million euro. It is narrower for products, and it disappears as soon as you grow past the threshold.

What happens if my app is not accessible?

Enforcement is handled by national authorities and varies by country, but it typically means investigation after a complaint, a requirement to fix the issue, and fines or service restrictions if you do not.

How often should I re-check accessibility?

Treat it like any other regression risk and check on every release. New screens and redesigns are where accessibility most often breaks.