App accessibility under the European Accessibility Act means that mobile apps used to deliver services covered by the Act, such as online shopping, consumer banking, e-books and passenger transport, must be usable by people with disabilities, including people who rely on screen readers, larger text, voice control or switch access. Since 28 June 2025 these requirements apply across the EU, and the practical benchmark for meeting them is the harmonised standard that builds on the Web Content Accessibility Guidelines. This guide explains which apps are covered, what the requirements mean in design and code, where to start and how to measure progress.
Last updated: 9 November 2026.
What is the European Accessibility Act?
The European Accessibility Act is an EU directive that sets common accessibility requirements for a list of products and services sold to consumers. Its official text is Directive (EU) 2019/882, and its rules apply from 28 June 2025. Each member state has transposed it into national law; in Germany, for example, it takes the form of the Barrierefreiheitsstärkungsgesetz (BFSG).
The aim is simple: people with disabilities and older people should be able to buy and use the same everyday digital services as everyone else, and companies should face one set of rules across the single market rather than a different one in each country.
At Odduel, a creative and technology agency in Barcelona and São Paulo, accessibility is part of how we plan, design and build apps in our application development service, not a test added at the end.
In short: the European Accessibility Act covers apps that deliver services within its scope, such as e-commerce, consumer banking, e-books and passenger transport. Those apps must be perceivable, operable, understandable and robust for people with disabilities. Start with an audit against the harmonised standard, fix the most used journeys first, build accessibility into design and code, and publish the required accessibility information.
Does the EAA apply to apps?
Yes. The Directive covers services provided to consumers in a number of sectors, and it explicitly includes services delivered through mobile devices, including mobile applications. If your app is the way customers access a covered service, the app is in scope.
The covered services include:
- E-commerce services: apps through which consumers buy products or services online.
- Consumer banking services: banking and payment apps for consumers.
- E-books and dedicated reading software.
- Electronic communications services, such as calling and messaging services.
- Services providing access to audiovisual media, such as streaming platforms.
- Elements of air, bus, rail and waterborne passenger transport services, including apps, ticketing and real-time travel information.
The Directive also covers certain products, such as smartphones, computers, payment terminals and ticketing machines, but the obligations for an app developer or app owner mostly come through the services above.
Which apps are usually outside the scope?
Apps that do not deliver a covered service to consumers are generally outside the Act, such as purely internal business tools or apps that only provide information about a company. Microenterprises that provide services, as defined in the Directive, are exempt from the service requirements. Public sector apps fall under a separate law, the Web Accessibility Directive. Scope questions can be subtle, so confirm your position with a legal adviser in your main market.
Are there transition periods?
The Directive allows some transition. Service providers may continue to deliver services using products they lawfully used before 28 June 2025 until 28 June 2030, and service contracts agreed before that date may continue until they expire, within a five-year limit. These periods do not cover new apps or new releases: anything you design or launch now should meet the requirements.
What does app accessibility under the EAA involve in practice?
The Directive describes requirements in functional terms: information must be perceivable, operable, understandable and robust, and the service must work with the assistive technologies people use. In practice, companies meet this by following the harmonised European standard for digital accessibility, EN 301 549, which takes its web and software criteria from the W3C’s Web Content Accessibility Guidelines and applies them to native apps as well as websites.
The table translates the four principles into everyday app design and development.
| Principle | What it means in an app | Common failures |
|---|---|---|
| Perceivable | Text alternatives for images and icons, sufficient contrast, text that scales with system settings, captions for video | Icon-only buttons with no label; text that does not grow; low-contrast grey text |
| Operable | All functions usable with screen readers, switch access and external keyboards; large enough touch targets; no time limits without control | Custom gestures with no alternative; tiny tap areas; carousels that cannot be paused |
| Understandable | Clear labels and instructions, consistent navigation, helpful error messages | Form errors shown only in red; vague labels such as “Submit” for every action |
| Robust | Correct use of platform accessibility features so assistive technologies read roles, names and states | Custom components that screen readers announce as “button” with no name |
What does this mean for design?
Designers set most of the accessibility of an app before any code exists. Key decisions include:
- colour contrast for text, icons and controls in both light and dark modes;
- layouts that still work when text is enlarged significantly;
- touch targets large enough to hit reliably;
- a visible focus order that matches the visual order;
- labels and instructions written in plain language;
- alternatives to complex gestures such as swipes, drags and pinches;
- states (selected, disabled, error) shown with more than colour alone.
What does this mean for development?
Developers make sure the platform’s accessibility features carry the design’s intent. On iOS and Android this means using native components where possible, giving every control an accessible name, role and state, supporting dynamic type and font scaling, managing focus when screens or dialogs change, announcing important updates and testing with VoiceOver and TalkBack. Cross-platform frameworks support accessibility too, but each needs care with custom components.
Where should a company start with app accessibility under the European Accessibility Act?
A structured plan avoids both panic and paralysis. These steps work for most companies.
- Confirm scope. List the services your apps deliver and check them against the Directive’s categories with your legal adviser.
- Audit the current app. Test against EN 301 549 and WCAG, combining automated checks with manual testing using screen readers, enlarged text and switch access.
- Map the key journeys. Sign-up, sign-in, search, product view, basket, checkout, payment, account and support: the paths every customer must complete.
- Prioritise fixes. Start with barriers that block those journeys completely, then problems that make them very hard, then lesser issues.
- Fix the design system. Correct components once (buttons, inputs, dialogs, navigation) so fixes spread across the app.
- Change the process. Add accessibility criteria to designs, user stories, code review and release testing so new features do not reintroduce barriers.
- Publish accessibility information. The Directive requires service providers to provide information on how the service meets the accessibility requirements, typically in an accessibility statement or the terms and conditions.
- Offer a feedback route. Give users a clear way to report barriers, and act on what they report.
The same principles apply to your website; our guide to website accessibility and the European Accessibility Act covers the web side in detail.
How do you measure whether app accessibility works?
Measurement should combine standards conformance with real use.
| Method | What it shows | Limits |
|---|---|---|
| Automated scanning | Missing labels, contrast problems, some structural issues | Finds only part of the problems |
| Manual expert audit | Conformance against each criterion of the standard | Depends on the auditor’s skill and coverage |
| Assistive technology testing | Whether journeys work with VoiceOver, TalkBack, switch access, enlarged text | Needs trained testers |
| Testing with disabled users | Whether real people can complete tasks with their own set-up | Requires planning and recruitment |
| Feedback and support data | Barriers users meet after release | Arrives after the problem exists |
Useful ongoing measures include the number of open accessibility issues by severity, the share of key journeys that pass manual testing on both platforms, and the time taken to fix reported barriers.
What happens if an app does not comply?
Enforcement is national. Each member state has designated market surveillance authorities that can check services, require corrections and apply penalties set in national law. Rules and penalties therefore differ from country to country. Beyond enforcement, an inaccessible app excludes customers, generates support requests and can harm a brand’s reputation. Treat compliance as part of product quality rather than a one-off legal task.
What should you ask an app development partner about accessibility?
If you work with an outside team, ask these questions before signing:
- How do you build accessibility into design, development and testing?
- Which standard will you test against, and how will you report results?
- Do you test with VoiceOver and TalkBack on real devices?
- How do you handle accessibility in custom components and cross-platform frameworks?
- Will you help us prepare the accessibility information the Directive requires?
Our guide on how to choose an app development company covers the wider selection process.
Questions people ask
Does the European Accessibility Act apply to mobile apps?
Yes. The Act covers services delivered to consumers in sectors such as e-commerce, consumer banking, e-books, electronic communications, audiovisual media access and passenger transport, and it explicitly includes services delivered through mobile applications. If your app is how customers access one of these services, it must meet the accessibility requirements.
Which standard should apps follow to meet the EAA?
Companies generally follow EN 301 549, the harmonised European standard for digital accessibility. Its criteria for web content and software draw on the W3C Web Content Accessibility Guidelines and apply to native mobile apps as well as websites. Conforming to the harmonised standard gives a presumption of meeting the corresponding requirements.
Where should a company start with app accessibility?
Confirm whether your app delivers a covered service, then audit it against the standard with automated and manual testing, including screen readers. Prioritise barriers on key journeys such as sign-in, search and checkout, fix shared components first, add accessibility to your process and publish the required accessibility information.
Are small companies exempt from the EAA?
Microenterprises that provide services, as defined in the Directive, are exempt from its requirements for services. Other small and medium-sized companies are covered if they provide services within its scope. Because the definitions matter, check your situation with a legal adviser in the country where you mainly operate.
How do you test an app for accessibility?
Combine automated scans with manual testing. Use VoiceOver on iOS and TalkBack on Android, enlarge system text, test with an external keyboard or switch access, check contrast and labels, and walk through every key journey. Testing with disabled users gives the clearest picture of whether people can actually complete tasks.
Start with a scope check and an audit of your app’s key journeys; together they show how much work lies ahead. If you need an app designed and built to be accessible from the first screen, read more about our application development service or contact us to discuss your app. This article is general information, not legal advice.
