Directive (EU) 2019/882 · EN 301 549 clause 11
The accessibility statement for a mobile app, and where it has to live
An app is a service under the European Accessibility Act, and it carries the same duty as a website: say how it meets the accessibility requirements, publish it where users can read it, and be able to show the test behind it. What changes is the testing, the standard clause that applies and the place the statement has to sit.
An app is covered by the same directive as the website
Directive (EU) 2019/882 covers services, and the definition includes the software used to deliver them. If your consumers in the Union order, book, bank or read through an app, the app is in scope from 28 June 2025, exactly as the website is. Selling only through a marketplace does not move the duty: it stays with whoever provides the service.
The technical reference is EN 301 549. Clause 9 covers web content, clause 11 covers software, and an app is read against clause 11, which imports the WCAG success criteria and adds requirements that only make sense on a device: platform accessibility services, user preferences, and interoperability with assistive technology installed on the phone.
What gets tested on a phone that is never tested on a site
A browser audit misses most of what breaks an app. The list below is where real failures concentrate, and each one has an owner in your codebase rather than in a template.
| Area | What is checked | Typical failure |
|---|---|---|
| Screen reader | VoiceOver on iOS and TalkBack on Android read every control in order | Custom buttons announced as "button", images with no label, focus jumping |
| Text size | System font scaling up to the largest setting | Fixed heights clipping text, tappable areas collapsing |
| Contrast and dark mode | Both themes checked, not only the default | Brand colour readable on white, unreadable on dark |
| Orientation | Portrait and landscape both usable | Orientation locked without a functional reason |
| Gestures | Every gesture has an alternative that is not a gesture | Swipe-only actions with no button |
| Forms and errors | Labels, error text and status messages reach the screen reader | Errors shown in red only, never announced |
| Timing | Sessions, one-time codes and carousels can be extended or paused | A 30-second code entry with no extension |
Where the statement has to be published
Annex V asks for the information to be available where the service is offered, in an accessible format. For an app that means three places, and most providers do only the first.
- In the app itself, under a settings or help entry a screen reader user can reach without signing in.
- On the store listing, in the description or in the accessibility field the platform provides.
- On your website, at a stable URL, so a buyer or an authority can read it without installing anything.
The three copies have to say the same thing. A statement in the app that claims full conformance while the website version lists open barriers is worse than having none at all.
What the statement has to contain
A general description of the service in accessible formats, the explanations needed to use it, how it meets the requirements, the standard applied, the known limitations with a reason and a horizon, and a contact point for reporting a barrier. For an app, name the minimum operating system versions the test covered, because behaviour changes between them and an inspector will ask.
Native, hybrid or web view: it changes the work, not the duty
A native app is tested against clause 11 in full. A hybrid app wrapping web content is tested twice, once for the shell and once for the content inside it, because a perfectly accessible web page can become unusable when the wrapper steals focus. A progressive web app is tested as web content, then checked again once installed on the device, where the browser chrome disappears and the navigation has to survive without it.
What a market surveillance authority actually asks
Complaints about apps arrive through the same channels as complaints about websites, and the first question is always the same: what is the statement based on. The answer has to include a date, the standard, the devices and assistive technologies used, the journeys tested and the barriers still open. A statement generated from a form has none of that, and the gap becomes visible in one email.
How we test an app
We run the journeys you choose on a real device with the screen reader on, at the largest system font, in both themes and in both orientations. Automatic tools contribute what they can, which on a mobile build is a small part. Everything we find goes into a developer report with the clause, the screen, the steps to reproduce and how to verify the fix.
The record we sign carries a date and a public code, so anyone can check it without asking you. Apps are quoted after a first look, because an app with two screens and one with a full checkout are not the same job.
The store listing is part of the job
Both platforms give you a place to describe accessibility support, and both are read by buyers long before anyone reads your website. Say which assistive technologies the app works with, which system settings it respects and where the full statement lives. A listing that says nothing is read as an app that does nothing.
What we ask you before the test starts
Four answers, and the scope is set: the minimum operating system versions you support, whether the app is native, hybrid or a web view, which journeys carry the revenue, and whether there is a test account we can use. Everything else we work out on the device.
Website first, app next
If the website and the app deliver the same service, test both: the duty follows the service, not the channel. In practice most clients start from the site, which is what a complaint hits first, and add the app in the same cycle so that the statement, the record and the badge stay aligned. See what changes for an online shop and what the 2025 deadline means in practice.
Questions we get before buying
Is a mobile app really covered by the European Accessibility Act?
Yes, where it is used to deliver a covered service to consumers in the Union. The directive covers the service, and the software that provides it comes with it.
Which standard applies to an app?
EN 301 549, clause 11 for software. It imports the WCAG success criteria and adds requirements specific to platforms and assistive technology on the device.
Do we need a separate statement for iOS and Android?
One statement can cover both, provided it names each platform, the versions tested and any limitation that exists on one and not the other.
Where do we publish it if the app has no website?
In the app, reachable without signing in, and on the store listing. A stable public URL is still strongly advisable for buyers and authorities.
Does the app store review check accessibility?
No. Store review is not a compliance check and gives you nothing to show an authority.
Are microenterprises exempt for apps too?
Service microenterprises with fewer than 10 staff and no more than 2 million euro are exempt from the service requirements, app included.
Can automatic tools test an app properly?
They catch a minority of real barriers. Gesture alternatives, focus order and screen reader labels need a person on a device.
What if a barrier cannot be fixed quickly?
Name it in the statement as a known limitation, with the reason and what you are doing about it. An honest statement survives scrutiny; a silent one does not.
Do you test apps behind a login?
Yes, with a test account you provide. The journeys that matter are almost always behind the login.
How long does an app test take?
Quoted after a first look, usually within the same five business days as the website once the scope is agreed.
Get the app tested and the statement signed
One test on a real device, one statement, one record with a public code. Apps are quoted after a first look.