Screen Readers Are Not a Checkbox: What the 2024 User Survey Means for Your Software

The latest WebAIM Screen Reader User Survey dropped a number that should stop every software team cold: 91.3% of screen reader users are using one on a mobile device (WebAIM). That's not a niche of power users with expensive setups—it's the mainstream of assistive technology. If you're still thinking of screen readers as a desktop-only accessibility afterthought, you're already behind.

We've spent years building software used by people who rely on assistive tech, and the data keeps confirming one thing: screen reader users are diverse, mobile-first, and not at all like the test cases your automated checker flags. The 2024 survey, with 1,539 respondents, gives us a rare window into how this population actually works—and it's time we act on it.

The Mobile Shift Is Real

Imagine you're a product manager for a health portal. You've just run an automated accessibility scan and fixed every 'low contrast' and 'missing alt text' error. You're feeling good. Then you check your analytics and see that 40% of your visitors are on phones, and you wonder: are any of them using a screen reader?

They probably are. The survey says 91.3% of screen reader users report using one on a mobile device, and that includes 93.6% of those with disabilities (WebAIM). So the next time you see a user session from an iPhone with VoiceOver, that's not an anomaly—it's the norm. If your mobile app or responsive site isn't tested with VoiceOver, you're effectively locking out a huge chunk of your audience.

Who's Actually Using Screen Readers?

It's tempting to picture a single profile: a blind user on a desktop with JAWS. But the survey shatters that stereotype. 76.6% of respondents report blindness, but 19.9% have low vision—meaning a significant portion can see, just not well enough to rely on visual cues alone (WebAIM). And 5.3% are both deaf and blind, relying on braille output more than audio (WebAIM).

That's why you can't design for just one mode. One user might swipe through pages with VoiceOver on an iPhone, another might tab through a desktop site with NVDA, and a third might be reading braille on a refreshable display. The survey shows 38% use braille output with their screen reader (WebAIM)—that's not a rounding error. Your software needs to work across all of these, not just the one you tested.

The Tools Users Actually Choose

On mobile, 70.6% use VoiceOver and 34.7% use TalkBack (WebAIM). On desktop, the market is split: JAWS holds 40.5% and NVDA 37.7% as primary screen readers, but when you ask which they've ever used, NVDA edges out JAWS at 65.6% vs 60.5% (WebAIM). That's not a niche preference—it's a near tie, and it means you can't just test with one.

Here's the kicker: 71.6% of respondents use more than one screen reader (WebAIM). So a user might start with VoiceOver on their phone, then switch to NVDA on a work computer. If your app behaves differently in each, they'll notice. And don't overlook NVDA—it's free and open source, translated into over 55 languages, and used in more than 175 countries (NV Access). That's not a fringe tool; it's a global standard.

Automated Testing Is Not Enough

You might think, 'We run Lighthouse and axe, we're fine.' But the WebAIM Million analysis of home pages found 95.9% have detectable WCAG 2 failures, averaging 56.1 errors per page (WebAIM). The most common errors are things an automated tool can catch—low contrast (83.9%), missing alt text (53.1%), missing labels (51%)—yet they persist. Why? Because automated tools can't tell you if a screen reader actually navigates your page logically.

We learned this the hard way. We had a page that passed every automated check, but when we tested with NVDA, the focus order jumped from the header straight to a footer link, skipping the main content. No automated tool caught that. Only a human using the software did.

What This Means for Your Testing Workflow

So here's our recommendation: add a structured screen reader test to every sprint. Not a one-time audit—a regular, scripted pass. Here's a practical starting point:

• Test on both mobile and desktop: VoiceOver on iOS and TalkBack on Android at minimum.
• Test with at least one free desktop tool: NVDA is the obvious choice, given its reach.
• Run a quick task-based script: can a user find a product, add it to cart, and check out without visual cues?
• Include a braille user in your testing at least once per release, since 38% rely on it.

This isn't about ticking boxes for compliance—though the legal pressure is real: US federal website accessibility lawsuits hit 3,117 in 2025, a 27% increase (WebAIM). It's about not excluding a fifth of your potential users.

The Bottom Line

The single most important thing to remember: screen reader users are not a monolith, and they're not a checkbox—they're real people on real devices, and your software needs to work for them. Start with a mobile-first, multi-tool testing routine, and you'll catch the issues that matter.

Sources

• WebAIM Screen Reader User Survey - https://webaim.org/projects/screenreadersurvey10/
• WebAIM Million - https://webaim.org/projects/million/
• NV Access - https://www.nvaccess.org/about-nv-access/