Your app talks to VoiceOver and TalkBack. We check what it says.
A native app exposes a second interface made of labels, traits, and focus order, and screen readers, switches, and large-text settings all depend on it. We test that interface on real iPhones and Android phones, then show your developers the exact code to change.
Apps fail differently than websites
A native app inherits accessibility from the platform's standard controls, and loses it the moment a team builds a custom one. A tappable card made from a plain view has no role. An icon button has no label. A bottom sheet slides up and VoiceOver keeps reading the screen behind it.
Mobile adds demands of its own. People set very large text sizes and expect layouts to grow without truncating. They use apps in landscape on a wheelchair mount, or with a switch instead of touch. Not everyone can perform a two-finger swipe, a long press, or a shake.
None of this shows up in a design review or a simulator screenshot. It shows up when someone turns on VoiceOver, sets the largest text size, and tries to book an appointment. That is how we test.
What we test on each platform
Each check maps to a WCAG success criterion and to the platform's own design guidance.
| What we check | iOS | Android | Reference |
|---|---|---|---|
| Screen reader | VoiceOver: labels, traits, rotor, focus order, and announcements | TalkBack: content descriptions, roles, state, reading order, and live regions | SC 4.1.2 Name, Role, Value; SC 1.3.2 Meaningful Sequence |
| Switch and keyboard | Switch Control, and a hardware keyboard with Full Keyboard Access | Switch Access, and a hardware keyboard | SC 2.1.1 Keyboard; SC 2.4.3 Focus Order |
| Large text | Dynamic Type, including the larger accessibility sizes | Font size and display size settings | SC 1.4.4 Resize Text |
| Orientation | Portrait and landscape, unless one is essential | Portrait and landscape, unless one is essential | SC 1.3.4 Orientation |
| Touch targets | Apple's guidance: at least 44 by 44 points | Material guidance: at least 48 by 48 dp | SC 2.5.8 Target Size (Minimum): 24 by 24 CSS pixels on the web |
| Gestures and motion | Alternatives to multi-finger gestures and shake; Reduce Motion respected | Alternatives to complex gestures; Remove animations respected | SC 2.5.1 Pointer Gestures; SC 2.5.4 Motion Actuation |
Shared code still needs platform-specific testing
VoiceOver and TalkBack read the same cross-platform component differently, so we test each build on its own platform and write fixes for the code you actually have.
SwiftUI and UIKit
We check accessibilityLabel, traits, grouping with accessibilityElement(children:), and the notifications that move VoiceOver focus after a screen changes.
Jetpack Compose and Android Views
We check contentDescription, Modifier.semantics, merged descendants, stateDescription, and live regions for content that updates without a tap.
React Native
We check accessibilityLabel and accessibilityRole, or the newer aria-label and role props, along with grouping and AccessibilityInfo announcements on both platforms.
Flutter
Flutter draws its own pixels, so the semantics tree is all assistive technology gets. We check Semantics, MergeSemantics, and ExcludeSemantics, and every custom painter that exposes nothing.
How a mobile audit runs
Choose screens and journeys
We agree on up to 12 screens per platform, built around the journeys that matter: sign-in, search, checkout, booking, or a form someone must finish.
Install your build
We test the build you're about to ship, through TestFlight or a Google Play testing track, with test accounts for signed-in areas.
Test on real devices
An analyst works through each screen on physical iPhones and Android phones with VoiceOver or TalkBack, switch access, a hardware keyboard, the largest text sizes, and both orientations.
Write fixes in your language
Each finding names the screen, the success criterion, and the people affected, with a fix in Swift, Kotlin, JavaScript, or Dart, whichever your codebase uses.
Retest the next build
When your team ships fixes, we retest them on the next build and update the findings register.
Title II covers public entities' apps, not just their websites
The Justice Department's Title II rule sets WCAG 2.1 Level AA as the standard for state and local government web content and mobile apps. The compliance date is April 26, 2027 for larger governments, and April 26, 2028 for smaller ones and special district governments. WCAG 2.1 doesn't include the 2.2 target-size criterion, but Apple's and Google's own guidelines already ask for larger targets. See all compliance deadlines.
Priced per platform
Mobile app audit
Starting at
$6,200per platform
Up to 12 screens on iOS or Android, tested with VoiceOver or TalkBack, Switch Access, and large text.
Request a quoteReact Native and Flutter apps are still priced per platform, because VoiceOver and TalkBack expose different bugs in the same shared code. Fixes can follow in remediation sprints.
Questions from app teams
Do you test on simulators or real devices?
Real devices, for the final word. Simulators are useful for quick checks, but screen-reader gestures, focus behavior, and performance on a mid-range Android phone only show up on hardware.
Does WCAG apply to native apps?
WCAG was written for the web, but its success criteria are widely applied to apps, and the W3C publishes guidance on doing so. The Justice Department's Title II rule applies WCAG 2.1 AA to public entities' mobile apps directly. Whether a specific obligation applies to your app is a question for your attorney.
Our app mixes native screens and web views. Can you test both?
Yes. The hand-off between native screens and embedded web content is a common place for focus to get lost, so we test both sides and the transition between them.
What do you need from us to start?
A test build through TestFlight or a Google Play testing track, test accounts, and the journeys that matter most. A short call with one of your developers helps us write fixes that fit your architecture.
Keep reading
Tell us what your website needs to do.
Send a link and a sentence about your deadline. You will hear back from a person within one business day, usually with a short list of questions and a proposed scope.