Manual mobile app accessibility testing
Accessibility testing for mobile apps
Native iOS and Android, React Native and Flutter — on real devices with screen readers, not in an emulator. The standard is EN 301 549 clause 11, "Software".
We reply during business hours
The law names apps explicitly
This is not a nice-to-have. Four documents mention mobile apps in their own right.
European Accessibility Act
Directive (EU) 2019/882 has applied since 28 June 2025. It covers the apps of banking, e-commerce, transport, e-book and telecom services.
BFSG · Germany
The German implementation of the EAA, same date. On the German market this is the document buyers cite when they ask about your app.
Ukraine: Resolution 895
Clause 7 obliges providers of universal electronic communications services to make both websites and mobile apps accessible. In force from 15.07.2028.
EN 301 549 V3.2.1
The technical standard both EU and Ukrainian requirements point to. For apps it is clause 11 that applies, not clause 9.
Clause 11 is not the same checklist as the web one
EN 301 549 assesses a web page under clause 9, which references WCAG. A native app is assessed under clause 11, "Software", with its own requirements for names and roles, focus, gestures and system settings. A website audit does not cover the app, even when both show the same data.
There is almost no automation for apps
On the web automation is mature: our Audit walks a site daily against 90+ rules. Native apps have no tooling at that level. Android Accessibility Scanner and Xcode Accessibility Inspector catch the basics: missing labels, small touch targets, weak contrast. Focus order, gesture logic, state announcements and behaviour at system-level font scaling are invisible to them.
So everything that matters is walked by hand
A tester walks every user journey on a real device with the screen reader on — sign-up, payment, changing settings. That is how you find screens you cannot leave, buttons with no name, modals that never take focus, and forms whose errors are never announced.
Both platforms, real devices
An emulator reproduces neither the screen reader nor the system accessibility settings
iOS
Key journeys with VoiceOver on a physical iPhone: focus order, rotor gestures, element names and roles, Dynamic Type and Voice Control, behaviour under Switch Control.
Android
The same with TalkBack across device generations and OS versions: announcements, traversal order, Switch Access, behaviour after a font-size or display-scale change.
React Native, Flutter and native code
Cross-platform apps are tested as native ones — from the user side there is no difference. The report states where the cause sits: your code, a framework component, or the build configuration.
What exactly we check
Eight areas, each on both platforms
Screen reader and focus order
Every screen is walked by ear: do all elements have names and roles, does traversal order make sense, does focus get lost in modals, and is there a way out of them.
Touch targets and gestures
At least 44×44 pt on iOS and 48×48 dp on Android, enough spacing between adjacent controls, and an alternative to complex gestures — swipe, long press, drag.
Text scaling
Dynamic Type on iOS and system font size on Android at their largest: no clipping, no overlap, no buttons pushed off-screen.
Contrast and themes
Light and dark themes, high contrast mode, colour inversion, and the readability of text over images and video.
Orientation and motion
Portrait and landscape with no loss of content, system Reduce Motion respected, and no automatic animation that cannot be stopped.
Forms and errors
Field labels, hints, keyboard type, error announcements, and the ability to correct input without losing what is already filled in.
Media and timeouts
Video captions, playback control, audio autostart, and every place the app puts a clock on an action — SMS codes, sessions, carts.
System settings
Whether the app respects what the person already set on their phone: bold text, reduced transparency, disabled animation, larger pointer, an external keyboard.
What you get
- A report of every issue mapped to EN 301 549 clause 11 and to WCAG criteria, ranked by severity with an estimate of the fix effort
- Screen recordings with the screen reader on — you see and hear exactly what breaks, so a developer does not have to reproduce the bug blind
- A prioritised action plan: fix before release, next sprint, or requires a change to the navigation architecture
- A re-check of the critical issues once you have fixed them
Pricing
Quoted from a brief
The price depends on the number of screens, the platforms, and whether you want sessions with real users. Send us the app or describe it and we will come back with a quote and a timeline.
Send a briefNeed the website too? Manual website testing
Frequently asked questions
Can an app be tested automatically, like a website?
Partly. Android Accessibility Scanner and Xcode Accessibility Inspector find missing labels, small touch targets and weak contrast. But native apps have nothing at the level of web scanners: focus order, gesture logic, state announcements and behaviour at large font sizes have to be walked by hand on a device.
Does this work for React Native and Flutter?
Yes. From the user side there is no difference — the screen reader works with whatever the platform exposes. The report separately states where the cause sits: your code, a framework component, or the build configuration, because the fix differs in each case.
Which standard applies to apps?
EN 301 549, clause 11 "Software". This matters: web pages are assessed under clause 9, which references WCAG, while apps fall under clause 11 with its own requirements for names, roles, focus and system settings. A website audit does not cover the app, even when both hold the same data.
Which devices do you test on?
Physical ones. An emulator reproduces neither the screen reader, nor the system accessibility settings, nor real gestures. We use several device generations and OS versions, because TalkBack and VoiceOver behave differently between them.
Do we also need a website audit?
If you have both a site and an app — yes, these are two separate assessments under different clauses of the standard. The site is covered by the automated Audit plus manual testing; the app by manual testing only. Ordering both together costs less than separately, because part of the preparation is shared.
Tell us about your app
We come back during business hours with a quote, a timeline and the list of what we will test.
Send a briefBrief → proposal with a timeline and a price