Screen Reader Testing Guide for Developers and QA

What is a Screen Reader?

A screen reader is a software application that interprets what is displayed on the screen and presents it to the user via text-to-speech (TTS) or a braille display. They are essential tools for users who are blind or have severe low vision.

The Big Three Screen Readers

These are the most widely used screen readers:

NVDA (NonVisual Desktop Access): A free, open-source screen reader for Windows, used around the world.
JAWS (Job Access With Speech): A commercial screen reader for Windows. It has long been the standard in corporate environments.
VoiceOver: Built directly into Apple's operating systems (macOS, iOS, iPadOS).

*Note: Testing on mobile (VoiceOver on iOS and TalkBack on Android) is just as important as desktop testing.*

Basic Screen Reader Concepts

Screen readers have two primary modes of interaction:

Focus Mode (or Forms Mode): When the user interacts with a form field or application widget, the screen reader passes keystrokes directly to the browser/widget.
Browse Mode (or Reading Mode): The screen reader intercepts keystrokes to provide quick navigation commands (e.g., pressing 'H' jumps to the next heading, 'B' jumps to the next button).

Basic Testing Commands (NVDA / JAWS)

Here are the essential commands to get started on Windows:

Stop Speech: Ctrl
Read Next Item: Down Arrow
Read Previous Item: Up Arrow
Jump to Next Heading: H (Shift+H for previous)
Jump to Next Button: B (Shift+B for previous)
Jump to Next Link: K (NVDA); in JAWS, Tab, or U for the next unvisited link
Jump to Next Landmark/Region: R (JAWS) or D (NVDA)
Activate Element: Enter or Spacebar

What to Test For

When testing with a screen reader, focus on the user's experience and context:

Meaningful Content: Does the screen reader announce all the information available visually? Are images described appropriately via alt text?
Structural Navigation: Can you easily jump through the page using Headings (H) and Landmarks (R/D)? Is the page structure logical?
Interactive Elements: When you land on a button or link, is its purpose clear? Does it announce its state (e.g., "collapsed" vs "expanded" for a menu button)?
Dynamic Changes: When new content appears (like an error message or a modal opening), is it announced? (This often requires ARIA live regions or careful focus management).

Perguntas frequentes

Do I need to test with all screen readers?

While testing with multiple screen readers is ideal, testing thoroughly with just one (like NVDA on Windows or VoiceOver on Mac) will find most screen reader problems.

Why does the screen reader behave differently in different browsers?

Screen readers rely on the accessibility tree, which is generated by the browser. Different browsers (Chrome, Firefox, Safari) may interpret HTML/ARIA slightly differently and expose different information to the accessibility API.