The Emulator as Training Wheels

The built-in screen reader emulator on this site simulates NVDA-like behavior — it builds an accessibility tree from your HTML, walks it with arrow keys and shortcut commands, and announces element roles, names, and states. It is a useful learning tool for understanding what screen readers do with your markup, but it is not a substitute for testing with real assistive technology.

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 emulator as a spell-checker: it catches obvious problems early, but you still need a human to read the final draft. Use the emulator to learn patterns and catch structural mistakes during development, then test with real screen readers 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 free, open-source, and the second most widely used screen reader after JAWS. It is the most literal of the major screen readers — it tends to announce exactly what the accessibility tree contains, without adding interpretive heuristics. This makes it the best choice for verifying that your ARIA implementation is technically correct.

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 well with both Chrome and Firefox. Firefox sometimes exposes accessibility tree information more accurately for certain ARIA patterns, so test with both if you encounter unexpected behavior.

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.

VoiceOver should always be tested with Safari. Chrome on macOS has incomplete VoiceOver support and will produce inaccurate results.

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 is the most thorough screen reader. It sometimes announces information that others skip, and it has decades of heuristics built in to compensate for poorly coded sites. This means that pages which “work” in JAWS may actually have accessibility bugs that JAWS is silently repairing — another reason to test with NVDA as well.

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 hold both volume keys for 3 seconds on most devices.

Essential gestures:

Mobile screen reader testing is increasingly important. Over 70% of web traffic is mobile, and TalkBack behavior can differ significantly from desktop screen readers, especially for touch-target sizing, gesture conflicts, and viewport-dependent 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? There should be one h1 per page, and headings should not skip levels (don’t jump from h2 to h4). Navigate by heading with the H key and confirm the hierarchy 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
• Catches approximately 30-40% of WCAG violations automatically

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

The 30-40% Rule

Automated tools reliably catch less than half of accessibility issues. The Accessibility Foundation’s 2023 research found that automated testing detects roughly 30-40% of WCAG conformance failures. The remaining 60-70% require human judgment.

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