Accessibility Compliance
Mobile App Accessibility Testing: iOS and Android Checklist
Mobile accessibility testing isn't web testing with a smaller screen - it's a genuinely different discipline, with platform-specific assistive technology, gesture conventions and failure patterns that a web-focused audit will miss entirely. This checklist covers what an actual iOS and Android accessibility test needs to include.
iOS: testing with VoiceOver
- Every interactive element has an accessible name, not just visible text - check custom icons and image buttons specifically.
- Swipe-based VoiceOver navigation reaches every interactive element in a logical order.
- Custom gestures (swipe-to-delete, pull-to-refresh) have an accessible alternative, since VoiceOver intercepts standard swipe gestures for its own navigation.
- Dynamic Type (iOS text-size scaling) doesn't break layout or truncate content.
- Focus moves logically after an action - a saved item, a dismissed modal, a completed form.
Android: testing with TalkBack
- Content descriptions are present and meaningful on all interactive views, especially custom components and icon-only buttons.
- TalkBack's explore-by-touch and linear navigation both reach every interactive element.
- Touch target sizes meet Android's accessibility guidance, not just Material Design's default visual sizing.
- Live regions for dynamic content updates announce changes without interrupting the user mid-task.
- Font scaling (Android's system text size) doesn't clip or overlap content.
Patterns that fail on both platforms
- Custom components built from generic views with no semantic role, common in cross-platform frameworks (React Native, Flutter) when accessibility props are skipped.
- Color-only state indicators - a red border with no text or icon to indicate an error.
- Video or audio content with no captions or transcript.
- Forms with no programmatic error association, so a screen-reader user doesn't know which field failed validation or why.
Native vs cross-platform: what changes
React Native and Flutter can produce fully accessible apps, but accessibility isn't automatic - each framework requires explicitly setting accessibility props (accessibilityLabel, Semantics widgets) that have no effect if skipped, unlike native UIKit/Android View components, which have more accessible defaults out of the box.
Need help with this in practice?
A5 Cyber Nexus audits, remediates and certifies against these frameworks.
Frequently asked questions
Can we test mobile accessibility with just automated tools?
No - automated mobile accessibility scanners exist but cover a narrower set of checks than web automated tools, and gesture-based navigation and custom-component issues are almost entirely a manual-testing problem.
Do we need to test on real devices, or is a simulator enough?
Real devices are strongly preferred - VoiceOver and TalkBack gesture behavior, haptics and some screen-reader quirks don't fully replicate in a simulator.
Make it accessible.
Make it attack-ready.
Prove both before launch.
Bring us your app, audit deadline, or security concern. We'll map the fastest path to WCAG conformance, VAPT coverage, and regulator-ready evidence.
