Tolaron
A phone in a navy case on grey paper with a coral-rimmed magnifying lens over its screen, beside a white card embossed with braille

Does the European Accessibility Act apply to your app?

By Zdeněk Dolák, Founder7 min read

Which consumer apps the European Accessibility Act covers, who is exempt, what accessible means in an iOS and Android app, and how to audit one.

If consumers use your app to shop, bank, make payments, buy travel or use a phone or internet service, the European Accessibility Act most likely applies to it, and it has done since 28 June 2025. The only size exemption is for microenterprises: fewer than 10 people and no more than EUR 2 million in turnover or balance sheet total. A company of 50 or 250 people is not exempt. There's no general transition period for existing apps either.

This article explains which apps the act covers, what "accessible" means in a native iOS and Android app, and how to find out where an existing app stands. It's general information, not legal advice. Whether the act applies to your particular service is a question for a lawyer.

Which apps the act covers

The European Accessibility Act is Directive (EU) 2019/882. Czechia transposed it as Act No. 424/2023 Coll., on accessibility requirements for certain products and services. The act covers these services when they're provided to consumers:

  • Electronic communications, such as mobile, internet and messaging services.
  • Services that give access to audiovisual media, such as TV and streaming platforms.
  • Parts of air, bus, rail and waterborne passenger transport, including websites and apps, e-tickets and real-time travel information.
  • Consumer banking: payments, payment accounts, electronic money, consumer credit, mortgages and some investment services.
  • E-books and the software used to read them.
  • E-commerce: selling products or services online to consumers.

Mobile apps are named explicitly. The directive's requirements cover "mobile device-based services, including mobile applications", alongside websites.

Urban, suburban and regional transport is a partial exception. Its transport obligations cover only self-service terminals, such as ticket machines. That doesn't settle the question for a city transport app that sells tickets, because selling online is also e-commerce. If that's your case, don't assume you're out.

Who is not covered

  • Business-to-business and internal apps. The service obligations apply to services provided to consumers. An app used only by business customers or by your own staff is generally outside them. If consumers can also use it, assume it's in scope until a lawyer tells you otherwise.
  • Microenterprises. Under the Czech act, the service rules don't apply to a provider with fewer than 10 people and turnover or balance sheet total of no more than EUR 2 million. The figures include linked and partner companies, so a small subsidiary of a larger group usually doesn't qualify.

There's no exemption for small or medium-sized companies as such.

Is there a grace period for an existing app?

Not a general one. The directive gives a transition period until 28 June 2030 for products a provider already used before June 2025, such as hardware and terminals. Contracts agreed before 28 June 2025 may also continue unchanged until they end, and no later than 28 June 2030. Neither is a blanket delay for an app offered to new customers or one that keeps being updated. If you plan to rely on the contract carve-out, take legal advice first.

What "accessible" means in a native app

The act describes the result rather than the code: the service has to be perceivable, operable, understandable and robust for people with disabilities. In an iOS and Android app, that comes down to concrete, testable things:

  • Screen readers. Every button, icon and image has a meaningful label for VoiceOver on iOS and TalkBack on Android, and the reading order follows the screen.
  • Text size. The layout still works when someone sets a large system font size. Text isn't cut off and nothing overlaps.
  • Contrast and colour. Text and controls have enough contrast, and colour is never the only way information is shown, such as a red field for an error.
  • Touch targets. Controls are large enough to hit and far enough apart.
  • Gestures and timing. Anything done with a swipe or a complex gesture has a simple alternative, and time limits can be extended.
  • Forms and errors. Fields have visible labels, errors say what went wrong and how to fix it, and the screen reader announces them.
  • Media and motion. Video has captions, and animation respects the system's reduce-motion setting.

Sign-in, payments and signing

For banking and e-commerce, the directive names the sensitive parts explicitly. Identification, electronic signatures, security steps and payments have to be accessible too. In an app, that means the sign-in screen, the one-time code and strong customer authentication step, the payment sheet and the signing flow. These screens are often supplied by a third-party SDK, but if you control or pay for that component, it's part of your service. For banking, the information given to customers shouldn't be more complex than level B2 of the Common European Framework of Reference for Languages.

