---
title: Screen Reader Testing
category: product
entity_type: skill
price: $15
canonical: https://forgehouse.ai/skills/screen-reader-testing/
lang: en
hreflang_alt: https://forgehouse.ai/tr/skiller/screen-reader-testing/
last_updated: 2026-06-20
---

# Screen Reader Testing

> Test web applications with screen readers including VoiceOver, NVDA, and JAWS.

A practical, command-level playbook for testing your web app with real screen readers including VoiceOver, NVDA, and JAWS, so you validate accessibility the way disabled users actually experience it. It covers the full assistive-technology chain from browser to accessibility tree to spoken output, with concrete fixes for the most common breakages like unlabeled icon buttons, silent dynamic content, and unannounced form errors. You move from guessing to verifying across the screen readers that cover the vast majority of real users.

## Use cases
- Validate ARIA implementations against actual screen reader output
- Debug why an icon button announces nothing to VoiceOver
- Test modal focus trapping and focus return on close
- Verify form labels, required fields, and error announcements
- Confirm live regions announce dynamic content correctly
- Cross-test the same flow on NVDA and JAWS for platform variance

## Benefits
- Ship interfaces that work for assistive technology, not just visual users
- Catch focus-management bugs that make modals invisible to screen readers
- Resolve the role-name-state announcement gaps before users hit them
- Distinguish real bugs from screen-reader platform variance with confidence

## What’s included
- Essential command references for VoiceOver, NVDA, JAWS, and TalkBack
- Per-screen-reader testing checklists for page load, navigation, forms, and tables
- Before-and-after HTML fixes for buttons, live regions, and form errors
- Accessible modal pattern with focus trap and Escape handling
- Tab interface and live region reference implementations
- A debugging snippet that logs the accessible name, role, and state of any element

## Who it’s for
For front-end developers and QA engineers who need to prove screen reader compatibility with real assistive technology, not simulators.

## How it runs
An accessibility audit that never ran a real screen reader is a guess. NVDA, VoiceOver, and JAWS walk the page element by element, and divergent behavior gets triaged, not dismissed.
1. Sets the coverage matrix first: minimum NVDA plus Firefox on Windows and VoiceOver plus Safari on macOS and iOS; comprehensive runs add JAWS, TalkBack and Narrator to cover roughly 90 percent of real usage.
2. Walks page structure with each reader's own navigation keys: page title announced on load, all landmarks reachable, heading levels logical when browsed through the rotor or the elements list.
3. Tests every interactive element against the announcement order of role, name, state and description: an icon-only button with no accessible name is a broken chain and gets an aria-label fix on the spot.
4. Runs the form script: labels read together with inputs, required fields announced, an invalid submission moves focus to the error and the message is spoken through role=alert and aria-describedby.
5. Validates dynamic content: aria-live regions announce updates, modals trap focus on open and return it to the trigger on close, and SPA route changes move focus to the new page heading.
6. Cross-checks results between at least 2 screen readers, because identical ARIA can behave differently in NVDA Browse Mode versus JAWS Forms Mode; divergence is triaged as platform variance with a documented workaround, not a random failure.

## FAQ
### I only have a Mac, can I still test NVDA and JAWS coverage?
The playbook gives per-screen-reader command references and checklists for all of them, but NVDA and JAWS run on Windows, so cross-testing needs a Windows machine or VM. VoiceOver coverage on macOS works right away.

### Why isn't an automated scanner like axe or Lighthouse enough?
Scanners check markup; this validates the full chain from browser to accessibility tree to spoken output, the way disabled users actually experience the page. That catches what scanners miss: silent live regions, modals that trap focus without returning it, and form errors that are never announced.

### Does passing these tests certify my site as WCAG compliant?
No. It proves screen reader behavior with real assistive technology and gives before-and-after HTML fixes, but WCAG conformance also covers contrast, motion, and timing, areas outside screen readers. A formal audit is a separate exercise.

## Price
$15, one-time, no subscription. VAT included.

Related guide: [Building a design system with Claude Design](https://forgehouse.ai/guides/claude-design-design-system/)