Why Mobile Accessibility Keeps Failing Users
Mobile accessibility is often described as harder than web accessibility, but the real problem is usually a lack of direction. Teams don't know where to start, what guidance applies, or how to avoid mobile-specific barriers. A recent survey of assistive technology users offers a useful starting point—and a stark reminder of what's at stake.
Half of assistive technology users said that accessibility barriers have a significant impact on their day-to-day well-being.
Accessibility work is not just about compliance. It directly affects quality of life.
The Assistive Tech Landscape On Mobile
Assistive technology on mobile devices generally falls into three groups:
- Screen readers: software that converts on-screen information to speech or braille.
- Screen magnifiers: software or system settings that magnify, adjust contrast, or modify content for better visibility.
- Alternative navigation: software and/or hardware that replaces a touchscreen or keyboard as the primary input.
According to the survey, 81% of assistive technology users change accessibility settings on their smartphone or tablet. Common adjustments include increasing font size, enabling captions, extending tap duration, and inverting colours. Even settings not officially labelled as accessibility features, such as dark mode, provide meaningful benefits.
Screen Reader Users: Connected And Selective
iPhone and Android both ship with built-in screen readers—VoiceOver and TalkBack, respectively. Users can explore by touch or swipe linearly through on-screen elements, and both support navigation by headings or other element types.
Screen reader users often rely on multiple devices to cover their accessibility needs. Nearly half own a smartwatch, half use an external keyboard with their phone, and a third use a braille display. Crucially, almost all of them factor app and site accessibility into their purchasing decisions. Accessibility is a genuine driver of brand loyalty.
Screen Magnification Users: More Tablet Owners, Fewer Pre-Purchase Checks
Android offers various vision-related features for adjusting screen colours and text size. The iPhone Magnifier app applies colour filters, adjusts brightness or contrast, and can detect people or doors nearby.
Screen magnification users had the highest tablet ownership among all groups, with 77% owning both a smartphone and a tablet. Alternative navigation users followed at 62%, while only 42% of screen reader users owned a tablet.
Notably, just 63% of screen magnification users investigate accessibility before buying a paid app, compared with 89% of screen reader users and 91% of alternative navigation users. This may reflect that device-level magnification, contrast, and colour inversion settings can compensate for some inaccessible designs.
Alternative Navigation Users: Switches And Voice
Switch Access on Android and Switch Control on iOS let users interact via one or more switches instead of the touchscreen. Switches can be external devices, keyboards, sounds, or even the smartphone's camera or buttons.
Two scanning methods are available. Item scan highlights elements one by one, and the user confirms selection with the switch. Point and scan starts with a horizontal line moving down the screen; the user stops it with the switch, then stops a vertical line similarly to isolate an element in the cross hairs. Users can also map custom gestures, such as swiping, to buttons.
Voice Access and Voice Control enable hands-free interaction through spoken commands. "Say names" reveals hidden labels, "Show numbers" allows commands like "tap two," and "Show grid" overlays a grid for targeting specific elements—typically a last resort.
Only 26% of alternative navigation users own a smartwatch, the lowest of the three groups. However, nearly all who do use it for health tracking. Currently, 24% use an external switch device with their phone.
The Barriers That Matter Most
Survey respondents were asked to select up to three of their most challenging mobile accessibility barriers. The results highlight recurring problems:
Unlabelled Buttons Or Links
This is the top issue reported by assistive technology users. It disproportionately affects screen reader users, but voice command users are also heavily impacted when no accessible name exists to target.
Small Buttons Or Links
Targets that are too small to tap accurately, or require precise switch control, are a major obstacle for people with mobility issues. Users with low vision also struggle to see them.
Complex Gestures
Swipe-to-delete, tap-and-drag, and other multi-step gestures are hard to discover and can be unusable for many people. A simple button that performs the same action is the safest approach. Custom actions in screen readers can help, but they only reach assistive technology users, not people with, for example, cognitive disabilities who may not use such tools.
Elements Blocking The Screen
Persistent chat buttons, sticky headers, or footers can cover content—especially when a user magnifies the screen. These overlays can make content impossible to read.
Missing Error Messages
Disabling a submit button until a form is correct avoids providing error messages but creates a barrier for assistive technology users, people with cognitive disabilities, and others. Even when error messages exist, they are sometimes not announced to screen reader users.
Ignored Text Resizing And Pinch Zoom
Apps that don't respect system font size settings force users to find workarounds. Websites that disable pinch and zoom also remove a feature that's essential for reading text and inspecting images more closely.
Other Significant Issues
Several other barriers, while less frequently selected, remain substantial challenges:
- Low contrast makes reading difficult for people with low vision; custom contrast settings can help a broader audience.
- No dark mode can cause eye strain or trigger migraines for some users.
- Fixed orientation prevents users with devices mounted on wheelchairs from rotating them, and blocks landscape mode that some people need to make text and images larger.
- Missing captions on videos excludes deaf and hard-of-hearing users completely.
When respondents were given a free-text field, several other patterns surfaced. Screen reader users reported unlabelled images or nonsensical labels. AI-based recognition often can't provide the same context a designer would. Some apps unexpectedly move the screen reader focus, disorienting users. Voice Control users encounter apps unresponsive to voice commands and must fall back to alternate commands, slowing them down. Complex navigation—large, dynamic lists or auto-expanding menus—was called out as particularly difficult, with no easy workaround, and can push users to abandon an app altogether.
A Process For Building Inclusively
The scope of mobile accessibility can feel overwhelming, but progress is possible by fixing critical issues first, releasing, celebrating, and repeating. Over time, integrate accessibility into the development flow itself:
- Do research with users to learn how their assistive technology works and what barriers they face in your app.
- Create designs for accessibility features, including font scaling, state indicators, and visible focus.
- Get feedback from users on design revisions before development begins.
- Annotate design files with accessibility guidance based on user feedback and best practices.
- Use automated testing tools on each new build to catch common issues.
- Perform manual QA testing on the new build using your phone's own accessibility settings.
- Test with users on a private build before production release.
Understanding how assistive technologies work and the barriers users encounter is the first step to fixing and preventing issues. Given that half of surveyed users report accessibility problems significantly affecting their well-being, there is no good reason to wait for perfect technical knowledge. Building accessibility from the perspective of usability for everyone empowers all users to interact independently with your products—and that's what a more equitable internet requires.
