Skip to content
wcagc
←Back to blog
EAAmobileEN 301 549WCAGaccessibility-statement

EAA compliance for mobile apps: what's required

Does the EAA cover your mobile app? What's in scope, which standard applies, and how to check and document your app's accessibility.

P

Pavel Charkasau

EAA mobile app compliance turns on one thing: if a consumer uses your app to reach an in-scope service, the app has to meet the same accessibility bar as your website. The European Accessibility Act names mobile apps directly. Its definition of e-commerce services covers services "provided at a distance, through websites and mobile device-based services" (Directive (EU) 2019/882, Article 3(30)), and passenger transport obligations refer to "mobile device-based services including mobile applications" (Article 2). So an app is not a lesser surface the Act forgets about. It is in scope on the same terms as the web.

The technical standard is EN 301 549, the same harmonized standard the EAA relies on for websites. For a native app, the relevant part is Chapter 11 (software), which applies WCAG 2.1 Level AA success criteria to non-web software and adds requirements that only make sense off the web. An automated scan can clear the machine-detectable defects on your web and in-app web content; native gestures, focus order, and screen-reader output need a person with VoiceOver and TalkBack. No plugin makes an app conformant on its own.

Here is what applies to a mobile app, and how to check it.

Does the European Accessibility Act cover mobile apps?

Yes, when the app delivers an in-scope service to a consumer. The EAA has applied across member states since 28 June 2025 (European Commission). It covers a defined set of consumer-facing services: electronic communications, access to audiovisual media services, elements of air, bus, rail and waterborne passenger transport, consumer banking, e-books, and e-commerce (Article 2). The Act repeatedly ties those services to the app that delivers them, not just the website.

That matters because a lot of teams treat the app as optional. If your banking service, store, or booking flow is available through an iOS or Android app, that app is a channel for an in-scope service, and the accessibility duty follows the service onto the phone. Building an accessible website and shipping an inaccessible app does not satisfy the Act. The consumer who relies on a screen reader is entitled to complete the same task in either place.

Two familiar limits still apply, exactly as they do on the web:

  • The microenterprise carve-out is narrow. A service provider with fewer than 10 people and annual turnover or a balance sheet total of €2 million or less is exempt from the service accessibility requirements (Article 4(5) and Article 3(23)). Both conditions must hold.
  • Location does not exempt you. The Act follows the EU market. An app offered to consumers in the EU is covered regardless of where the company sits.

What standard does a mobile app have to meet?

EN 301 549, and for a native app the part that governs is Chapter 11, "Software." The EAA sets the goal (a service should be perceivable, operable, understandable, and robust) but does not list the checks. For those it points to the harmonized standard, and meeting the relevant clauses gives a presumption of conformity with the law. The version cited today is EN 301 549 v3.2.1 (ETSI).

Chapter 11 takes the WCAG 2.1 Level AA success criteria and applies them to non-web software, following the W3C's WCAG2ICT guidance on how each criterion reads when there is no browser. In practice, most of WCAG carries over: labels, contrast, keyboard (or switch and external-keyboard) operability, focus order, error identification, and status messages all apply to an app screen the way they apply to a web page.

Chapter 11 then adds clauses that only exist because an app runs on a platform. Two of the most commonly missed:

  • Clause 11.6: don't defeat platform accessibility. An app must not disrupt the accessibility features the operating system provides. If a custom control breaks VoiceOver focus or a self-drawn view is invisible to TalkBack, the app is failing here even if the same content would pass on the web.
  • Clause 11.7: respect user preferences. An app must honour the platform's accessibility settings, including the user's system font-size choice. Text that ignores Dynamic Type on iOS or the system font scale on Android fails, because the person who enlarged their text can no longer read yours.

So "we passed a WCAG audit" is necessary but not sufficient for a native app. The web success criteria are in there, but Chapter 11 asks for more.

Which WCAG criteria bite hardest on mobile?