What else a provider has to do

Accessibility isn't only the app's screens. Under the Czech act, a provider also has to:

  • Publish information on how the service meets the requirements, in its general terms and conditions or an equivalent document, and keep it available while the service runs.
  • Make support accessible. If you run a help desk or call centre, it has to be able to explain the service's accessibility and how it works with assistive technology.
  • Fix and report. If the service doesn't meet the requirements, take corrective action and inform the supervisory authority.

There are two narrow exceptions: a fundamental alteration of the service, and a disproportionate burden. Both require a documented assessment. In Czechia you also have to inform the authority before the service starts. The directive says lack of priority, time or knowledge is not a legitimate reason, so treat these as exceptions, not a plan.

Which standard to build against

The act sets functional requirements and doesn't name a technical standard. In practice, the recognised benchmark is the European standard EN 301 549. It incorporates the WCAG 2.1 AA level of the Web Content Accessibility Guidelines, and its newest version, V4.1.1 from September 2026, moves to WCAG 2.2 AA. Once that version is cited in the EU Official Journal, meeting it will give a legal presumption of conformity under the act. When this article was written, it had not yet been cited.

If you're building or fixing an app now, WCAG 2.2 AA, applied to native screens as EN 301 549 describes, is the sensible target. Czech banks can also look at the Czech Banking Association's accessibility standard, which is an industry recommendation rather than law.

Who supervises it in Czechia

The Czech Trade Inspection Authority (ČOI) supervises most services the act covers, including banking and payment apps, e-commerce and e-books. The Czech Telecommunication Office (ČTÚ) covers electronic communications, and transport has its own authorities. Fines under the Czech act go up to CZK 10 million per offence for a service that doesn't meet the requirements. Authorities also publish a list of non-compliant services.

How to find out where your app stands

  1. Decide whether the act applies. Which of the covered services does the app provide, to consumers, and is your company a microenterprise? Write down the answer and why.
  2. Pick the key journeys. Sign-up, sign-in, the main task (a payment, an order, a ticket), support and settings.
  3. Run the automated checks. Xcode's Accessibility Inspector and Google's Accessibility Scanner find missing labels, low contrast and small touch targets. They catch only part of the problems.
  4. Test by hand. Go through each journey with VoiceOver and TalkBack switched on, with the largest text size, and without relying on colour.
  5. Check the third-party parts. Sign-in, payment and identity-verification SDKs, and web views inside the app.
  6. Test with people who use assistive technology, if you can. They find what a checklist misses.
  7. Write down the findings, fix them in order of severity, and update the accessibility information in your terms.
AreaWhat to checkWho usually owns it
ScopeCovered service, provided to consumers, company size including the groupLegal or compliance, with the product owner
Screen readersLabels, reading order and announcements on every key screen, in VoiceOver and TalkBackApp developers, confirmed by testing
Text and contrastLargest system font size, contrast, no information shown by colour aloneDesign and app developers
Sign-in and paymentsLogin, one-time codes, strong authentication, payment and signing screens, including third-party SDKsApp developers, security and the SDK vendor
SupportHelp desk can explain accessibility and works in accessible channelsCustomer support
Published informationHow the service meets the requirements, in the terms or an equivalent documentLegal or compliance
Ongoing releasesAccessibility checks in design review and testing for each releaseProduct owner and the whole team

Next step

Most of the fixes live in the app itself: labels, layouts that handle large text, contrast, accessible sign-in and payment screens. If you'd like a second opinion on an existing iOS or Android app, send a short description through the contact page: what the app does, who uses it, and whether you've run an audit before. If you're planning a new app, accessibility belongs in the brief from the start. See what to send before asking for a mobile app proposal.

This article is general information, not legal advice. It reflects Directive (EU) 2019/882 and Czech Act No. 424/2023 Coll. as at September 2026. Whether and how the act applies to your app depends on your specific service; consult a qualified lawyer.

Sources