Mobile app accessibility is frequently overlooked because developers assume WCAG only applies to the web. It does not. WCAG 2.1 explicitly includes mobile applications in its scope. Section 508 covers mobile apps. The European Accessibility Act covers mobile apps. And ADA Title III applies to apps that are integral to a place of public accommodation — which includes most consumer-facing apps. If you have a mobile app, you have accessibility requirements.
How WCAG maps to mobile
Perceivable on mobile
All touch-only UI elements need accessible labels (UIAccessibilityLabel on iOS, contentDescription on Android). Images need alternative text. Video content needs captions. Text must meet contrast requirements — the 4.5:1 ratio applies regardless of platform. Dynamic type / font scaling must be supported without content clipping or loss of functionality.
Operable on mobile
Touch targets must be at least 44x44 points on iOS and 48x48dp on Android. All interactions must be achievable without requiring specific gestures (swiping, multi-finger gestures must have alternatives). Switch Access (Android) and Switch Control (iOS) must work for all interactive elements. Session timeout warnings must be dismissible via switch or voice control.
Understandable on mobile
Form fields must have accessible labels that are announced when the field receives focus. Error messages must be programmatically associated with their input. Navigation must be consistent across screens. Custom gestures (shake-to-undo, long-press context menus) need discoverable alternatives.
Robust on mobile
Native components (UIButton, UITextField on iOS; Button, EditText on Android) have built-in accessibility support. Custom components built from View/UIView require manual accessibility implementation. Always prefer platform native components — they inherit decades of assistive technology compatibility that custom implementations must rebuild from scratch.
Testing mobile accessibility: tools and process
- VoiceOver (iOS): Enable in Settings > Accessibility > VoiceOver. Navigate your entire app by swipe. Every element must have an accessible label; every interactive element must respond to double-tap.
- TalkBack (Android): Enable in Settings > Accessibility > TalkBack. Test with a physical Android device — emulators do not fully simulate TalkBack behavior.
- Accessibility Inspector (Xcode): Audit mode scans for common iOS accessibility issues without requiring a device.
- Android Accessibility Scanner: Google's scanning app highlights missing labels, small touch targets, and contrast failures.
- Switch Control / Switch Access: Test with a single switch to verify all interactive elements are reachable in focus order.
- Keyboard testing: Connect a Bluetooth keyboard to both iOS and Android and verify all interactive elements are reachable via Tab/arrow keys.
The 5 most common mobile accessibility failures
- Interactive elements without accessible labels — icon buttons (back, close, share) with no contentDescription or accessibilityLabel
- Custom components built from View that don't expose role or state — e.g., a custom toggle switch that VoiceOver announces as 'button' and never announces its on/off state
- Touch targets below 44x44pt (iOS) or 48x48dp (Android) — especially in dense list rows and navigation bars
- Dynamic content updates not announced to screen readers — counters, loading states, success messages that appear visually but are invisible to VoiceOver/TalkBack
- No alternative to complex gestures — swipe-to-dismiss, pinch-to-zoom, long-press menus with no keyboard or single-tap equivalent
React Native, Flutter, and cross-platform considerations
Cross-platform frameworks introduce additional complexity. React Native components map to native components (good), but custom native modules and third-party libraries often do not expose accessibility properties. Flutter has its own accessibility semantic layer that maps to platform ATs — it works well when used correctly but requires explicit Semantics widget configuration for custom UI. Always test on real devices with real screen readers, regardless of framework. Simulator-based testing will miss critical TalkBack and VoiceOver behaviors.
Marcus Thompson
Accessibility Engineer
A certified accessibility consultant at BuildWithAccess helping organizations achieve WCAG compliance and build more inclusive digital experiences.
Need help making your site accessible?
We offer free consultations to assess your current accessibility posture and recommend a path forward.
Get a Free Consultation