Mobile accessibility testing: complete guide for iOS and Android

Over 60% of web traffic now comes from mobile devices, according to Statcounter's 2025 platform data. Yet most accessibility testing still focuses on desktop browsers. Mobile apps and mobile web experiences introduce unique accessibility challenges: touch targets, gesture-based interactions, screen reader behaviors that differ significantly from desktop equivalents, and platform-specific assistive technologies that require dedicated testing.

WCAG 2.2 applies to mobile. The W3C confirmed this in their "Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile" guidance document (updated 2023). WCAG criteria were written to be technology-agnostic, which means every success criterion applies to native iOS apps, native Android apps, and mobile web experiences.

This guide covers the testing tools, common failures, and practical checklists your team needs to test mobile apps against WCAG 2.2 and platform-specific guidelines.

Why mobile accessibility testing requires its own process

Desktop accessibility testing does not translate directly to mobile. Three factors make mobile different:

1. Different assistive technologies Desktop users rely on NVDA, JAWS, and VoiceOver for macOS. Mobile users rely on VoiceOver for iOS and TalkBack for Android. These screen readers use gestures (swipe, double-tap) instead of keyboard shortcuts, and they expose content differently than their desktop counterparts.

2. Touch input replaces keyboard Desktop WCAG testing emphasizes keyboard operability. On mobile, the primary input is touch. WCAG 2.5.1 (Pointer Gestures) and 2.5.2 (Pointer Cancellation) address touch-specific concerns that don't apply to desktop. Switch Control and Switch Access serve users who cannot use touch at all.

3. Platform guidelines extend WCAG Apple's Human Interface Guidelines (HIG) and Android's accessibility guidelines add platform-specific requirements beyond WCAG. For example, Apple requires that all interactive elements support Dynamic Type (text scaling), while Android expects apps to define content descriptions using `android:contentDescription` attributes.

iOS vs Android: accessibility features and testing tools

| Feature | iOS | Android | |---------|-----|---------| | Built-in screen reader | VoiceOver | TalkBack | | Voice input | Voice Control | Voice Access | | Switch navigation | Switch Control | Switch Access | | Text scaling | Dynamic Type (up to 310%) | Font size (up to 200%) + Display size | | Magnification | Zoom (full screen or window) | Magnification (triple-tap or shortcut) | | Color/contrast | Increase Contrast, Color Filters | High contrast text, Color correction | | Reduced motion | Reduce Motion toggle | Remove animations toggle | | Testing tool (automated) | Accessibility Inspector (Xcode) | Accessibility Scanner (Play Store) | | Testing framework | XCUITest accessibility API | Espresso accessibility checks | | Minimum OS for WCAG 2.2 | iOS 15+ (recommended iOS 17+) | Android 11+ (recommended Android 13+) |

Source: Apple Accessibility documentation (developer.apple.com/accessibility), Android Accessibility documentation (developer.android.com/guide/topics/ui/accessibility).

Six most common mobile accessibility failures

Based on accessibility audits conducted by BetterQA across more than 200 mobile applications, these failures appear most frequently:

1. Touch targets too small (WCAG 2.5.8)

WCAG 2.2 introduced Success Criterion 2.5.8 Target Size (Minimum), requiring interactive elements to be at least 24x24 CSS pixels. Apple's HIG recommends a 44x44 point minimum. Android Material Design specifies 48x48 dp.

Common violations: icon-only buttons (share, close, favorite), inline text links in dense content, form radio buttons and checkboxes using default browser styling, navigation tabs in bottom bars.

Fix: Set explicit minimum dimensions on all interactive elements. Use padding to expand the tap area without changing visual size.

2. Screen reader focus order broken in custom views

Native platform controls (UIButton, UITextField on iOS; Button, EditText on Android) get correct focus order automatically. Custom views, overlays, modals, and bottom sheets frequently break the expected reading order.

