Screen Reader Testing for Beginners: A Practical Guide to NVDA and VoiceOver

Screen Reader Testing for Beginners: A Practical Guide to NVDA and VoiceOver

Automated accessibility tools are useful, but they only catch part of the picture. They can tell you an image has no alt attribute; they can’t tell you that your checkout announces “button, button, button” with no labels, or that a success message appears on screen but is never read out.

To find those problems, you need to use the product the way many disabled people do: with a screen reader. I use screen readers every day, both professionally and as a low vision user, and the most common thing I hear from designers and developers is that screen readers feel intimidating. They don’t need to be. This guide gets you from zero to a useful 15-minute test.

Key takeaways

  • Start with NVDA on Windows (free) or VoiceOver on Mac (built in). Test with Firefox or Chrome for NVDA and Safari for VoiceOver.
  • Screen reader users navigate by headings, landmarks, links and form fields, not by reading top to bottom.
  • Learn about ten commands and you can test most pages.
  • Follow a repeatable script and write down what you hear, not what you assume.
  • Your goal is not to simulate blindness. It’s to check whether the page communicates structure, names, roles and states.

Which screen reader should you start with?

The main desktop and mobile screen readers are:

Screen readerPlatformCostPair with
NVDAWindowsFreeFirefox or Chrome
JAWSWindowsPaid (has a demo mode)Chrome or Edge
VoiceOvermacOS and iOSBuilt inSafari
TalkBackAndroidBuilt inChrome
NarratorWindowsBuilt inEdge

If you’re on Windows, start with NVDA. It’s free, widely used and well supported. If you’re on a Mac, start with VoiceOver. Later, add a mobile screen reader, since a large share of real-world usage is on phones.

Getting set up

NVDA (Windows)

  1. Download NVDA from nvaccess.org and install it. During setup you can create a desktop shortcut, which also enables Ctrl + Alt + N to start NVDA.
  2. NVDA uses a modifier called the NVDA key: by default Insert (or Caps Lock if you choose the laptop layout).
  3. Turn on Speech Viewer (NVDA menu, Tools, Speech Viewer). It shows everything NVDA says as text, which is very helpful while you’re learning and for taking notes.
  4. To quit, press NVDA + Q.

VoiceOver (macOS)

  1. Turn VoiceOver on and off with Cmd + F5 (or triple-press Touch ID on some Macs).
  2. VoiceOver commands use the VO keys: Control + Option held together.
  3. Use Safari, which has the best VoiceOver support.
  4. Turn on the caption panel in VoiceOver Utility if you want to see the spoken output.

Tip: lower the speech rate at first. Experienced users listen very fast, but you’ll learn more at a comfortable speed.

The essential commands

You can test a surprising amount with this short list.

NVDA (browse mode)

ActionKeys
Stop speechCtrl
Read next / previous lineDown / Up Arrow
Next / previous headingH / Shift + H
Heading at a specific level1 to 6
Next landmarkD
Next form fieldF
Next buttonB
Next linkK
Next tableT
List of elements (headings, links, landmarks)NVDA + F7
Switch between browse and focus modeNVDA + Space
Read from current positionNVDA + Down Arrow (desktop layout)

VoiceOver (macOS)

ActionKeys
Stop speechControl
Next / previous itemVO + Right / Left Arrow
Activate itemVO + Space
Open the rotor (headings, links, landmarks, form controls)VO + U
Next headingVO + Cmd + H
Read from current positionVO + A
Move through interactive elementsTab

The elements list in NVDA and the rotor in VoiceOver are the fastest way to get an overview of a page’s structure. They show what many screen reader users see first.

Browse mode vs focus mode

This trips up most beginners. NVDA and JAWS have two main modes:

  • Browse mode (sometimes called virtual cursor) is for reading. Single-letter keys like H and K jump around the page.
  • Focus mode is for interacting with form fields and widgets. Keys are passed to the page, so typing “h” types the letter h.

NVDA usually switches automatically when you move into a form field. If something isn’t working the way you expect, check which mode you’re in. You’ll hear a click sound or an announcement when it changes.

A 15-minute screen reader test script

Use the same script on every page so your results are comparable.

1. Page title and language (1 minute)

Load the page. Does the screen reader announce a meaningful page title? Is the content pronounced in the right language?

2. Headings (3 minutes)

Open the elements list or rotor and view headings. Ask:

  • Is there one clear H1 that describes the page?
  • Do headings form a logical outline?
  • Is any visual heading missing from the list, meaning it’s just bold text?

3. Landmarks (2 minutes)

View landmarks. Is there a banner (header), navigation, main and contentinfo (footer)? Can you jump straight to the main content? My skip links guide covers this in detail.

View the links list. Do link names make sense out of context? Lists full of “Read more”, “Click here” or raw URLs are a red flag. Then Tab through buttons: does each one have a clear name?

5. Images (2 minutes)

Arrow through the content. Are meaningful images described usefully? Are decorative ones silent? See how to write alt text for what good looks like.

6. A key task (4 minutes)

Pick the most important thing the page does: search, sign up, add to cart, submit a form. Do it using only the screen reader and keyboard:

  • Is each form field announced with its label and required state?
  • When you make a mistake, are errors announced?
  • When you succeed, is the confirmation announced?
  • Do dialogs, menus and accordions announce when they open and close?

How to record findings

Write down exactly what you heard, what you expected, and where it happened. For example:

Location: Checkout, payment step

What happened: The card number field is announced as “edit text” with no label.

Expected: “Card number, edit text, required”

Impact: Screen reader users can’t tell which field is which.

WCAG: 1.3.1 Info and Relationships, 4.1.2 Name, Role, Value

Specific, reproducible findings get fixed. Vague ones (“screen reader doesn’t work”) don’t.

Common beginner mistakes

  • Testing with the mouse. Screen reader users mostly navigate with the keyboard or touch gestures. Put the mouse away.
  • Only reading top to bottom. Real users jump by headings, landmarks and links. Test the way they navigate.
  • Using the wrong browser pairing. VoiceOver works best with Safari, and NVDA with Firefox or Chrome. Other pairings can give misleading results.
  • Assuming one screen reader represents all. Behaviour differs. When something critical seems broken, check a second combination.
  • Treating it as a blindness simulation. You can still see the screen, and that’s fine. You’re checking the information the page exposes, not trying to experience disability.

Mobile screen readers

Once you’re comfortable on desktop, try mobile:

  • VoiceOver on iOS: Settings, Accessibility, VoiceOver. Swipe right and left to move between items, double-tap to activate, and use the rotor (twist two fingers on screen) to move by headings or links.
  • TalkBack on Android: Settings, Accessibility, TalkBack. Swipe right and left to move, double-tap to activate.

Set up an accessibility shortcut first (triple-click the side button on iPhone, or the volume-key shortcut on Android) so you can turn the screen reader off quickly.

Conclusion

Screen reader testing is a skill you build with practice, and you don’t need to be an expert to find real problems. Install NVDA or turn on VoiceOver, learn the core commands, and run the 15-minute script on your most important page this week. The issues you’ll find are exactly the ones automated tools miss.

Further reading

4 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *