What Is Mobile Accessibility Testing?
Mobile accessibility testing evaluates the accessibility of websites and mobile applications on smartphones and tablets. As mobile devices become the main way many people access digital content, making sure mobile experiences work with assistive technology is increasingly important.
Testing covers compatibility with mobile screen readers and accessibility settings, touch and gesture interactions, motion, orientation and responsive layouts. The W3C’s mobile accessibility overview explains how existing standards apply to mobile.
Organizations seeking compliance with WCAG and accessibility regulations should include mobile testing as part of their accessibility program.
Mobile Web, Native and Hybrid Apps: Which Rules Apply?
- Mobile websites and web apps are web content, so WCAG 2.2 applies directly.
- Native iOS and Android apps are not web pages, but WCAG is still the benchmark most laws and procurement rules use for them. The W3C’s WCAG2ICT Group Note explains how to interpret WCAG for non-web software, and its draft Guidance on Applying WCAG 2.2 to Mobile Applications (WCAG2Mobile), a Group Draft Note still in development (latest editor’s draft), gives mobile-specific interpretation. Treat WCAG2Mobile as guidance, not a separate standard.
- Hybrid apps (web views inside a native shell) need both: WCAG checks for the web content and native checks for the shell, navigation and system controls.
The earlier W3C note on mobile accessibility mapping is still a useful background read on how WCAG principles map to touch devices.
Key Components of Mobile Accessibility Testing
Screen Reader Compatibility Testing
Accessibility specialists test with VoiceOver on iOS and TalkBack on Android to verify that every element is announced with a clear name, role and state, that the swipe order matches the visual order, and that custom gestures have alternatives. Our screen reader testing guide goes deeper on what to listen for.
Touch Target Accessibility
Buttons, links and controls must be large enough and spaced far enough apart for people with motor impairments or tremors to hit them reliably.
Mobile Gesture Accessibility
Users should be able to use all content without relying only on complex gestures such as pinches, multi-finger swipes, drags or shaking the device.
External Keyboard and Switch Access
Many people pair a Bluetooth keyboard or switch with their phone. Focus order, visible focus and keyboard operability matter on mobile too; see our manual keyboard testing guide.
Mobile WCAG Success Criteria to Test
| Criterion | Level | What to check on mobile |
|---|---|---|
| 2.5.1 Pointer Gestures | A | Pinch, multi-finger and path-based gestures have a single-pointer alternative, such as + and − buttons for a map. |
| 2.5.2 Pointer Cancellation | A | Actions fire on lift, not touch-down, so users can slide off a control to cancel. |
| 2.5.4 Motion Actuation | A | Shake-to-undo or tilt controls have an on-screen alternative and can be turned off. |
| 2.5.7 Dragging Movements | AA | New in WCAG 2.2: sliders, sortable lists and drag-and-drop also work with taps. |
| 2.5.8 Target Size (Minimum) | AA | New in WCAG 2.2: targets are at least 24 by 24 CSS pixels, or have enough spacing, with some exceptions such as inline links. |
| 1.3.4 Orientation | AA | Content works in both portrait and landscape unless one orientation is essential. |
| 1.4.4 Resize Text | AA | Text can be enlarged to 200% (on mobile, test with the system’s largest text settings) without losing content. |
| 1.4.10 Reflow | AA | Web content works at a width of 320 CSS pixels without horizontal scrolling. |
WCAG’s 24-pixel target size is a minimum. Platform guidelines recommend larger targets: Apple suggests at least 44 by 44 points and Google’s Material Design 48 by 48 density-independent pixels. Aim for those in new designs.
How to Run Mobile Accessibility Testing on Real Devices
- Choose devices. At least one current iPhone and one Android phone, plus a tablet if your audience uses them. Simulators help during development but do not replace real hardware.
- Run a quick automated pass. Use Google’s Accessibility Scanner on Android and Xcode’s Accessibility Inspector on iOS (see Android’s accessibility testing guide and Apple’s accessibility documentation). For mobile web, run your usual browser tools too; our automated accessibility testing guide explains what they find.
- Test with VoiceOver. Turn it on in Settings, then Accessibility, then VoiceOver (Apple’s VoiceOver practice guide covers the gestures). Swipe right through every screen, double-tap to activate, use the rotor to move by headings and links, and complete key tasks.
- Test with TalkBack. Turn it on in Settings, then Accessibility, then TalkBack (Google’s TalkBack help lists the gestures). Repeat the same tasks.
- Check touch targets and gestures. Try every control with one finger, look for small or crowded targets, and confirm each gesture, drag and motion feature has a simple alternative.
- Rotate the device and confirm everything works in both orientations.
- Turn on large text and display zoom. Set the largest system text size and check that nothing is cut off, overlaps or needs horizontal scrolling.
- Connect a keyboard and Tab through the key journeys.
- Check other settings such as reduced motion, dark mode, increased contrast and captions for video.
Common Mobile Accessibility Issues
Small Interactive Elements
Touch targets that are too small or too close together are hard to activate accurately: icon buttons in headers, close buttons on banners and carousel dots are frequent offenders.
Accessibility Problems in Responsive Designs
Content may become hidden, truncated or difficult to navigate on smaller screens, and off-canvas menus often remain readable by screen readers when closed.
Orientation Restrictions
Users should not be forced into a specific screen orientation unless it is essential. People with devices mounted on wheelchairs, for example, may not be able to rotate them.
Unlabeled Icons and Images
Icon-only buttons with no accessible name are announced as “button” or by a file name.
Gesture-Only Interactions
Swipe-to-delete, pull-to-refresh and drag-to-reorder with no visible alternative exclude many users.
Text That Does Not Scale
Fixed font sizes ignore the user’s text settings, or larger text breaks the layout.
Mobile Testing vs Automated Scans
Mobile scanners are good at finding missing labels, small targets and low contrast. They cannot tell whether a VoiceOver user can complete a purchase, whether swipe order makes sense or whether a gesture has a usable alternative. Combine a quick automated pass with manual testing on real devices for every release that changes key screens. WebAIM’s overview of mobile accessibility evaluation tools is a useful comparison.
Mobile Accessibility Testing Checklist
- Every element is announced with a clear name, role and state in VoiceOver and TalkBack (see WCAG 4.1.2 Name, Role, Value).
- Swipe order matches the visual order.
- Targets are at least 24 by 24 CSS pixels (ideally 44 points or 48 dp) or well spaced.
- Every multi-finger, path, drag or motion gesture has a simple alternative.
- Actions fire on release, not touch-down.
- Content works in portrait and landscape.
- Largest text size and zoom do not break or hide content.
- Web content reflows at 320 CSS pixels.
- An external keyboard can reach and operate everything.
- Closed menus and dialogs are hidden from screen readers.
For PDFs and documents opened on phones, see our document accessibility testing guide. Mobile accessibility testing helps ensure inclusive experiences across all devices and operating systems.
Work With Us
Want your mobile experience professionally tested? Our WCAG 2.2 accessibility audit covers mobile web and app testing with manual, assistive-technology-based checks.
Get a free accessibility needs assessment — no commitment required.
