In a previous post, I wrote about the most used screen reader and browser combinations, based on the WebAIM Screen Reader User Survey #10: JAWS with Chrome at 24.7%, NVDA with Chrome at 21.3%, and three other pairings that together cover the majority of desktop screen reader usage.
That data tells you where to start when you have nothing else to go on. Its limit is that it describes the world in aggregate, not your users.
What your analytics already know
Most analytics platforms, including Google Analytics, Plausible and Fathom, collect data about the technical environment of every visit:
- Browser: Chrome, Safari, Firefox, Edge, and their versions
- Operating system: Windows, macOS, iOS, Android, Linux
- Device type: desktop, mobile, tablet
- Screen resolution, which shows how interfaces are actually rendered
Some platforms, when configured correctly, can also surface data about accessibility-related browser features, though this varies a lot by tool and configuration.
This data is collected by default and sits in most dashboards, yet teams almost never consult it when they choose accessibility testing environments.
Why it matters for testing decisions
Consider two products with very different user bases.
A government service used mostly by older adults on Windows desktops has a testing profile weighted toward JAWS and NVDA with Chrome or Edge. A mobile-first consumer app with a younger audience may get 70% of its traffic from iOS, which makes VoiceOver with Safari the top combination to validate.
The WebAIM Survey would point both teams in the same direction. Their analytics would not.
Any screen reader testing is useful. But if you prioritise the wrong combination, the experience most of your actual users have may be the one you test least.
The gap between data and decisions
The data exists, but it rarely reaches the accessibility conversation.
Developers and QA engineers tend to make accessibility decisions from general guidance: WCAG criteria, survey data, tooling defaults. Analytics lives in dashboards that product managers and marketing teams check for other purposes.
Closing that gap is a process question. It needs no new tools, only one question asked before deciding what to test: what do we know about who uses this product, and how?
The answer is usually already available. Nobody looks it up.
A practical starting point
Before your next accessibility testing cycle, pull the browser and operating system breakdown for your product from whatever analytics tool you use.
Look at the top three or four combinations, match them with the screen reader pairings most common on each operating system, and adjust your testing priorities.
It takes less time than a full audit, and it puts your testing effort on the environments your actual users depend on.