In brief
The European Accessibility Act does not regulate "apps" as a separate category. It covers mobile device-based services, including mobile applications, when they are part of an in-scope service, for example banking, e-commerce, passenger transport or communications.
If your app is the front end of such a service, it has to be accessible. Each checklist page includes iOS and Android code examples for this reason.
When is an app in scope?
- General services: Annex I, Section III covers making websites, online applications and mobile services, including mobile apps, accessible.
- Passenger transport: Article 2(2)(c) lists mobile device-based services, including mobile applications, among the covered elements.
- Other in-scope services: Banking, e-commerce, e-books, audiovisual media access and electronic communications are covered, and their apps are part of the service. See EAA scope.
An app that has nothing to do with an in-scope service is not covered by these provisions. Check the scope first.
The four principles
Recital 47 of the Directive names four principles for websites and mobile applications: perceivable, operable, understandable and robust. They are the same four principles as in WCAG.
How the standard treats native apps
EN 301 549 has separate clauses for web content, non-web documents and non-web software. A native iOS or Android app falls under the software clause. The WCAG success criteria are applied there as requirements for software with a user interface.
EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2. It has not yet been cited in the Official Journal of the European Union, so for now it is a voluntary technical route. Some WCAG criteria concern sets of web pages, so they are handled differently for native apps. Check the standard for the exact clauses.
Web content shown inside an app, for example in a web view, is web content and should meet the web requirements.
Where to start in the checklist
These pages have iOS (SwiftUI) and Android (Jetpack Compose) examples:
How to test an app
- Screen readers: VoiceOver on iOS and TalkBack on Android. Go through every main flow without looking at the screen.
- Text size: Set the largest text size in the system settings and check that nothing is cut off or overlaps.
- Switch and keyboard access: Test with Switch Control on iOS, Switch Access on Android, and an external keyboard.
- Automated checks: Use the Accessibility Inspector in Xcode and the Accessibility Scanner on Android. They find only some problems, so manual testing is still needed.
Service information
Publish the information required by Article 13 and Annex V for the service the app belongs to. See service accessibility information. It must be reachable from the app, not only from your website.
What to do
- Decide whether the app is in scope. Check which in-scope service it belongs to.
- Test the main flows with VoiceOver and TalkBack. Sign-in, search, purchase or booking, and settings.
- Test the largest text size. On both platforms.
- Check touch targets and gestures. Offer a simple alternative to complex gestures.
- Link the accessibility information. Inside the app and on the store page where possible.
Common mistakes
- Testing only on the latest phone. Test on the oldest OS version you support, with the accessibility settings on.
- Custom controls with no labels. A screen reader needs name, role and state.
- Fixed font sizes. Text must scale with the system setting.
- Gesture-only actions. Offer a single-tap alternative.
- Ignoring web views. Web content inside the app needs the same checks as the website.
Sources
This page is for informational purposes only and is not legal advice. For binding requirements, refer to the official text of the European Accessibility Act (Directive (EU) 2019/882) and to the national law of the Member State where you operate.
Which pages on your site fail WCAG?
Scan your website and see every WCAG and EAA issue, page by page.