91.8% of Screen Reader Users Are on Their Phone. Is Your Site?
We still hear web teams describe mobile accessibility as a nice-to-have, something to circle back to after the desktop version passes an audit. The survey data says that ordering is backwards, and has been for a while.
WebAIM has run its Screen Reader User Survey eleven times since 2009. The eleventh, fielded in July and August 2026, drew 1,780 valid responses and landed on a number that should reorder every agency's QA checklist: 91.8% of respondents use a screen reader on a mobile device. Mobile isn't an edge case anymore. It's where most of your screen reader traffic already is.
1What Else Changed in Survey #11
JAWS remains the dominant desktop screen reader at 55.0%, with NVDA at 32.9% and VoiceOver at 6.5%. JAWS's share has bounced around for over a decade, down to 41% in 2024 and back up to 55% in 2026, which tells you something useful on its own: the assistive technology market isn't settled, and building to test against only one screen reader is a bet, not a strategy.
Geography matters too. JAWS leads NVDA heavily in North America, 72.5% to 15.6%. In Europe, the two run almost even, 42.8% to 42.3%. A state tourism site drawing international visitors or a university with international student programs is serving a genuinely different assistive technology mix than a single-county government portal.
2Why Government Sites Skew Desktop-First Anyway
A lot of government CMS platforms were built, or last meaningfully redesigned, years before this shift was obvious. Accessibility audits historically ran on desktop because that's where the auditor's screen reader license lived, and QA checklists just inherited that assumption without anyone revisiting it.
Meanwhile, residents applying for a permit, checking a trash pickup schedule, or reading a benefits notice are doing it from a phone, on a lunch break, standing in line, exactly where 91.8% of screen reader users already expect it to work. A site that passes a desktop screen reader audit while buttons mis-tap or focus order breaks on mobile touch navigation hasn't actually solved the problem most of its screen reader visitors are having.
3Proficiency Changes What "Accessible Enough" Means
57.8% of survey respondents reported advanced screen reader proficiency, versus 38.8% intermediate and only 3.4% beginner. These are experienced users who know exactly when a site is cutting corners. A workaround that a novice might not notice, like a focus trap on a modal or a skip link that doesn't actually skip anything, reads immediately as broken to someone who navigates by screen reader every day. Advanced users file the complaints. Advanced users are also the ones most likely to be on mobile, since that's simply where their daily computing happens now.
4VoiceOver and TalkBack Don't Behave the Same Way
Testing on one mobile platform and assuming the other behaves the same is a common shortcut, and it doesn't hold up. VoiceOver on iOS uses swipe gestures and a rotor control to jump between headings, links, and form fields. TalkBack on Android has its own gesture set and its own quirks around how it announces custom components. A button built with a generic div and a click handler, instead of a real button element, can announce fine on one platform and silently fail on the other.
Government residents skew toward whichever phone they already own, not whichever platform your team happened to test on. A permit form that passes a quick VoiceOver check but was never opened on an Android device under TalkBack is an unverified assumption, not a verified pass.
5Why Mobile Sessions Fail Differently Than Desktop Ones
A desktop screen reader user sitting at a keyboard has stable input, a full-size screen, and usually isn't multitasking against a dying battery or a spotty connection. A mobile screen reader user filling out a benefits form on a bus has none of that stability. Session interruptions, like a phone call or a dropped connection, hit harder on mobile, and a form that doesn't preserve entered data across an interruption punishes a mobile screen reader user far more than it punishes a desktop one. "It worked when I tested it at my desk" is a different claim than "it works for the person actually using it."
6Testing on a Budget That Doesn't Include New Phones
A small municipal IT team doesn't need a device lab to start closing this gap. Most staff already carry a personal iPhone or Android phone capable of running VoiceOver or TalkBack for free, built into the OS settings. Thirty minutes spent navigating your own permit form with one finger and the screen reader on, no mouse, no keyboard, surfaces more real problems than another round of automated scanning. Do it on both an iPhone and an Android device if you can borrow one, since the two platforms genuinely do fail differently.
7What to Actually Test, in Order
Touch target size and spacing
A link or button that works fine with a mouse pointer can be nearly impossible to tap accurately with VoiceOver gestures on a small screen.
Focus order on responsive layouts
Content that reflows into a single column on mobile needs a reading order that still makes sense, not just a visual rearrangement.
Forms under a mobile keyboard
Check whether a form field stays visible and properly labeled once the on-screen keyboard covers half the viewport.
PDFs opened from a phone
A tagged, accessible PDF that opens cleanly on desktop can still render badly in a mobile browser's built-in viewer. Test the actual path a resident takes.
Final Takeaway
If your last accessibility review happened entirely on a laptop with a desktop screen reader, it checked the minority use case. Run the same checklist from a phone before your next audit, and budget the fixes you find there first, not last.
See how your site reads on mobile
Our free scan checks your pages and PDFs the way residents actually encounter them, including on mobile browsers.
Run a Free PDF Audit