Common violations: modals that don't trap focus, bottom sheets where focus falls behind the overlay, tab bars where the active tab is not announced as selected, custom carousels that skip items.

Fix: On iOS, set `accessibilityElements` array to define explicit order. On Android, use `android:accessibilityTraversalBefore` and `android:accessibilityTraversalAfter` or `importantForAccessibility`.

3. Gesture-only interactions without alternatives (WCAG 2.5.1)

WCAG 2.5.1 (Pointer Gestures) requires that any function triggered by a multi-point or path-based gesture has a single-pointer alternative. Swipe-to-delete, pinch-to-zoom on maps, and drag-to-reorder are common offenders.

Common violations: swipe-to-delete with no button alternative, pinch-to-zoom without zoom controls, drag-to-reorder lists with no alternative sort mechanism, pull-to-refresh with no refresh button.

Fix: Provide a visible single-tap alternative for every gesture-based action. For swipe-to-delete, add a delete button accessible through a context menu or long-press action.

4. Dynamic content not announced to screen readers

When content updates without a page reload (loading states, error messages, live scores, chat messages), screen readers need explicit notification through accessibility announcements.

Common violations: form validation errors not announced on submission, loading spinners without status announcements, toast notifications invisible to screen readers, real-time content updates (chat, feeds) not announced.

Fix: On iOS, use `UIAccessibility.post(notification: .announcement, argument: message)`. On Android, use `AccessibilityEvent.TYPE_ANNOUNCEMENT` or mark containers with `android:accessibilityLiveRegion="polite"`.

5. External keyboard and switch navigation broken

Users with motor impairments connect Bluetooth keyboards or switch devices to mobile devices. All interactive elements must be reachable and operable through these input methods.

Common violations: custom controls not included in focus chain, focus indicator not visible on mobile, gestures with no keyboard equivalent, dropdown menus that only respond to touch.

Fix: Test with a Bluetooth keyboard connected. Ensure all controls are focusable and respond to Enter/Space activation. Verify that a visible focus indicator appears.

6. Orientation locked unnecessarily (WCAG 1.3.4)

WCAG 1.3.4 (Orientation) requires that content is not restricted to a single display orientation unless a specific orientation is essential for the content. Many apps lock to portrait without justification.

Common violations: apps locked to portrait mode in the manifest or info.plist, horizontal-orientation content that doesn't reflow properly, modal dialogs that break layout when rotated.

Fix: Support both orientations unless the content genuinely requires one (such as a piano app). Test that layouts adapt correctly when the device rotates.

Practical testing checklist by assistive technology

VoiceOver testing (iOS)

Enable VoiceOver: Settings > Accessibility > VoiceOver (or triple-click the side button if configured).

| Test | Pass criteria | WCAG criterion | |------|---------------|----------------| | Swipe through all elements | Every interactive element is reachable | 2.1.1 Keyboard | | Listen to element announcements | Labels are descriptive and accurate | 1.1.1 Non-text Content, 4.1.2 Name/Role/Value | | Double-tap to activate buttons | All buttons respond to VoiceOver activation | 2.1.1 Keyboard | | Navigate headings (rotor) | Heading hierarchy is logical and complete | 1.3.1 Info and Relationships | | Check focus order | Reading order matches visual layout | 1.3.2 Meaningful Sequence | | Dismiss modals/dialogs | Focus returns to trigger element | 2.4.3 Focus Order | | Test with Dynamic Type | Text scales without clipping or overlap | 1.4.4 Resize Text | | Check announcements on updates | Dynamic content changes are announced | 4.1.3 Status Messages |

TalkBack testing (Android)

Enable TalkBack: Settings > Accessibility > TalkBack.

