Test with keyboard and assistive technology

Automation covered a third. The rest needs a human at a keyboard, a screen reader, a zoomed screen and a voice. But “test with a screen reader” is not a plan. It’s an afternoon of wandering. A plan says which combinations, which tasks, what you expect to hear, and what counts as evidence.

Pick a small matrix

Screen readers and browsers pair up differently. VoiceOver is tuned for Safari. NVDA and JAWS are tuned for Chrome and Firefox on Windows. Testing one pair doesn’t tell you about the others, and testing every pair is impossible. Pick the ones your audience uses and write them down.

For the registration page I use this:

Keyboard only           Chrome, macOS
Zoom 400%               Chrome, 1280px screen
Screen reader, desktop  VoiceOver + Safari, macOS
Screen reader, desktop  NVDA + Firefox, Windows
Screen reader, mobile   VoiceOver + Safari, iOS
Voice control           Voice Control, macOS

Six rows. Each release runs all six against the same tasks. When a JAWS user reports a bug, we add a row.

Learn the handful of commands you need

You don’t need to master a screen reader to test with one. On macOS, Command + F5 toggles VoiceOver. The VO keys are Control + Option. VO + Right Arrow reads the next item, VO + U opens the rotor with headings, landmarks, form controls and tables. On Windows, NVDA is free. Insert is the NVDA key, and in a page you press H for the next heading, F for the next form field, B for the next button and T for the next table. On iOS, swipe right to move to the next item and double tap to activate it.

Ten minutes with those and you can run every task in this course.

Write the expected outcome first

Each row gets the same tasks from lesson 1, with the expected result spelled out before you start:

Task: submit with 2 errors
Expect: focus lands on "There are 2 problems with your registration"
        each invalid field announces its error text
        valid values are still in place

Task: say "Click Register" (voice control)
Expect: the form submits

Run it and record pass or fail per row, with a screenshot or a short recording as evidence. Here’s a finding from our matrix that keyboard testing alone never showed:

Voice Control, macOS  "Click Add a guest"  FAIL
  Nothing happens. Button has aria-label="Open guest dialog".
  Fix: remove aria-label so the visible text is the name.

That’s WCAG 2.5.3 Label in Name, caught because a voice row was in the matrix.

Don’t overclaim

A pass on six rows means the page works on six rows. Say that in the report. The mistake is to test on your own Mac with VoiceOver, hear everything announced nicely, and write “screen reader accessible”. An NVDA user on Firefox may hit a different problem, and now they don’t believe the rest of your report either.

The other mistake is exploring without a task. You listen to the page for ten minutes and conclude it “sounds fine”. Without an expected outcome there’s nothing to fail, so nothing fails.

Try this on your own page: pick three rows, write the expected result for a registration-style task before testing, run it, and keep the evidence for each row.