Know the major screen readers

There is no universal screen reader

A screen reader is part of a larger environment. The operating system supplies accessibility APIs, the browser or app exposes product information, and the available input device shapes navigation. A result from one combination does not automatically describe another. VoiceOver on an iPhone, for example, has a different interaction model from VoiceOver on a Mac even though both products share a name.

• Desktop screen readers often emphasize keyboard commands and efficient navigation through dense information.
• Mobile screen readers combine touch exploration, swipe navigation, gestures, and external keyboards or braille displays.
• Desktop web testing often combines a browser, keyboard, and a screen reader's structural navigation model.
• Native mobile app testing often combines touch exploration, swipe order, system dialogs, and platform components.
• Browser and app versions can change how the same screen reader receives information.

Start with supported environments

Do not begin with a generic list of popular screen readers. Begin with the operating systems, devices, browsers, and apps that the product supports. Then identify the screen readers available in those environments. Product analytics, support requests, user research, procurement requirements, and platform documentation can all inform the decision.

• Record whether each combination is officially supported, commonly used, or included for investigation.
• Separate desktop web, mobile web, native iOS, native Android, and embedded web-view contexts.
• Include input methods such as keyboard, touch, and braille when they affect the task.
• Define representative user journeys instead of testing every page in every combination.
• Review the matrix when platform versions or product support change.

Use market-share statistics carefully

Use statistics to choose starting points, then test the combinations your product actually supports. These figures come from the linked survey and telemetry sources below; they are not a complete global install-base measurement.

Interpret differences carefully

Different phrasing does not always indicate a defect. Two screen readers can announce the same name, role, state, and value in a different order. A defect exists when necessary meaning or operation is missing, incorrect, confusing, or unavailable. Teams should compare the information and task outcome, not require one exact spoken sentence from every product.

• Confirm that the control exposes valid information through the platform.
• Check whether the user can find, understand, and operate it.
• Distinguish a product defect from a screen reader preference or platform convention.
• Record combination-specific behaviour instead of generalising it to all users.
• Escalate suspected platform defects with a small reproducible example.

Create a practical baseline

A small team does not need every screen reader on the first day. Establish a baseline that covers the product's most important environments and tasks, then add combinations when evidence shows a need. Keep installation notes, test accounts, settings, and short command references ready so that testing is repeatable. The baseline should reduce obvious coverage gaps without becoming a promise that every possible configuration has been validated.