| Test | Pass criteria | WCAG criterion | |------|---------------|----------------| | Swipe through all elements | Every interactive element is reachable | 2.1.1 Keyboard | | Listen to content descriptions | Labels are meaningful, not "Button 1" | 1.1.1, 4.1.2 | | Double-tap to activate | All interactive elements respond | 2.1.1 | | Navigate by headings | Headings announced with correct level | 1.3.1 | | Check reading order | Logical order top-to-bottom, left-to-right | 1.3.2 | | Test live regions | Toast messages and errors are announced | 4.1.3 | | Increase font size to max | Content remains readable, no truncation | 1.4.4 | | Test with Switch Access | All elements reachable via scanning | 2.1.1 |

External keyboard testing (both platforms)

| Test | Pass criteria | WCAG criterion | |------|---------------|----------------| | Tab through all controls | Complete navigation via Tab key | 2.1.1 | | Activate with Enter/Space | Buttons and links respond | 2.1.1 | | Visible focus indicator | Focus ring visible on every focused element | 2.4.7 Focus Visible | | No keyboard traps | Can always Tab away from any element | 2.1.2 No Keyboard Trap | | Shortcut keys documented | Custom shortcuts are discoverable | 2.1.4 Character Key Shortcuts |

Mobile web vs native app testing differences

Testing mobile web and native apps against WCAG 2.2 shares principles, but the implementation differs significantly:

| Aspect | Mobile web | Native app | |--------|-----------|------------| | Standards | WCAG 2.2 + WAI-ARIA | WCAG 2.2 + platform guidelines (HIG/Material) | | Screen reader API | HTML semantics + ARIA roles | UIAccessibility (iOS) / AccessibilityNodeInfo (Android) | | Automated testing | axe, WAVE, Lighthouse (same as desktop) | Accessibility Scanner (Android), Accessibility Inspector (Xcode) | | Focus management | DOM focus via tabindex, JavaScript | Native focus APIs, accessibility element ordering | | Text scaling | CSS relative units (rem, em, %) | Dynamic Type (iOS), sp units (Android) | | Testing browsers | Safari (iOS), Chrome (Android) | Platform-native tooling | | VPAT scope | Website as a whole | Per-app version and platform |

For mobile web, you can reuse many desktop testing tools. For native apps, you need platform-specific tools and real device testing. Emulators and simulators miss certain accessibility behaviors, particularly around haptic feedback, device motion, and certain gesture interactions.

Automated testing tools for mobile

Android Accessibility Scanner (free, Google Play Store): scans screens for touch target sizes, content labels, contrast ratios, and item descriptions. Produces a report with specific fix suggestions. Does not test screen reader interactions or focus order.

Xcode Accessibility Inspector (free, included with Xcode): inspects accessibility properties of iOS UI elements in real time. Shows the accessibility label, traits, value, and hint for any element. Run accessibility audits on individual screens to detect common issues.

Espresso accessibility checks (Android testing framework): integrates accessibility checking into UI tests. Add `AccessibilityChecks.enable()` to your test setup, and Espresso verifies touch target size, content labeling, and contrast during test execution. Google's open-source Accessibility Test Framework powers these checks.

XCUITest accessibility API (iOS testing framework): query accessibility elements programmatically. Verify that elements have appropriate labels, traits (button, header, image), and values. Combine with snapshot testing to detect accessibility regressions.

Deque axe for mobile: Deque offers axe DevTools Mobile for automated accessibility scanning of native iOS and Android applications. It checks against WCAG criteria adapted for mobile contexts.

No automated tool catches all mobile accessibility issues. The WebAIM Million report (2025) found that automated tools detect roughly 30-40% of WCAG violations on web pages. For mobile native apps, the detection rate is comparable or lower because platform-specific issues require manual testing with actual assistive technologies.

How Auditi supports mobile accessibility testing

Auditi structures accessibility testing as user journeys, which maps directly to mobile testing needs:

Journey-based mobile testing: define mobile user flows as journeys (onboarding, core feature, checkout). Each step in the journey maps to a screen state. Test each state against WCAG 2.2 criteria, with specific focus on mobile-relevant criteria like 2.5.1 (Pointer Gestures), 2.5.8 (Target Size), and 1.3.4 (Orientation).