Several WCAG 2.1 criteria were written with touch and small screens in mind, and they are where apps most often fall down:

  • 1.3.4 Orientation: the app must work in both portrait and landscape unless a specific orientation is essential. Locking to portrait for no reason fails.
  • 1.4.10 Reflow and 1.4.4 Resize text: content has to remain usable when text is enlarged, without horizontal scrolling or clipping. This is the on-screen consequence of Clause 11.7.
  • 2.5.1 Pointer Gestures: anything driven by a multi-finger or path-based gesture (pinch, swipe-to-a-target) needs a single-pointer alternative, such as a button.
  • 2.5.2 Pointer Cancellation: an action should complete on release, not on touch-down, so a user can slide off and cancel.
  • 2.5.4 Motion Actuation: if a function is triggered by moving the device (shake to undo), there must be a standard control that does the same thing, and a way to turn motion off.

None of these are exotic. They are the criteria a keyboard-and-mouse web tester tends to skip and a real device test catches immediately.

How do I test a mobile app for EAA compliance?

Work in two layers, and be honest about what each one reaches.

Layer one: automated checks where they apply. Automated tooling is strong on web content and on the machine-detectable parts of an app: missing labels, low contrast, small touch targets, and structural issues in any in-app web views or your marketing and account pages. If your app is a wrapper around web content, or has a companion responsive site, run a free scan of those surfaces to clear the obvious defects fast. Native platforms also ship first-party linters, Android's Accessibility Scanner and Xcode's Accessibility Inspector, that flag issues a general web scanner cannot see.

Layer two: manual testing on real devices. This is the larger share for a native app. Turn on VoiceOver (iOS) and TalkBack (Android) and complete the core task by voice alone. Can you reach every control, in a sensible order? Are icons and images labelled, or does the screen reader announce "button, button, button"? Does focus move into a modal and back out when it closes? Enlarge the system font to its maximum and check the screens still hold together. Test both orientations.

How much does automation catch? Deque's analysis of more than 2,000 audits found automated testing identified about 57% of issues by volume, and closer to 30% measured against WCAG success criteria (Deque, 2021). That study is web-focused; on native apps, where automated tools see less of the interface, the manual share is generally larger. Scan what you can, then run a structured manual pass with our WCAG checklist so the rest does not slip through.

Do I need an accessibility statement for the app?

For an in-scope service, yes. The EAA expects a provider to explain how the service meets the accessibility requirements, and that documentation covers the app as much as the website. An honest accessibility statement records your conformance level, lists known limitations, gives a plan and a timeline for fixing them, and offers a way to report problems. Documented effort is what the law asks for, not a perfect score, which no tool can promise anyway.

The overreach the law punishes is claiming more than you can back up. In 2025 the US Federal Trade Commission approved a final order requiring the overlay vendor accessiBe to pay $1 million over claims that its widget could make any site WCAG compliant (FTC, April 2025). The same caution applies to a "make our app accessible" SDK. Real conformance comes from labels, focus handling, and gesture alternatives in your own code, verified on a device.

Frequently asked questions

Does the EAA apply to native mobile apps, or only websites?

Both. The Act's definition of e-commerce services covers services provided "through websites and mobile device-based services," and its transport provisions name mobile applications directly. If a consumer uses your app to reach an in-scope service, the app is covered on the same terms as the site.

What accessibility standard does a mobile app follow?

EN 301 549 v3.2.1, and for a native app the governing part is Chapter 11 (software). It applies WCAG 2.1 Level AA to non-web software and adds platform clauses, such as not defeating built-in accessibility features and respecting the user's system font size.

Is passing a WCAG audit enough for a native app?

It is necessary but not complete. WCAG 2.1 AA sits inside EN 301 549 Chapter 11, but Chapter 11 adds requirements, such as respecting platform settings and not disrupting assistive technology, that a web-only audit does not check.

Can an automated tool test my whole app?

No. Automated tools catch the machine-detectable issues, roughly 57% by volume on the web and generally less on native, and platform linters help. Screen-reader operation, focus order, and gesture alternatives need manual testing on a real device.

Does an accessibility statement need to mention the app?

Yes, for an in-scope service. The statement should cover every channel the service is delivered through, including the app: its conformance level, known limitations, and how to report problems.

Check the surfaces you can, then test the rest

The quickest way to make EAA mobile app compliance concrete is to start with what a scanner can see. Run a free scan of your app's web content, in-app web views, and account pages to clear the machine-detectable issues, then work through the manual checklist on a real device for gestures, focus, and screen-reader output. You will end with a fix list in priority order and the evidence you need for your accessibility statement.

Pavel Charkasau, founder, wcagc.com. Last updated 9 July 2026.

Sources