WCAG

Screen reader testing — how to check accessibility in practice

WCAG checklists and automated tools are a good start — but screen reader testing shows what actually works and what does not.

Why screen reader testing is necessary

Automated accessibility tools (axe, Lighthouse, WAVE) check code structure — whether alt texts exist, whether headings are in order, whether colour contrast meets the standard. This covers roughly 30% of accessibility issues.

The remaining 70% — whether navigation is logical, whether focus moves sensibly, whether modal dialogs behave as expected, whether dynamic content is accessible — can only be discovered through real use.

Screen reader testing shows the site as a user who does not use a mouse experiences it.

Which screen readers exist

NVDA (Windows, free) — the most widely used screen reader on Windows. Ideal for testing since most users are on Windows.

JAWS (Windows, paid) — the most common professional screen reader. A demo version is available.

VoiceOver (macOS and iOS, built-in) — good for testing on Apple devices. Enable with Cmd+F5.

TalkBack (Android, built-in) — for mobile testing on Android.

Getting started: VoiceOver on macOS

VoiceOver is the most accessible option for developers on a Mac.

Enable: Cmd+F5 (or System Settings → Accessibility → VoiceOver)

Basic controls:

  • Tab — move focus to the next element
  • Shift+Tab — move backwards
  • VoiceOver + Right/Left arrow — navigate within an element
  • Space / Return — activate an element
  • VoiceOver + U — opens the rotor (quick navigation by headings, links, forms)

The VoiceOver key is Caps Lock or Ctrl+Option.

Getting started: NVDA on Windows

  1. Download from nvaccess.org (free)
  2. Install
  3. Launch NVDA — it starts reading immediately

Basic controls:

  • Tab — move focus forward
  • H — next heading (in Browse Mode)
  • F — next form element (in Browse Mode)
  • NVDA+F7 — elements list (links, headings, forms)
  • Enter — enter Focus Mode (for filling forms)
  • Escape — exit Focus Mode

What to test

Keyboard navigation

  • Every interactive element is reachable with Tab
  • Focus is always visible
  • There are no keyboard traps where Tab cannot escape

Page structure when listened to

  • H1 is single, clear, and describes the page
  • Headings follow a logical order (H1 → H2 → H3)
  • The page makes sense when listened to without visual context

Forms

  • Every field's label is clear and associated with the field
  • Error messages are understandable and focus moves to the error
  • Buttons describe what they do ("Submit" not "Click here")

Images

  • Decorative images have alt="" (screen reader ignores them)
  • Informative images describe what is shown
  • Charts and graphs have alternative text descriptions

Dynamic content

  • Modal dialogs automatically focus their content
  • After closing a modal, focus returns to the element that opened it
  • Live regions (notifications, loading states) are announced by screen readers

Common issues automated tests do not find

Meaningless alt text — "image001.jpg" or "photo" passes automated checks but communicates nothing useful.

Illogical focus order — visually the page looks sensible but Tab moves in an unexpected sequence.

Modal does not close on Escape — a standard expectation for screen reader users but automated tests do not check behaviour.

Icons without text — a gear icon for "Settings" without visible or hidden text is unknown to a screen reader.

EAA 2025 context

From June 2025 the European Accessibility Act requires most e-commerce and public services to meet WCAG 2.1 AA. Screen reader testing is one of the most practical ways to verify compliance.

Need help with an accessibility audit? Contact us.

Kaido Toomingas Kaido Toomingas WebPro Company OÜ

Need Drupal help?

If the article describes your situation, you do not have to read everything first. A real person will help you choose the next step.

Contact us