Preparing mobile apps for the European Accessibility Act (EAA)

What changed and who it affects

Mandatory digital accessibility applied only to the public sector for years. The European Accessibility Act (Directive 2019/882; in the Czech Republic, Act No. 424/2023 Coll.) extends it, for the first time as of June 28, 2025, to commercial services too: online retail, consumer banking, ticket sales, telecommunications, streaming and e-books.

The obligation applies to the service as a whole: if you run an online store, it applies equally to the website and the mobile app. New services must comply right away; services already operating before June 2025 have until June 28, 2030. Micro-enterprises providing services – companies with fewer than 10 employees and turnover under EUR 2 million – are exempt.

Enforcement mainly falls to the Czech Trade Inspection Authority, and the law allows fines of up to CZK 10 million. For most businesses, though, the practical reasons matter more: accessibility is often a condition in public tenders and corporate procurement, and accessibility features such as a screen reader or larger text are used regularly by 10–15% of mobile app users, for whom an inaccessible app makes checkout difficult or impossible.

What accessibility means in practice

The technical benchmark is the European standard EN 301 549, which for apps adopts the WCAG 2.1 level AA rules. What they actually require is easiest to see in situations that come up in apps every day.

A blind user operates their phone with a screen reader: VoiceOver on iOS, TalkBack on Android. The screen reader reads out loud whatever is under their finger. In a well-built app, they hear "Add to cart, button." In a poorly built one, they hear just "button" – or nothing at all for an icon with no label – and the purchase never gets completed. A low-vision user enlarges the text, and an unprepared app truncates it or breaks the screen layout. Someone with a hand tremor needs sufficiently large touch targets, and no function can depend on a precise gesture.

From a development perspective, this comes down to a set of verifiable properties:

How we verify and maintain accessibility

We work through it step by step:

1. 1

   Initial audit

   We go through the app from the perspective of users with different limitations, manually test key scenarios with assistive technologies, and back up the results with automated checks.

2. 2

   Findings and a remediation plan

   Every issue is prioritized by its impact on users. We then prepare a fix plan with an estimate of effort, the materials needed, and the right approach.

3. 3

   Automatable fixes

   Tools and AI handle part of the findings – for example, semantic labels for components, image descriptions generated through image recognition, or video captions.

4. 4

   Reviewing the automated fixes

   We manually verify what the tools and AI produce. Anything we can't judge ourselves, such as descriptions and copy specific to your field, we confirm with the client.

5. 5

   Fixes that require judgment

   What's left is work no tool can do, because it needs a human call, typically the clarity of messages, the reading order of screens, or navigation logic.

6. 6

   Final audit

   A repeat pass confirms the app meets the requirements.

7. 7

   Deliverable

   An accessibility statement based on the fixes and tests actually carried out.

How we handle accessibility in development

For new apps, we build accessibility in from the design stage, wherever the project calls for it. We scale the effort to the regulations that actually apply to the app, since requirements vary by industry and by the countries where the service will be available.

Cross-platform development brings a big advantage here. In Flutter, which is what we build our apps in, a single codebase produces a version for iOS, Android, web and desktop. Accessibility doesn't need to be adapted for each platform separately – solve it once and it applies everywhere. With separate native apps, the same work has to be repeated for every platform.

Projects the law doesn't yet cover are a special case. Even there, it pays to build on properly structured components and a design with contrast to spare. That keeps the app open-ended: once accessibility becomes necessary, whether because of legislation, a tender, or new users, labels and tests can be added without rebuilding the screens.

Healthcare apps: a gray area of the law

Medical devices are explicitly excluded from the Act's scope, and purely medical content in an app, such as logging symptoms or a medication overview, isn't among the listed services either. But as soon as an app includes elements of a consumer contract, typically account registration, sign-in, or a subscription, it falls into the "e-commerce" services the Act covers. Exactly where that line sits in a given app isn't always clear, and lawyers across EU member states don't agree on how to interpret it.

We ran into this ambiguity with our client Teva and its app Migraine Compass, a migraine diary for patients and doctors that we're localizing into additional countries.