Testing with Screen Readers

The Predicted Semantics Explorer

The built-in predicted semantics explorer parses the small HTML preview and estimates selected roles, names, states, and relationships. It is useful for learning how markup contributes to semantics, but it does not implement an operating-system accessibility API, virtual buffer, browse/focus mode, braille output, or any named screen reader.

Real screen readers interact with the operating system’s accessibility APIs, not directly with the DOM. They have heuristics, repair strategies, and quirks that no browser-based emulator can fully replicate. A component that works perfectly in the emulator might fail in JAWS because of a browser-specific ARIA mapping issue, or behave unexpectedly in VoiceOver because Safari computes accessible names differently from Chrome.

Think of the explorer as an annotated prediction, not test evidence. Use browser accessibility inspectors and automated checks for early feedback, then complete keyboard, zoom, visual, and real assistive-technology testing before shipping.

Screen Reader and Browser Pairings

Screen readers are tightly coupled with specific browsers. Each pairing uses a different accessibility API path, and testing with the wrong combination can produce misleading results. These are the standard pairings used in professional accessibility testing.

NVDA + Chrome or Firefox (Windows)

NVDA  is a free, open-source Windows screen reader. It is widely represented in the WebAIM Screen Reader User Survey, but no screen reader is a universal reference implementation. Test NVDA with both Firefox and Chrome when those pairings are in scope.

Getting started:

• Download and install from nvaccess.org 
• NVDA launches with Ctrl+Alt+N (or from the Start menu)
• The NVDA modifier key (called “Insert” or “NVDA key”) is used in most commands

Essential commands:

NVDA works with both Chrome and Firefox. Their accessibility mappings and timing can differ, so record the browser and version and test both when they are supported combinations.

VoiceOver + Safari (macOS and iOS)

VoiceOver is built into every Apple device — no installation required. On Mac, press Cmd+F5 to toggle it on and off. On iPhone and iPad, go to Settings > Accessibility > VoiceOver, or ask Siri to turn it on.

VoiceOver on macOS uses a two-key modifier called the “VO key,” which is Ctrl+Option by default. Almost every VoiceOver command starts with VO.

Essential macOS commands:

The Rotor is VoiceOver’s most powerful navigation feature. Press VO+U to open it, then use Left and Right Arrow to switch between categories (headings, links, form controls, landmarks), and Up and Down Arrow to select an item. Press Enter to jump to it. This is how real VoiceOver users scan an unfamiliar page.

On iOS, VoiceOver is gesture-based: swipe right to move to the next element, swipe left to go back, double-tap to activate. Twist two fingers (like turning a dial) to change the Rotor category, then swipe up/down to navigate within that category.

Use VoiceOver with Safari as the primary macOS pairing for this test matrix. If the product formally supports another macOS browser, test that pairing too and record it separately.

JAWS + Chrome (Windows)

JAWS (Job Access With Speech)  is the most widely used screen reader in corporate, government, and enterprise environments. It is a commercial product — a license costs several hundred dollars — but Freedom Scientific offers a 40-minute free mode that restarts when you reboot the computer. This is enough for testing sessions.

JAWS behavior differs from NVDA across modes, settings, browsers, and patterns. A result in one pairing does not prove conformance in another, so test the actual JAWS/browser combination in the support matrix.

Key differences from NVDA:

• JAWS uses the Insert key as its modifier (same default as NVDA)
• Virtual cursor navigation is similar: H for headings, Tab for interactive elements
• JAWS has a “forms mode” that auto-activates more aggressively than NVDA
• The JAWS equivalent of the element list is Insert+F5 (form fields), Insert+F6 (headings), Insert+F7 (links)

TalkBack + Chrome (Android)

TalkBack  is Android’s built-in screen reader. Enable it at Settings > Accessibility > TalkBack, or use the configured accessibility shortcut; setup varies by device and Android version.

Essential gestures:

Mobile screen reader testing is important whenever the experience supports mobile users. TalkBack behavior differs from desktop screen readers, especially for touch exploration, virtual keyboards, gesture conflicts, target sizing, and responsive layouts.

Basic Testing Checklist

Use this checklist with any screen reader. Work through it on every component and page before considering accessibility testing complete.

Keyboard Navigation

1. Can you reach all interactive elements with Tab? Every button, link, input, and custom control must appear in the tab order. Nothing interactive should be skipped, and nothing non-interactive should be in the way.
2. Can you activate buttons and links with Enter and Space? Native HTML elements handle this automatically. Custom elements built from <div> or <span> must add keyboard event handlers explicitly.
3. Is the tab order logical? Focus should move in a sequence that matches the visual layout, typically left-to-right, top-to-bottom. Unexpected focus jumps disorient users.

Labels and Announcements