Multi-version tracking: mobile apps ship versions frequently. Auditi tracks accessibility results across versions, so you can detect regressions when a new build breaks previously passing criteria.

VPAT generation for mobile apps: procurement teams and enterprise buyers increasingly request VPATs for mobile applications. Auditi generates VPAT 2.4 reports from your mobile journey test results, documenting conformance per WCAG criterion.

Import automated results: feed results from Accessibility Scanner, axe, or custom Espresso tests into Auditi through its API, combining automated scans with manual screen reader testing in a unified compliance view.

Multi-standard support: test against WCAG 2.1, WCAG 2.2, FDA 21 CFR Part 11 (for health apps), and EU accessibility directive requirements in a single audit.

Auditi is built by BetterQA, a software testing company that has conducted accessibility assessments for mobile apps across healthcare, fintech, and government sectors.

Frequently asked questions

Does WCAG 2.2 apply to native mobile apps? Yes. The W3C published "Mobile Accessibility: How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile" confirming that WCAG criteria are technology-agnostic. WCAG 2.2, adopted as a W3C Recommendation in October 2023, applies equally to websites, web applications, native mobile apps, and hybrid apps. The European Accessibility Act (EAA), which takes effect June 2025, explicitly includes mobile applications.

What is the minimum touch target size required by WCAG 2.2? WCAG 2.2 Success Criterion 2.5.8 (Target Size - Minimum, Level AA) requires that interactive targets are at least 24x24 CSS pixels, with exceptions for inline text links, targets where the spacing ensures adequate area, and targets whose size is determined by the user agent. Apple recommends 44x44 points, and Android Material Design recommends 48x48 dp. Meeting the platform guidelines automatically satisfies the WCAG minimum.

How do I test VoiceOver on iOS without a physical device? The iOS Simulator included with Xcode supports Accessibility Inspector but does not run VoiceOver. For accurate VoiceOver testing, you need a physical iOS device. This is because VoiceOver relies on touch gestures (swipe, double-tap, scrub) that a mouse click cannot replicate. Budget for at least one physical test device per major iOS version you support.

Should I test on emulators or real devices? Test on real devices whenever possible. The Android Emulator supports TalkBack through the Accessibility Suite APK, but its behavior can differ from physical hardware. Certain accessibility features (haptic feedback, biometric interactions, gesture responsiveness at full speed) only behave correctly on physical devices. Use emulators for early development checks and real devices for final validation.

What is the difference between mobile web and native app accessibility testing? Mobile web accessibility uses HTML semantics, ARIA roles, and CSS for accessibility. Native app accessibility uses platform APIs: UIAccessibility on iOS and AccessibilityNodeInfo on Android. Testing tools differ as well. Mobile web can use axe, WAVE, and Lighthouse through a mobile browser. Native apps require Xcode Accessibility Inspector (iOS), Accessibility Scanner (Android), or framework-level checks like Espresso accessibility tests. Both need manual screen reader testing on real devices.

How often should I run mobile accessibility tests? Run automated checks on every build through CI integration (Espresso accessibility checks, XCUITest). Conduct manual screen reader testing before each release. Perform a full WCAG 2.2 audit quarterly or after major UI changes. Track results over time to detect regressions early. Auditi supports version comparison so you can see exactly which criteria changed between releases.

Getting started with mobile accessibility testing

Start with your most critical mobile user flow. Define 3-5 steps that represent the core experience (login, main feature, key conversion point). Test that single journey with VoiceOver and TalkBack on real devices. Document the results.

This one journey will reveal your biggest mobile accessibility gaps. Fix those first, then expand your test coverage to additional flows.

For teams that need structured mobile accessibility testing across releases, Auditi provides the journey framework, multi-platform tracking, and compliance documentation to make mobile accessibility systematic rather than ad hoc.

© 2026 Auditi. A BetterQA project. | auditi.ro