Ability Bazaar guide
What is screen-reader testing, and why does it matter?
The short answer
A screen reader converts interface information into speech or refreshable braille and provides commands for navigating headings, links, landmarks, forms, tables and controls. Screen-reader testing uses that interaction model to complete representative tasks and record barriers.
Common combinations include NVDA with Windows, JAWS with Windows and VoiceOver on Apple platforms. Testing must be planned: results depend on the browser, operating system, screen-reader version, settings, tester skill and the tasks selected.
What can screen-reader testing reveal?
- Controls that have no useful name, role, state or value.
- Heading and landmark structures that make navigation confusing.
- Reading and focus order that differs from the intended visual sequence.
- Status, validation and error messages that are never announced.
- Custom widgets whose keyboard commands or announcements are incomplete.
- Tables, images and documents whose meaning is lost in nonvisual use.
- Workflows that are technically operable but inefficient or disorienting.
Why is a native assistive-technology user valuable?
A person who uses a screen reader in daily life brings efficient navigation strategies and can recognise barriers that a sighted tester following a script may miss. That lived experience is especially valuable when evaluating task flow, announcements, orientation and recovery from errors.
Native-user testing is not a shortcut around standards. W3C recommends combining disabled-user evaluation with conformance evaluation, and warns against assuming one user represents everyone. A mature review records both WCAG findings and broader usability observations.
Sources for this section: [5]
Which browser and screen-reader combinations should be tested?
There is no universal matrix. Choose combinations used by the target audience and supported by the product. At minimum, record the exact operating system, browser, screen reader and version so another tester can reproduce the result.
A public website serving a broad audience may need more than one desktop combination plus mobile VoiceOver or TalkBack. An internal enterprise product may have a narrower supported environment. Scope should follow users and risk, not a vendor's favourite tool.
How do you prepare a useful screen-reader test?
- List essential tasks and the expected successful outcome for each.
- Provide realistic test accounts and data without exposing customer information.
- Include navigation, search, forms, errors, dialogs, documents and time-sensitive steps.
- Define supported browser and assistive-technology combinations.
- Ask testers to report impact, steps, actual result, expected result and evidence.
- Separate product defects from tester preferences and document both appropriately.
- Re-test the same task after remediation.
Frequently asked questions
- Is screen-reader testing the same as automated accessibility testing?
No. It evaluates a rendered experience and real tasks using assistive technology; automation inspects only rules that software can decide.
- Which screen readers are commonly included?
Common examples are NVDA and JAWS on Windows and VoiceOver on Apple platforms. The right matrix depends on actual users and supported environments.
- Does one blind tester represent all users?
No. Lived experience adds essential insight, but disability, technology, skill and preferences vary. Combine multiple perspectives with standards-based evaluation.
Sources
- W3C WAI, How People with Disabilities Use Browsers and Assistive Technologies
- NV Access, NVDA Screen Reader
- Freedom Scientific, JAWS
- Apple, VoiceOver User Guide
- W3C WAI, Involving Users in Evaluating Web Accessibility
Sources were checked on August 21, 2026. Regulations, standards and product documentation can change; follow the linked source for the latest version.