Why Accessibility Testing Matters
Over 1.3 billion people globally live with some form of disability. In the mobile context, this includes visual impairments (blindness, low vision, color blindness), motor impairments (limited dexterity, tremors), hearing impairments, and cognitive disabilities.
Beyond the moral imperative, accessibility is increasingly a legal requirement. The Americans with Disabilities Act (ADA) in the US, the European Accessibility Act (effective June 2025), and similar laws in other jurisdictions mandate that digital products be accessible. Lawsuits targeting inaccessible mobile apps have grown significantly since 2023.
Apple and Google also factor accessibility into their app review and featuring decisions. Apps with strong VoiceOver and TalkBack support are more likely to be featured in editorial collections.
Core Accessibility Standards
WCAG 2.2 (Web Content Accessibility Guidelines)
While originally created for web content, WCAG 2.2 is the accepted standard for mobile app accessibility. The key principles follow the POUR framework:
Perceivable - Users must be able to perceive all content and UI elements through at least one sense.
Operable - Users must be able to interact with all controls and navigation using their preferred input method.
Understandable - Content and operations must be clear and predictable.
Robust - Content must work with current and future assistive technologies.
WCAG defines three conformance levels:
- Level A - Minimum accessibility (baseline requirement)
- Level AA - Recommended standard (target this level)
- Level AAA - Enhanced accessibility (aspirational)
Testing with Screen Readers
VoiceOver (iOS)
VoiceOver is Apple's built-in screen reader. Enable it in Settings > Accessibility > VoiceOver or ask Siri.
How to test:
- Turn on VoiceOver
- Navigate through your app by swiping right (next element) and left (previous element)
- Double-tap to activate the focused element
- Listen to what VoiceOver announces for each element
What to check:
- Does every interactive element have a meaningful label?
- Are images described with accessibility labels (or marked as decorative)?
- Is the reading order logical (not jumping randomly across the screen)?
- Can you complete every critical flow using only VoiceOver gestures?
- Are state changes announced (loading states, errors, success messages)?
TalkBack (Android)
TalkBack is Android's screen reader. Enable it in Settings > Accessibility > TalkBack.
How to test:
- Turn on TalkBack
- Swipe right to move to the next element, left for previous
- Double-tap to activate
- Use the reading control (swipe up then right) to change navigation granularity
What to check:
- Same checklist as VoiceOver
- Additionally: test with BrailleBack if targeting blind users
- Verify custom views expose correct semantics through AccessibilityNodeInfo
Common Accessibility Failures
1. Missing Labels
The most frequent failure. A button shows an icon but has no accessibility label. VoiceOver reads "button" and TalkBack reads "unlabeled." The user has no idea what it does.
Fix: Add accessibilityLabel (iOS) or contentDescription (Android) to every interactive element. For image buttons, describe the action: "Send message" not "Arrow icon."
2. Insufficient Color Contrast
Text that is too low-contrast against its background is unreadable for users with low vision and difficult for everyone in bright sunlight.
WCAG AA requirements:
- Normal text (below 18pt): contrast ratio of at least 4.5:1
- Large text (18pt+ or 14pt+ bold): contrast ratio of at least 3:1
- UI components and graphical objects: at least 3:1
Tools: Use the Colour Contrast Analyser (desktop app), Stark (Figma plugin), or the Accessibility Inspector in Xcode.
3. Touch Targets Too Small
Users with motor impairments need adequately sized touch targets. Both Apple and Google specify minimum sizes:
- Apple HIG: 44x44 points minimum
- Material Design: 48x48 dp minimum
- WCAG 2.2 (Level AA): 24x24 CSS pixels minimum target size
Fix: Even if the visual element is smaller, extend the tappable area using padding, contentEdgeInsets (iOS), or TouchDelegate (Android).
4. No Keyboard/Switch Support
Users with motor impairments often use external keyboards, switch devices, or voice control instead of the touchscreen.
Test: Connect a Bluetooth keyboard to your device. Can you navigate and operate every feature using Tab, arrow keys, and Enter?
5. Motion and Animation Issues
Vestibular disorders make parallax effects, auto-playing animations, and screen transitions nauseating for some users.
Fix: Respect the system "Reduce Motion" preference (UIAccessibility.isReduceMotionEnabled on iOS, Settings.Global.ANIMATOR_DURATION_SCALE on Android). Replace animations with simple fades or remove them entirely.
6. Missing Live Region Announcements
When content changes dynamically (a new message arrives, a counter updates, an error appears), screen reader users may not notice unless you announce the change.
Fix: Use UIAccessibility.post(notification:) on iOS or ViewCompat.setAccessibilityLiveRegion() on Android to announce dynamic content changes.
Automated Accessibility Testing
Accessibility Scanner (Android)
Google's free tool that scans your app screens and identifies issues: missing labels, small touch targets, low contrast. Available as a standalone app on the Play Store.
Accessibility Inspector (iOS)
Built into Xcode. Run an audit on any screen to get a list of elements with missing labels, poor contrast, or incorrect traits.
axe DevTools Mobile
Automated accessibility testing SDK that integrates into your test suite. Runs programmatic audits and generates reports during E2E tests.
Accessibility Snapshot Testing
For iOS, the SnapshotTesting library supports accessibility snapshots that capture the VoiceOver representation of your UI. Changes to accessibility labels, traits, or hierarchy appear as test failures, catching regressions automatically.
Building an Accessibility Testing Routine
Every sprint:
- Run automated scanners on new and modified screens
- Test critical flows with VoiceOver/TalkBack
- Verify color contrast for new design elements
Every release:
- Complete VoiceOver/TalkBack walkthrough of all core flows
- Keyboard navigation test
- Dynamic text size test (increase to the largest system size)
- High contrast mode verification
- Reduced motion mode verification
Quarterly:
- Full WCAG AA audit
- Usability testing with actual assistive technology users
- Review and update accessibility documentation
Dynamic Type and Text Scaling
Both iOS and Android allow users to increase system font size. Your app must handle this gracefully.
iOS Dynamic Type: Support the system text styles (body, headline, callout, etc.) and test at the largest accessibility size. Views should scroll or reflow, not clip or overlap.
Android Font Scale: Test with font scale set to the maximum (200%). Use sp units for text sizes and ensure layouts accommodate larger text.
Apps that break at large text sizes fail a basic accessibility requirement and lose users who depend on larger fonts to read content.