# Mobile App Accessibility Testing: iOS and Android Checklist

> Updated 2026-10-25 - 9 min read

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.

## FAQ

**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.