Skip to content

Testing with screen readers (updated)

Testing with a screen reader is an important part of accessibility work. It helps anyone who uses that particular assistive technology (such as blind people and people with other visual disabilities). It helps me check that my code is robust and semantic.

This is an updated version of a previous post: Testing with screen readers. I’ve split this up into what I test (tech-agnostic), Testing with VoiceOver on MacOS, and Testing with NVDA on Windows.

What I test

The amount of time I have available for testing determines how in-depth I can test. It’s only when I have plenty of time that I sit and use a screen reader to read through the whole content of the page in detail. My usual check list looks like this:

  1. Check structure.
    • Landmarks: do they exist and do they have helpful names?
    • Headings: are they nested correctly?
    • Tables: is there a caption? Are row and column headers correctly scoped?
  2. Check interactions.
    • Links: does the link text describe the destination?
    • Form controls
      • do fields have associated labels?
      • does button text describe the action?
      • is help text associated with the control (using aria-describedby)?
      • do radio and checkboxes have a group name (using fieldset and legend)?
  3. Check alt text of images: does it convey the content and function of the image?
  4. Check form error handling. (Warning! This could get a bit hairy. 😬)
    • Is the error message with the field (added to the label, or in an associated aria-labelledby)?
    • Is the field marked as invalid (with an aria-invalid="true" attribute)?
    • If there’s a list of errors at the top of the page:
      • are there in-page links down the page to the fields with errors (and is focus set to that field on jump)?
      • are errors announced? (add aria-live="assertive" so it announces and aria-relevant="additions removals" so it isn’t overly verbose. role="alert" gets aria-atomic="true" by default, so re-reads the whole thing each time.)
  5. Does the order of content make sense?

Screenshot of me using VoiceOver on a Mac showing "heading level 2"

Getting some help

Both Deque University and WebAIM have great guides.

Testing with VoiceOver on MacOS

First time set up

Before getting going for the first time, I needed to do some once-off set up of my system and Safari. I use Firefox and Chrome as my usual browsers, but VoiceOver and Safari work better together.

  1. System Preferences:
    1. Keyboard item > Shortcuts tab > tick “Use keyboard navigation to move focus between controls”
  2. Safari Preferences:
    1. Advanced tab > Accessibility item, tick “Press Tab to highlight each item on a web page.”
    2. AutoFill tab > untick all. (I do this to make VoiceOver less noisy on form fields)

Each time set up

Here’s what I do each time to get started testing.

  • Open Safari. Since it’s not my default browser I often forget this step! This leads to me spending a few moments confused about why VoiceOver isn’t working properly…
  • Start VoiceOver (VO) with Cmd + F5;
  • Lock VO activation keys with Ctrl + Option + ;.
    • This means I can use the activation keys without having to hold Ctrl + Option each time.
  • Press Shift + ↓ to jump into the page.

Testing

  • Open the Rotor with U (and later exit it with Esc).
    • Use the ← and → keys to move between menus and ↑ and ↓ inside menus. (Test landmarks, headings, links, and forms from here.)
  • Cycle through images using Cmd + G.
  • Use R and C to hear row and column headers of tables.
  • Start reading with A. Jump through the page with →. Stop reading with Ctrl.
  • Jump to the top of the page with Fn + ←.

Testing with NVDA on Windows

First time set up

Turn on Speech Viewer in Tools. This displays the speech as text on the screen. I find it very helpful!

Testing

  • Turn off Num Lock. (I tend to have it on for day to day use)
  • Start NVDA with Ctrl + Alt + N.
  • Open the helper with Ins + F7. (Test landmarks, headings, links, forms from here.)
  • Cycle through images using G.
  • Use T to cycle through tables. Use Ctrl + Alt + arrow keys to move around table cells.
  • Use Ins + Space to switch between Browse mode (reading) and Focus mode (entering data in forms) if needed.
  • Jump to the top of the page with Numpad +.

Summary

Testing with a screen reader has the potential to be complicated and time-consuming. To do a full-on test, it kinda is. I’ve tried to get around this a bit by:

  • getting some experience so I’m a bit faster using one;
  • testing the most important things first;
  • having a standardised way of testing.