4. Are all form fields labeled? When you Tab to an input, the screen reader should announce its label. If it only says “edit text” or “combo box” with no label, the field is inaccessible.
5. Are dynamic updates announced? Content that changes without a page reload — toast notifications, error messages, live search results, loading states — must use ARIA live regions (aria-live="polite" or role="status") to be announced by screen readers.
6. Do custom controls communicate state? Accordions should announce “expanded” or “collapsed.” Toggles should announce “pressed” or “not pressed.” Tabs should announce “selected.” If the screen reader doesn’t describe the state, the user can’t tell what happened when they interact.

Structure

7. Is the heading structure logical? A single page-topic h1 is a useful convention, not a WCAG requirement. Use levels to represent the hierarchy and avoid unnecessary downward skips such as h2 to h4. Navigate by heading and confirm the structure makes sense.
8. Do images have appropriate alt text? Informative images need descriptive alt text. Decorative images need alt="" (empty alt) so screen readers skip them. Images with no alt attribute at all are announced by their file name, which is almost always useless.
9. Are decorative elements hidden from the screen reader? Icons used purely for decoration, visual separators, and background images should use aria-hidden="true" or be implemented in CSS so they don’t clutter the screen reader experience.

Focus Management

10. Does focus management work for modals and overlays? When a modal opens, focus must move into it. When it closes, focus must return to the element that triggered it. Content behind the modal must be inert (unreachable by screen reader or keyboard).

Automated Tools

Automated accessibility testing tools are valuable for catching certain categories of issues quickly, but they have hard limits. Use them as a first pass, not a final verdict.

axe-core and axe DevTools

axe DevTools  is a browser extension from Deque Systems that runs the open-source axe-core  engine against your page. It checks for missing alt text, empty buttons, color contrast violations, missing form labels, invalid ARIA attributes, and dozens of other machine-detectable issues.

• Available as a Chrome and Firefox extension
• Can also be integrated into CI/CD pipelines via @axe-core/cli or testing frameworks like jest-axe and cypress-axe
• Detects only issues that can be determined from machine-testable rules; coverage varies by page, rule set, and what is counted

Lighthouse Accessibility Audit

Chrome DevTools includes a Lighthouse audit (DevTools > Lighthouse tab > check “Accessibility” > Generate report). It runs a subset of axe-core rules and produces a score from 0 to 100.

• Good for getting a quick baseline
• A score of 100 does not mean the page is accessible — it means no machine-detectable violations were found
• Useful for catching regressions in CI when run via the Lighthouse CLI

WAVE

WAVE  is a visual evaluation tool from WebAIM. It overlays icons and indicators directly on your page to highlight errors, alerts, structural elements, and ARIA usage. The browser extension version works on localhost and authenticated pages.

• Particularly good for visual learners who want to see where issues are on the page
• The “details” sidebar explains each issue with references to WCAG criteria
• Also available as an API for automated scanning

Automation Has No Universal Percentage

There is no defensible universal percentage of accessibility issues that automation will catch. Results depend on the content, tool, rules enabled, test states reached, and whether the denominator is WCAG criteria, defects, pages, or user barriers. Automated checks are valuable regression controls, but a clean run does not establish WCAG conformance.

Issues that automated tools catch well:

• Missing alt attributes on images
• Missing form labels
• Color contrast ratios below WCAG thresholds
• Invalid ARIA attribute values
• Duplicate IDs
• Missing document language

Issues that require manual testing:

• Whether alt text is actually meaningful (a tool knows it exists, not whether it’s useful)
• Whether focus order is logical
• Whether a custom widget is operable by keyboard
• Whether live region announcements are timely and not excessive
• Whether a modal properly traps focus
• Whether the reading order makes sense when CSS layout differs from DOM order
• Whether error messages are associated with the correct fields and announced at the right time

The bottom line: run axe-core in your CI pipeline to prevent regressions, and pair every release with manual screen reader testing to catch what automation cannot.

Resources

Screen Reader Downloads and Guides

• NVDA — Free download  and NVDA User Guide 
• VoiceOver Getting Started Guide (macOS) 
• VoiceOver for iPhone User Guide 
• JAWS — Download and 40-minute demo 
• TalkBack documentation (Android) 

Surveys and Research

• WebAIM Screen Reader User Survey  — the most comprehensive data on how screen reader users browse the web, updated periodically
• The WebAIM Million  — annual analysis of the top one million home pages for accessibility errors

Learning Resources

• Deque University  — free and paid courses on web accessibility, ARIA, and testing
• WAI-ARIA Authoring Practices Guide  — reference implementations for common widget patterns
• A11y Project Checklist  — a practical WCAG compliance checklist
• WCAG 2.2 Quick Reference  — the official guidelines with filtering by level and topic