VPAT for mobile apps
Native iOS and Android applications, and why web testing tools do not transfer.
A native mobile app is evaluated against the same WCAG success criteria as a website, but almost nothing about how you test it carries over. The tooling is different, the platform APIs are different, and browser-based scanners cannot see your app at all.
Which standard applies
WCAG 2.1 and 2.2 apply to mobile applications: the W3C intends the criteria to be technology-neutral, and both Section 508 and EN 301 549 incorporate them for software user interfaces. Some criteria read oddly against a native app and a few are commonly marked not applicable, but the list you answer is the same list.
Two criteria matter more on mobile than anywhere else, and both were added in WCAG 2.1 largely because of it: 1.3.4 Orientation (the app must work in both portrait and landscape unless orientation is essential) and 1.4.10 Reflow. Add 2.5.1 Pointer Gestures and 2.5.7 Dragging Movements, which are where gesture-driven interfaces usually fail.
How to test it
- iOS — VoiceOver for screen reader behaviour, Dynamic Type at the largest setting, and Xcode's Accessibility Inspector for audit passes and element properties.
- Android — TalkBack, the Accessibility Scanner app, and Espresso's accessibility checks if you have instrumented tests already.
- Both — external keyboard navigation, which people forget mobile supports and which surfaces focus-order problems quickly.
Test on a real device. Simulators misreport touch target sizes and gesture handling, which are exactly the criteria most likely to fail.
Hybrid and web views
If your app is React Native, Flutter, or a wrapper around web views, you are testing both: the web content inside the view against WCAG as usual, and the native shell against the platform's accessibility API. A web view that is accessible in a browser can still be unreachable inside an app that has not exposed it correctly.
Our service does not cover native apps. We scan web-delivered interfaces. There is no honest way to run that process against an iOS or Android binary, so we do not sell it — for a native app you want a tester with the devices in hand. If your product also has a web application or an admin console, that part we can draft, and it is often the part the buyer is asking about.
If you need one anyway
Scope it explicitly: name the app, the version, the OS versions you tested on, and the assistive technologies you used. Mobile ACRs that do not name an OS version age badly, because a platform update can change screen reader behaviour underneath you.
The worksheet lists every Level A and AA criterion with the question to answer, and applies to a mobile evaluation as readily as a web one — only the tools change.