EZUD Accessible Mobile App Design: iOS and Android
Accessible Mobile App Design: iOS and Android
Mobile apps face every accessibility challenge web products do, plus platform-specific constraints: gestures replace keyboard shortcuts, screen real estate is limited, and assistive technology (VoiceOver on iOS, TalkBack on Android) interacts with native UI frameworks differently than with web content. Building accessible mobile apps requires understanding both WCAG principles and platform-specific accessibility APIs.
Platform Accessibility Frameworks
iOS (VoiceOver)
VoiceOver is Apple’s built-in screen reader. It uses swipe gestures for navigation and a rotor control for switching between navigation modes (headings, links, form controls).
Key iOS accessibility APIs:
accessibilityLabel: The text VoiceOver reads for the element. Every interactive element needs one.accessibilityHint: Additional context describing the result of an action (“Double-tap to add to cart”).accessibilityTraits: Defines the element’s role (button, link, header, adjustable). Maps to ARIA roles conceptually.accessibilityValue: The current value for adjustable controls (sliders, steppers).isAccessibilityElement: Whether VoiceOver should recognize the element. Container views should befalse; their children should betrue.
Android (TalkBack)
TalkBack is Android’s primary screen reader. It uses swipe gestures and explore-by-touch for navigation.
Key Android accessibility APIs:
contentDescription: The text TalkBack reads. Equivalent to iOSaccessibilityLabel.importantForAccessibility: Controls whether the view is visible to TalkBack.AccessibilityNodeInfo: Programmatic access to an element’s role, state, and actions.ViewCompat.setAccessibilityDelegate(): Custom accessibility behavior for complex views.- Live regions:
ViewCompat.setAccessibilityLiveRegion()for dynamic content announcements, equivalent toaria-liveon the web.
Cross-Platform Accessibility Principles
1. Label Every Interactive Element
The most common mobile accessibility failure: buttons, icons, and controls with no accessible label. An icon-only trash button without a content description is announced as “button” by both VoiceOver and TalkBack — useless.
Every interactive element needs:
- A label describing what it is or does.
- A role (button, link, checkbox, slider) provided by native UI components or explicitly set.
- A state (selected, expanded, disabled) that updates dynamically.
2. Touch Target Sizing
Both platforms recommend minimum touch targets well above WCAG’s 24px:
- iOS: 44x44 points minimum.
- Android (Material Design): 48x48 dp minimum.
Apply the same principles as our touch target sizing guide: pad small icons to expand the interactive area and space adjacent targets apart.
3. Gesture Alternatives
Mobile interactions rely on gestures that may be impossible for users with motor impairments:
| Gesture | Accessibility Concern | Alternative Needed |
|---|---|---|
| Swipe to delete | Requires precise directional swipe | Edit mode with delete button |
| Pinch to zoom | Requires two fingers | Zoom buttons or double-tap |
| Long press | Requires sustained contact | Menu button or action sheet |
| Custom gestures | Not discoverable, not universal | Standard UI controls |
| Drag to reorder | Requires sustained contact + movement | Move up/move down buttons |
WCAG 2.2 SC 2.5.1 (Pointer Gestures, Level A) requires that any function using multipoint or path-based gestures can be operated with a single pointer without a path-based gesture. SC 2.5.7 (Dragging Movements, Level AA) requires alternatives to drag operations. See our accessible drag and drop guide.
4. Dynamic Content Announcements
When content updates without navigation (a toast notification, a counter incrementing, a loading state resolving), assistive technology must be informed:
- iOS: Use
UIAccessibility.post(notification: .announcement, argument: "Item added to cart"). - Android: Use
announceForAccessibility("Item added to cart")or set a live region on the updating view.
5. Navigation and Focus Order
Both VoiceOver and TalkBack traverse the screen in a logical order (top-left to bottom-right for LTR, reversed for RTL). Custom layouts must ensure this order matches the intended reading order.
- Group related elements into accessibility containers so the screen reader treats them as a unit.
- When a modal or bottom sheet appears, trap focus within it.
- When the modal dismisses, return focus to the trigger element. Same principles as web focus management.
6. Text and Typography
- Respect the system font size preference (
Dynamic Typeon iOS, font scale on Android). Hard-coded font sizes ignore user preferences. - Apply the same typography principles as web: 16pt minimum body text, sufficient line height, adequate contrast.
- Avoid text truncation without providing access to the full content.
Testing Mobile Accessibility
| Test | iOS | Android |
|---|---|---|
| Screen reader navigation | VoiceOver (triple-click home/side button) | TalkBack (Settings > Accessibility) |
| Keyboard navigation | Connect Bluetooth keyboard | Connect Bluetooth keyboard |
| Switch control | Switch Control (Settings > Accessibility) | Switch Access (Settings > Accessibility) |
| Display settings | Bold Text, Larger Text, Increase Contrast, Reduce Motion | Font size, Display size, High contrast text |
| Automated audit | Xcode Accessibility Inspector | Android Studio Accessibility Scanner |
Test with at least one screen reader on each target platform. Use the platform’s accessibility inspector during development.
Key Takeaways
- Every interactive element needs an accessible label, role, and state on both iOS and Android.
- Touch targets: 44x44 points (iOS) or 48x48 dp (Android) minimum.
- Provide alternatives for all custom gestures — swipe, pinch, long press, and drag.
- Announce dynamic content updates using platform-specific live region APIs.
- Respect system font size preferences; never hard-code text sizes.
Next Steps
- Apply touch target sizing guidelines to your mobile design system.
- Ensure gesture alternatives exist for all drag and custom gesture interactions.
- Review the universal design framework for the principles underpinning mobile accessibility.
Sources
- WCAG 2.2 SC 2.5.1 Pointer Gestures — The requirement for single-pointer alternatives to multipoint gestures.
- W3C WAI: Mobile Accessibility — How WCAG applies to mobile applications.
- WebAIM: Mobile Accessibility Testing — Practical guide to testing mobile app accessibility.
- Deque University: Mobile Accessibility — Mobile accessibility checklist for iOS and Android.
iOS accessibility guidance from Apple’s Human Interface Guidelines and VoiceOver documentation. Android accessibility guidance from Material Design 3 and Android Accessibility developer documentation. WCAG requirements from Success Criteria 2.5.1 and 2.5.7.