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 Screen Reader Use In 2026 At A Glance
- 91.8%: Of survey respondents use a screen reader on a phone or tablet (Source: WebAIM Screen Reader Survey #11 (2026) (opens in a new tab))
- 72.2%: Commonly use VoiceOver on mobile, and 29.5% use TalkBack, so test both (Source: WebAIM Screen Reader Survey #11 (2026) (opens in a new tab))
- 54.8%: Would rather use a mobile app than the website for tasks like banking or shopping (Source: WebAIM Screen Reader Survey #11 (2026) (opens in a new tab))
- 24 px: Minimum touch target in CSS pixels (or enough spacing) under WCAG 2.2 Level AA (Source: W3C, WCAG 2.2 SC 2.5.8 (opens in a new tab))
Choose Your Next Step
Want a quick first look at a mobile web page? Run a free scan on AccessibilityScore.in (opens in a new tab); it is a starting point that complements manual testing on real devices, not a replacement. For a full manual WCAG 2.2 AA audit of up to 25 templates or key user flows, see the $2,000 Complete Audit on our pricing page or our accessibility audit services.
Free 30-Minute Call
Best for: first conversations, scoping and quotes
Tell us whether you need your mobile website, an iOS or Android app, or a hybrid app tested, and which journeys matter most. We suggest the devices and screen readers to cover and send a quote. No technical prep needed.
Book a free 30-minute call (opens in a new tab)
$500 Quick Audit
Best for: mobile websites and small sites that want a first check
Up to 5 page templates with automated scans plus manual keyboard and screen reader spot checks, a top-10 issues report mapped to WCAG 2.2 and a 30-minute review call.
$100 Technical Consultation
Best for: developers stuck on a VoiceOver or TalkBack bug, or on audit findings
A one-hour working session to walk through findings, talk with your developer, or review focus, labels and gestures live on a device.
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
These are the problems we find most often on phones and tablets, with the fix and the WCAG success criterion each one maps to.
| Issue | What users run into | How to fix it |
|---|---|---|
| Small interactive elements WCAG 2.5.8 |
Icon buttons in headers, banner close buttons and carousel dots are too small or too close together to hit reliably, especially for people with tremors. | Make targets at least 24 by 24 CSS pixels or space them out; aim for 44 points (Apple) or 48 dp (Android). |
| Responsive layout problems WCAG 1.4.10, 2.4.3 |
Content is hidden or cut off on small screens, and closed off-canvas menus can still be reached by a screen reader. | Let content reflow at 320 CSS pixels, and hide closed menus from assistive technology (for example with hidden or inert). |
| Orientation locked WCAG 1.3.4 |
People with a phone mounted on a wheelchair may not be able to rotate it. | Support portrait and landscape unless one orientation is essential. |
| Unlabeled icons and images WCAG 1.1.1, 4.1.2 |
Icon-only buttons are announced as “button” or by a file name. | Give every icon button an accessible name and every meaningful image a text alternative. |
| Gesture-only interactions WCAG 2.5.1, 2.5.7 |
Swipe-to-delete, pinch and drag-to-reorder with no visible alternative shut out many users. | Add a single-tap alternative, such as a delete button or up and down controls. |
| Text that does not scale WCAG 1.4.4 |
Fixed font sizes ignore the user’s text settings, or larger text breaks the layout. | Use relative units and test at the largest system text size. |
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 tested by hand? Founder Mohammad Shadab Saifi (CPACC, WAS, CPWA, DHS Trusted Tester, 10+ years) leads our WCAG 2.2 accessibility audits, which cover mobile web and app testing with VoiceOver, TalkBack and an external keyboard on real devices. See what you receive in our sample audit report.
New to this? Book a free 30-minute call to talk through where you stand and get a quote, or get a free accessibility needs assessment with no commitment. If your developer needs hands-on technical answers now, book the $100 one-hour technical consultation.
