RatedWithAI

RatedWithAI

Accessibility scanner

Free Scan
Developer GuideTesting

Screen Reader Testing Guide 2026: How to Test Your Website with NVDA, JAWS, and VoiceOver

65.6% of screen reader users rely on NVDA, 60.5% use JAWS, and 43.9% use VoiceOver — most use multiple screen readers. If you're building websites and never testing with one, you're shipping inaccessible code to millions of users. This guide teaches you exactly how to set up, navigate, and test with every major screen reader, step by step.

1,539

Screen reader users surveyed

65.6%

Use NVDA regularly

91.3%

Use mobile screen readers

71.6%

Use 2+ screen readers

1. Why You Need to Test with Screen Readers

Automated accessibility testing tools — including RatedWithAI, axe-core, and Lighthouse — can detect approximately 30-40% of WCAG violations automatically. They excel at catching missing alt text, insufficient color contrast, invalid ARIA attributes, and broken heading hierarchies. But the majority of accessibility issues can only be found by experiencing your site the way screen reader users do.

According to the WebAIM Screen Reader User Survey #10 (December 2023 – January 2024, 1,539 respondents), 89.9% of screen reader users have a disability, with 76.6% reporting blindness as their primary disability. These users navigate entirely by keyboard and audio output — if your site doesn't work without a mouse and without seeing the screen, it doesn't work for them.

Screen reader testing reveals issues that no automated tool can catch:

  • ⚠️Reading order doesn't match visual order — content announced in a confusing sequence
  • ⚠️Alt text is present but meaningless ('image1.jpg', 'photo', 'banner') — technically passes automation, completely fails users
  • ⚠️Custom widgets (dropdowns, date pickers, accordions) look interactive but are completely invisible or inoperable to screen readers
  • ⚠️Dynamic content updates (notifications, form errors, live feeds) happen silently — no ARIA live regions announce them
  • ⚠️Focus management is broken — modals don't trap focus, page transitions don't reset focus position
  • ⚠️Heading structure is technically valid but semantically wrong — screen readers use headings as the primary way to scan page content
  • ⚠️Form error messages exist visually but aren't programmatically associated with their fields
  • ⚠️Tables are used for layout but announced as data tables, creating a confusing experience

💡 The Developer Reality Check

Turn off your monitor, launch NVDA, and try to complete one task on your website — fill out a form, navigate to a product page, or complete a checkout. If you can't do it in under 3 minutes, neither can your screen reader users. Most developers who try this for the first time are shocked at how broken the experience is.

2. Which Screen Readers to Test With (Data-Driven)

Don't guess — let the data guide your testing priorities. WebAIM's Survey #10 provides the most comprehensive picture of real screen reader usage. Here's what 1,539 actual screen reader users told us:

Primary Desktop Screen Reader Market Share

JAWS40.5%

Freedom Scientific — $90/year or ~$1,000 perpetual

NVDA37.7%

NV Access — Free, open source

VoiceOver9.7%

Apple — Built into macOS/iOS, free

Dolphin SuperNova3.7%

Dolphin — ~$800, UK-based

ZoomText/Fusion2.7%

Freedom Scientific — $699+

Orca2.4%

GNOME — Free, Linux

Narrator0.7%

Microsoft — Built into Windows, free

Regional Differences Matter

Your audience's geography determines which screen reader matters most:

  • 🌍North America: JAWS dominates (55.5% vs. NVDA 24.0%) — enterprise IT departments buy JAWS licenses
  • 🌍Europe: NVDA leads (37.2% vs. JAWS 29.7%) — cost sensitivity and open-source culture
  • 🌍Asia: NVDA dominant (70.8% vs. JAWS 22.9%) — price sensitivity, NVDA's localization support
  • 🌍Africa/Middle East: NVDA overwhelming (69.9% vs. JAWS 23.3%) — free is essential
  • 🌍Australia: JAWS slightly ahead (45.8% vs. NVDA 37.5%)

The Minimum Testing Matrix

✅ Recommended Testing Combinations (covers 90%+ of users)

  • 1.NVDA + Chrome (Windows) — 21.3% of users, free, catches most code issues
  • 2.JAWS + Chrome (Windows) — 24.7% of users, the #1 combination by market share
  • 3.VoiceOver + Safari (macOS) — 7.0% desktop, plus 70.6% of all mobile screen reader users on iOS

If you can only test with one: use NVDA + Chrome. It's free, widely used, and catches the vast majority of issues.

3. NVDA Setup and Testing Guide (Windows, Free)

NVDA (NonVisual Desktop Access) is the best screen reader for developers to start with. It's free, open-source, actively maintained by NV Access, and used regularly by 65.6% of screen reader users. NVDA has two modes you need to understand:

Installation (5 Minutes)

  1. Download from nvaccess.org/download (free, 40MB)
  2. Run the installer → select "Install NVDA on this computer"
  3. On the Welcome dialog:
    • •Check "Use Caps Lock as an NVDA modifier key" — much easier than Insert on laptop keyboards
    • •Uncheck "Start NVDA after I log on" unless you want it running always
  4. Launch NVDA → an icon appears in the system tray
  5. Open Chrome or Firefox and navigate to your site

Understanding Browse Mode vs. Focus Mode

This is the single most important concept in NVDA testing. If you don't understand these two modes, you'll think NVDA is broken:

📖 Browse Mode (Default)

  • • Read and navigate web content
  • • Single-letter shortcuts work (H for heading, K for link)
  • • Arrow keys move through content linearly
  • • Content is presented as a flat text document
  • • You CANNOT type in text fields

✏️ Focus Mode (For Interactions)

  • • Interact with form controls, menus, widgets
  • • Single-letter shortcuts are disabled
  • • Keystrokes go directly to the web page
  • • You CAN type in text fields
  • • Automatically enters when you Tab to a form field

Toggle between modes with NVDA+Space (Insert+Space or CapsLock+Space). NVDA plays a distinctive sound when switching — a low tone for Browse Mode and a high tone for Focus Mode.

Recommended NVDA Settings for Testing

  • ⚙️Speech rate: NVDA Preferences → Settings → Speech → Rate slider. Start at 40-50% speed while learning; experienced testers use 70-80%
  • ⚙️Install Focus Highlight add-on: Red outline = Browse Mode, Blue outline = Focus Mode — essential visual feedback for sighted testers
  • ⚙️Enable Speech Viewer: NVDA menu → Tools → Speech Viewer — shows everything NVDA says in a text window, great for documentation
  • ⚙️Set punctuation level to 'All': NVDA → Settings → Speech → Punctuation/Symbol Level → All — hear symbols that might indicate ARIA roles

⚠️ Critical NVDA Rule

Never use your mouse while testing with NVDA. Screen reader users don't have a mouse. The moment you click somewhere, you've broken the test. Navigate entirely with the keyboard. If you get stuck, press Ctrl to stop speech, then NVDA+Space to ensure you're in Browse Mode, then use Ctrl+Home to return to the top of the page.

4. Essential NVDA Keyboard Shortcuts

The NVDA modifier key (shown as NVDA below) is either Insert or CapsLock, depending on your settings. Single-letter shortcuts only work in Browse Mode.

General Navigation

NVDA + SpaceToggle Browse / Focus Mode — the most important shortcut
↓ / ↑ ArrowMove to next / previous line in Browse Mode
Tab / Shift+TabNext / previous focusable element (links, buttons, form fields)
EnterActivate link or button
NVDA + ↓ ArrowRead from current position to end of page ('say all')
CtrlStop speaking immediately
NVDA + F7Elements list — browse all links, headings, landmarks, and form fields
Ctrl + HomeGo to top of page
NVDA + QQuit NVDA

Quick Navigation Keys (Browse Mode Only)

Press the key to move forward; hold Shift + key to move backward.

HNext heading
1-6Next heading at level 1-6
KNext link
UNext unvisited link
VNext visited link
FNext form field
BNext button
ENext edit field (text input)
TNext table
DNext landmark/region
LNext list
INext list item
GNext graphic (image)
NNext block of text not a link
RNext radio button
XNext checkbox

Table Navigation (Inside a Table)

Ctrl + Alt + → ArrowNext column (move right)
Ctrl + Alt + ← ArrowPrevious column (move left)
Ctrl + Alt + ↓ ArrowNext row (move down)
Ctrl + Alt + ↑ ArrowPrevious row (move up)

5. JAWS Setup and Testing Guide (Windows, Paid)

JAWS (Job Access With Speech) by Freedom Scientific is the most-used primary screen reader at 40.5% market share, especially dominant in North American enterprises (55.5%). JAWS costs $90/year (Home Annual) or approximately $1,000 for a perpetual Professional license — but there's a way to test for free.

Getting JAWS for Testing

  • 💰Free 40-minute mode: Download JAWS from freedomscientific.com — it runs in full-featured demo mode for 40 minutes per restart. Restart your computer (or JAWS) to get another 40 minutes. Sufficient for testing sessions.
  • 💰Home Annual license: $90/year — best option for developers who test regularly
  • 💰Professional license: ~$1,000 one-time — includes enterprise features, network licensing
  • 💰Trial: Contact Freedom Scientific for a full 30-day trial license

JAWS Key Concepts

JAWS works similarly to NVDA but with some important differences:

  • 📌JAWS modifier key is Insert (not configurable to CapsLock like NVDA)
  • 📌Virtual PC Cursor = NVDA's Browse Mode — arrow keys read through content
  • 📌Forms Mode = NVDA's Focus Mode — activated when you press Enter on a form field
  • 📌JAWS is generally better at announcing ARIA roles and states in complex web applications
  • 📌JAWS has built-in verbosity settings: Beginner (most detail) through Advanced (minimal) — set to Beginner for testing
  • 📌JAWS + Chrome is the #1 screen reader/browser combination at 24.7% market share

🔑 JAWS vs. NVDA for Testing: When to Use Each

Use NVDA for initial development and code-level testing — it's stricter about standards compliance and will catch more technical errors. It's also free, so every team member can use it.

Use JAWS for final user-experience validation, especially if your audience includes enterprise or government users. JAWS is more forgiving of non-standard markup (which means something that "works" in JAWS might still fail in NVDA). Test with both to catch the full range of issues.

6. Essential JAWS Keyboard Shortcuts

JAWS shortcuts are similar to NVDA in many cases. The JAWS modifier key is always Insert.

General Navigation

Insert + ↓ ArrowRead from current position ('say all')
Insert + F6Heading list — browse all headings on the page
Insert + F7Links list — browse all links on the page
Insert + F5Form fields list — all form controls
Insert + F3Virtual HTML features — landmarks, headings, links, form fields, buttons, tables
Insert + SpaceToggle Virtual PC Cursor mode
EnterEnter Forms Mode (on a form field)
Numpad +Exit Forms Mode (return to Virtual PC Cursor)
Insert + ZToggle JAWS verbosity level
CtrlStop speech
Insert + F4Quit JAWS

Quick Navigation Keys (Same as NVDA)

JAWS uses the same single-letter navigation keys as NVDA in Virtual PC Cursor mode: H for headings, K for links, F for form fields, T for tables, D for landmarks, B for buttons. Add Shift to move backward.

7. VoiceOver Setup and Testing Guide (macOS/iOS, Free)

VoiceOver is Apple's built-in screen reader, available on macOS, iOS, iPadOS, watchOS, and tvOS. It's free with every Apple device and used regularly by 43.9% of screen reader users. While only 9.7% use it as their primary desktop screen reader, it dominates mobile at 70.6% of all mobile screen reader usage.

macOS Setup (2 Minutes)

  1. Press Cmd + F5 to toggle VoiceOver on/off
  2. The VoiceOver modifier (called VO) is Control + Option
  3. Critical step: Enable full keyboard access in Safari → Preferences → Advanced → Accessibility → check "Press Tab to highlight each item on a webpage"
  4. Use Safari for testing — VoiceOver works best with Safari due to Apple's tight integration
  5. VoiceOver will start narrating everything. Press Ctrl to pause speech at any time

VoiceOver Key Concepts

  • 🍎VO (VoiceOver modifier) = Control + Option — you'll use this with almost every command
  • 🍎Web Rotor (VO+U): The single most powerful VoiceOver feature — opens a heads-up display to browse headings, links, landmarks, form controls, tables, and more. Use Left/Right arrows to switch categories.
  • 🍎Interact (VO+Shift+↓ Arrow): Enters a group or container to navigate its contents — essential for complex layouts, iframes, and web apps
  • 🍎Stop Interacting (VO+Shift+↑ Arrow): Exits the current group — moves up one level in the element hierarchy
  • 🍎Unlike NVDA/JAWS, VoiceOver doesn't have distinct Browse/Focus modes — it uses a single navigation model
  • 🍎VoiceOver with Chrome is not as well-supported as VoiceOver with Safari — always test VoiceOver in Safari

8. Essential VoiceOver Keyboard Shortcuts

VO below means Control + Option. All shortcuts assume macOS with Safari.

Navigation

Cmd + F5Toggle VoiceOver on/off
VO + → / ← ArrowMove to next / previous element
VO + ARead from current position ('read all')
VO + UOpen Web Rotor — browse headings, links, landmarks, forms
VO + Shift + ↓Interact with (enter) a group/container
VO + Shift + ↑Stop interacting (exit group/container)
VO + SpaceActivate (click) the current element
Tab / Shift+TabNext / previous focusable element
CtrlPause/resume speech
VO + HVoiceOver Help menu — lists all available commands
VO + Cmd + HNext heading (add Shift for previous)
VO + Cmd + LNext link (add Shift for previous)
VO + Cmd + JNext form control (add Shift for previous)
VO + Cmd + TNext table (add Shift for previous)

Web Rotor Categories

After pressing VO+U, use Left/Right arrows to switch between:

Headings
Links
Form Controls
Tables
Landmarks
Web Spots
Visited Links
Non-Visited Links
Images

9. Narrator (Windows) and TalkBack (Android) Quick Start

Windows Narrator

While only 0.7% of users rely on Narrator as their primary screen reader, 37.3% use it regularly — often as a quick-check tool. It's built into every Windows installation since Windows 10 and has improved dramatically in recent versions.

  • 🪟Toggle: Windows key + Ctrl + Enter
  • 🪟Narrator key: CapsLock or Insert
  • 🪟Read from cursor: Narrator + ↓ Arrow
  • 🪟Next heading: Narrator + H
  • 🪟Element list: Narrator + F6 (headings), F7 (links)
  • 🪟Best paired with Microsoft Edge for compatibility
  • 🪟Scan Mode: Toggle with CapsLock + Space — similar to NVDA's Browse Mode

Android TalkBack

TalkBack is used by 26.4% of mobile screen reader users. If your site or app serves Android users, TalkBack testing is essential.

  • 🤖Enable: Settings → Accessibility → TalkBack → On
  • 🤖Navigate: Swipe right (next element), swipe left (previous element)
  • 🤖Activate: Double-tap anywhere on screen
  • 🤖Scroll: Two-finger swipe up/down
  • 🤖Reading controls (rotor equivalent): Swipe up/down to change navigation mode (headings, links, characters)
  • 🤖Quick menu: Three-finger tap — access TalkBack settings during testing
  • 🤖Explore by touch: Drag your finger across the screen — TalkBack reads what's under your finger

10. Screen Reader + Browser Pairings That Matter

Not all screen reader and browser combinations work equally well. Testing with the wrong pairing can give you false positives or false negatives. Based on WebAIM Survey #10 real-world usage data:

JAWS + Chrome24.7%
🔴 Must testThe #1 combination. Enterprise standard. Best ARIA support.
NVDA + Chrome21.3%
🔴 Must testFree + widely used. Strict standards compliance. Developer favorite.
JAWS + Edge11.4%
🟡 Should testGrowing as enterprises adopt Edge. Edge = Chromium, similar to Chrome.
NVDA + Firefox10.0%
🟡 Should testSome ARIA features work differently in Firefox. Good diversity testing.
VoiceOver + Safari7.0%
🔴 Must testOnly way to test macOS + the dominant mobile screen reader. Safari-only features.
NVDA + Edge5.0%
🟢 OptionalEdge is Chromium-based; results will mirror NVDA + Chrome in most cases.
JAWS + Firefox2.6%
🟢 OptionalLow usage, declining. Firefox/JAWS combination has some rendering differences.
Orca + Firefox1.9%
🟢 Linux onlyThe primary screen reader for Linux desktop users. Test if Linux audience.

⚠️ Don't Test VoiceOver with Chrome

While VoiceOver technically works with Chrome on macOS, Apple's support for Chrome with VoiceOver is inconsistent. You'll encounter bugs and behaviors that don't represent real user experiences. VoiceOver was designed for Safari — test it in Safari. If you need to test Chrome, use NVDA or JAWS on Windows.

11. Screen Reader Testing Methodology: Step-by-Step

Follow this structured approach for consistent, thorough testing. Each step maps to specific WCAG 2.2 success criteria.

Step 1: First Impression Audit (5 min)

WCAG 1.3.1, 1.3.2, 2.4.1, 2.4.2

  • ☐Load the page and listen to what NVDA announces first — is it the page title? (WCAG 2.4.2)
  • ☐Press D to navigate by landmarks — does the page have main, nav, banner, contentinfo? (WCAG 1.3.1)
  • ☐Check for a 'Skip to main content' link — Tab should hit it first (WCAG 2.4.1)
  • ☐Press Insert+F7 to open the Elements List → Headings tab — is there exactly one H1? Do headings create a logical outline?

Step 2: Navigation Audit (10 min)

WCAG 2.1.1, 2.4.3, 2.4.7

  • ☐Tab through the entire page — does every interactive element receive focus in a logical order? (WCAG 2.4.3)
  • ☐Can you see where focus is? (Check with eyes — WCAG 2.4.7, but also listen to what NVDA announces)
  • ☐Try the main navigation menu — can you expand/collapse dropdowns? Are submenus reachable? (WCAG 2.1.1)
  • ☐Are there any keyboard traps? Tab forward and backward — can you always escape? (WCAG 2.1.2)
  • ☐Interact with any skip links, back-to-top buttons, or in-page anchors

Step 3: Content Audit (10 min)

WCAG 1.1.1, 1.3.1, 1.3.5

  • ☐Press G to navigate between images — does NVDA announce meaningful alt text? (WCAG 1.1.1)
  • ☐For decorative images, NVDA should say nothing — they should have alt="" or role="presentation"
  • ☐Navigate through text content — is the reading order logical? (WCAG 1.3.2)
  • ☐Check lists — are they marked up as <ul>/<ol>? NVDA should announce 'list of X items'
  • ☐Check any data tables — press T to jump to tables, then use Ctrl+Alt+Arrow keys to navigate cells. Are headers announced? (WCAG 1.3.1)

Step 4: Form Audit (15 min)

WCAG 1.3.1, 3.3.1, 3.3.2, 4.1.2

  • ☐Tab to each form field — does NVDA announce the label? Not just 'edit,' but 'Name, edit' or 'Email address, edit' (WCAG 4.1.2)
  • ☐Are required fields announced? NVDA should say 'required' (aria-required='true' or required attribute)
  • ☐Submit a form with errors — are error messages announced? Do they identify which field has the error? (WCAG 3.3.1)
  • ☐Are input purposes identified for autocomplete? (WCAG 1.3.5) — name, email, tel, address fields should have autocomplete attributes
  • ☐Check select dropdowns, checkboxes, radio buttons — can you operate all of them with keyboard only?
  • ☐Test any custom form controls (date pickers, sliders, toggle switches) — these are the most common failure points

Step 5: Interactive Component Audit (10 min)

WCAG 4.1.2, 4.1.3

  • ☐Open any modal/dialog — does focus move into it? Can you Tab within it without focus escaping behind the overlay? (Focus trap)
  • ☐When the modal closes, does focus return to the element that opened it?
  • ☐Test accordions — are they announced as 'expanded' or 'collapsed'? Do they use proper ARIA states?
  • ☐Test tab panels — is the selected tab announced? Can you arrow between tabs and Tab into the panel content?
  • ☐Check any carousels, sliders, or auto-playing content — can you pause, stop, or control them? (WCAG 2.2.2)
  • ☐Dynamic content: trigger content changes (add to cart, loading spinners, notifications) — does NVDA announce the update? (WCAG 4.1.3, aria-live regions)

Step 6: Link and Button Audit (5 min)

WCAG 2.4.4, 4.1.2

  • ☐Press Insert+F7 → Links tab — read the link list. Do links make sense out of context? (No 'click here,' 'read more,' 'learn more') (WCAG 2.4.4)
  • ☐Check that links are links (<a>) and buttons are buttons (<button>) — NVDA should announce the correct role (WCAG 4.1.2)
  • ☐Are icon-only buttons labeled? An icon button with no text should have aria-label or visually hidden text
  • ☐External links — are they indicated? Users should know when a link opens in a new window

12. 15 Common Issues Screen Reader Testing Reveals

These are the issues you'll find most frequently when testing real websites. Each one fails at least one WCAG 2.2 success criterion and directly impacts usability.

#1

Missing or meaningless alt text

WCAG 1.1.1

What you'll hear: NVDA announces 'graphic' with no description, or reads the filename: 'IMG_3847.jpg'

Fix: Add descriptive alt text: alt="Team reviewing accessibility audit results." For decorative images, use alt="".

#2

Broken heading hierarchy

WCAG 1.3.1

What you'll hear: Page jumps from H1 to H3, or uses headings for visual styling (making a paragraph H2 because it 'looks right')

Fix: Ensure headings are sequential (H1→H2→H3). Use CSS for styling; headings are for document structure.

#3

Unlabeled form fields

WCAG 4.1.2

What you'll hear: NVDA says 'edit' instead of 'Email address, edit' — users don't know what to type

Fix: Associate labels with for/id attributes, or use aria-label/aria-labelledby on the input.

#4

Keyboard trap in modal

WCAG 2.1.2

What you'll hear: Modal opens, but Tab moves focus behind the overlay to page content underneath

Fix: Trap focus within the modal using JavaScript. On close, return focus to the triggering element.

#5

Layout tables announced as data tables

WCAG 1.3.1

What you'll hear: NVDA says 'table with 3 rows and 2 columns' for a layout that isn't tabular data

Fix: Add role="presentation" to layout tables so screen readers ignore the table structure.

#6

Dynamic content not announced

WCAG 4.1.3

What you'll hear: An error message appears visually after form submission, but NVDA says nothing

Fix: Use aria-live="polite" on the container, or aria-live="assertive" for critical errors. Or use role="alert".

#7

Links that say 'click here' or 'read more'

WCAG 2.4.4

What you'll hear: In the NVDA links list (Insert+F7), you see 20 links all labeled 'Read More' with no context

Fix: Make link text descriptive: 'Read the full accessibility audit report' instead of 'Read more'.

#8

Custom dropdown not operable

WCAG 2.1.1

What you'll hear: A styled select menu opens on click but doesn't respond to arrow keys or keyboard activation

Fix: Use native <select> when possible. For custom dropdowns, implement full ARIA listbox pattern with keyboard support.

#9

Missing skip navigation link

WCAG 2.4.1

What you'll hear: Tab lands on the first nav link, and you must Tab through 50+ navigation items to reach main content

Fix: Add a visually-hidden 'Skip to main content' link as the first focusable element on the page.

#10

Auto-playing video or carousel

WCAG 2.2.2

What you'll hear: Content moves automatically, NVDA tries to read it, and the user can't stop or control it

Fix: No auto-play. If auto-playing content exists, provide visible pause/stop controls that are keyboard accessible.

#11

Icon buttons without labels

WCAG 4.1.2

What you'll hear: NVDA announces 'button' with no label — user has no idea what the button does (hamburger menu, search, close)

Fix: Add aria-label="Menu", aria-label="Search", or visually-hidden text inside the button.

#12

Focus not visible on interactive elements

WCAG 2.4.7

What you'll hear: CSS removes focus outlines (outline: none) without providing an alternative focus indicator

Fix: Never remove focus outlines without a replacement. Use :focus-visible for modern focus indicators.

#13

Data table without headers

WCAG 1.3.1

What you'll hear: NVDA reads table cells without context — you hear 'John Smith' but don't know which column it belongs to

Fix: Use <th> elements for headers with scope="col" or scope="row". For complex tables, use id/headers attributes.

#14

ARIA state not updated

WCAG 4.1.2

What you'll hear: Accordion button says 'collapsed' even after expanding, because aria-expanded isn't toggled

Fix: Toggle aria-expanded="true"/"false" with JavaScript when state changes. Test with screen reader to verify.

#15

iframe without title

WCAG 4.1.2

What you'll hear: NVDA encounters an iframe and announces 'frame' with no description — user doesn't know what it contains

Fix: Add a title attribute to every iframe: <iframe title="YouTube video: How to use our product">

13. Complete Screen Reader Testing Checklist

Use this checklist for every page and feature you test. Each item can be verified with any screen reader (NVDA, JAWS, or VoiceOver).

Page Structure

☐Page has a descriptive <title> that's announced on load
☐Exactly one <h1> that describes the page content
☐Heading levels are sequential — no skipping from H2 to H4
☐ARIA landmarks present: main, navigation, banner, contentinfo
☐Skip-to-main-content link is first focusable element
☐Language is set correctly (lang attribute on <html>)

Navigation

☐All interactive elements reachable by keyboard (Tab key)
☐Tab order matches visual/logical reading order
☐No keyboard traps — can Tab into and out of every component
☐Focus indicator visible on every focusable element
☐Menu items accessible — can expand, navigate, and close with keyboard
☐Focus returns to trigger element when closing dialogs/menus

Images & Media

☐All informational images have descriptive alt text
☐Decorative images have alt="" or role="presentation"
☐Complex images (charts, diagrams) have long descriptions
☐Video has captions and/or transcript
☐Audio-only content has transcript
☐No auto-playing media, or pause/stop control is keyboard accessible

Forms

☐Every input has an associated label (announced by screen reader)
☐Required fields indicated both visually and programmatically (aria-required)
☐Error messages are associated with their fields (aria-describedby)
☐Error messages are announced when they appear (aria-live or role="alert")
☐Input purpose identified for autocomplete (name, email, tel, etc.)
☐Custom controls (date pickers, toggles) fully keyboard operable
☐Form validation errors are specific — 'Email is invalid' not just 'Error'

Links & Buttons

☐Link text descriptive out of context (no 'click here')
☐Links use <a>, buttons use <button> — correct semantic roles
☐Icon-only buttons have aria-label or visually-hidden text
☐New-window links indicated (e.g., 'opens in new tab' in link text)
☐No empty links or buttons (no <a href></a> without content)

Dynamic Content

☐Content updates announced via aria-live regions
☐Loading states communicated (aria-busy='true' or status messages)
☐Modal dialogs trap focus and return focus on close
☐Accordion/disclosure widgets announce expanded/collapsed state
☐Tab panels indicate selected state and are keyboard navigable
☐Toast/notification messages announced (role="alert" or aria-live="assertive")

Tables

☐Data tables have <th> header cells with proper scope
☐Layout tables use role="presentation" to suppress table semantics
☐Complex tables use id/headers attributes for cell-to-header mapping
☐Tables have caption or aria-label describing their purpose
☐Can navigate cells with Ctrl+Alt+Arrow keys (NVDA/JAWS)

14. Automated Testing vs. Screen Reader Testing

Automated tools and screen reader testing are complementary, not interchangeable. Here's what each approach catches — and what it misses.

🤖 Automated Tools Catch

  • ✅Missing alt text (attribute absent)
  • ✅Color contrast ratios below thresholds
  • ✅Invalid ARIA attributes and roles
  • ✅Missing form labels
  • ✅Duplicate IDs
  • ✅Empty links and buttons
  • ✅Missing lang attribute

🧑‍🦯 Screen Reader Testing Catches

  • ✅Alt text that exists but is meaningless
  • ✅Illogical reading order
  • ✅Keyboard traps and focus management issues
  • ✅Custom widget usability
  • ✅Dynamic content not announced
  • ✅Confusing or verbose screen reader output
  • ✅Overall user experience and task completion

🎯 The Optimal Testing Workflow

  1. Automated scan first: Run RatedWithAI or axe-core to catch the low-hanging fruit (30-40% of issues)
  2. Fix automated findings: Resolve all critical and serious issues before manual testing
  3. Screen reader testing: Use NVDA + Chrome to test the full user experience (catches the other 60-70%)
  4. Cross-screen-reader validation: Test critical flows in JAWS + Chrome and VoiceOver + Safari
  5. User testing: If possible, have actual screen reader users test — they'll find nuances that even skilled testers miss

15. Mobile Screen Reader Testing

91.3% of screen reader users access content on mobile devices (WebAIM Survey #10). If you only test on desktop, you're missing the majority of your users' actual experience.

VoiceOver on iOS (70.6% of Mobile Users)

Essential iOS VoiceOver Gestures

  • •Enable: Settings → Accessibility → VoiceOver → On (or triple-click Side Button)
  • •Navigate forward: Swipe right with one finger
  • •Navigate backward: Swipe left with one finger
  • •Activate element: Double-tap anywhere on screen
  • •Scroll: Three-finger swipe up/down
  • •Rotor: Two-finger rotate gesture — changes navigation mode (headings, links, form controls)
  • •Navigate by rotor setting: Swipe up/down with one finger
  • •Read from top: Two-finger swipe up
  • •Stop reading: Two-finger tap
  • •Magic tap: Two-finger double-tap — starts/stops audio or video

TalkBack on Android (26.4% of Mobile Users)

Essential Android TalkBack Gestures

  • •Enable: Settings → Accessibility → TalkBack → On
  • •Navigate forward: Swipe right
  • •Navigate backward: Swipe left
  • •Activate element: Double-tap
  • •Scroll: Two-finger swipe up/down
  • •Reading controls: Swipe up/down to change navigation granularity (characters, words, headings, links)
  • •Context menu: Three-finger tap for global actions
  • •Explore by touch: Drag finger across screen to hear what's under it
  • •Read from top: Swipe down then right in one motion
  • •Stop reading: Two-finger tap

Mobile Testing Priorities

  • 📱Touch target size: Buttons and links should be at least 44×44 CSS pixels (WCAG 2.5.8 Target Size) — small touch targets are the #1 mobile accessibility failure
  • 📱Responsive layout: Does content reflow properly? Horizontal scrolling at 320px viewport breaks screen reader users who rely on linear reading
  • 📱Gesture alternatives: Any custom swipe or pinch interactions must have button alternatives
  • 📱Orientation: Does the site work in both portrait and landscape? (WCAG 1.3.4) — some users mount their phones in fixed orientations
  • 📱Focus management: Tap targets and keyboard focus must match — what you tap and what gets focused should be the same element

16. Frequently Asked Questions

Which screen reader should I use for testing?

For comprehensive coverage, test with at least two screen readers. Start with NVDA (free, Windows) paired with Chrome — the most common screen reader/browser combination used by 21.3% of real users according to WebAIM's 2024 survey. Add VoiceOver with Safari for macOS/iOS testing. If your audience includes enterprise users, test with JAWS and Chrome (the #1 combination at 24.7%). NVDA alone catches approximately 80% of screen reader accessibility issues.

Is NVDA or JAWS better for accessibility testing?

Both are excellent but serve different purposes. NVDA is free, open-source, and ideal for developers — it's precise at catching code-level issues. JAWS ($90/year) is better at simulating the real-world user experience, especially for complex web applications. WebAIM's Survey #10 shows JAWS at 40.5% and NVDA at 37.7% primary usage. Test with both for the broadest coverage, or start with NVDA if budget is a concern.

How often should I test with screen readers?

Test during development (not just before launch). Ideally, test key user flows with a screen reader after every sprint or major feature change. At minimum: test new pages, new forms, new interactive components, and any significant layout changes. Integrate screen reader testing into your QA process alongside automated scanning.

Can automated testing replace screen reader testing?

No. Automated tools catch approximately 30-40% of WCAG issues. Screen reader testing catches the other 60-70% — whether alt text is meaningful, whether reading order is logical, whether custom widgets are usable, and whether the overall experience is navigable. Use automated tools as your first pass, then validate with screen readers.

How long does screen reader testing take?

A focused screen reader test of a single page takes 30-60 minutes. A full audit of a multi-page site takes 2-5 hours, depending on complexity. The first time will be slower as you learn the shortcuts. After practice, you can test a form or component in 10-15 minutes. Start with the most critical user flows: homepage, navigation, primary CTA pages, forms, and checkout.

Do I need to test on mobile screen readers too?

Yes. 91.3% of screen reader users use mobile devices, with VoiceOver on iOS at 70.6% market share. At minimum, test your critical flows with VoiceOver on an iPhone. Focus on touch target sizes (44×44px minimum), responsive reflow, and gesture alternatives.

I'm on Mac — can I test with NVDA?

Not natively. NVDA is Windows-only. Your options: (1) Use VoiceOver + Safari (built into macOS). (2) Install Windows via Parallels, UTM, or Boot Camp and run NVDA there. (3) Use BrowserStack or similar cloud services that provide Windows VMs with screen readers. Option 1 (VoiceOver) is the practical choice for daily testing on Mac.

What if I find too many issues to fix?

Prioritize by impact. Fix these first: (1) keyboard traps that block navigation entirely, (2) unlabeled form fields on critical pages (login, signup, checkout), (3) missing skip navigation, (4) broken heading hierarchy, (5) empty links and buttons. Then work through the rest. Use an automated tool like RatedWithAI to track your progress over time.

Start Your Accessibility Testing with an Automated Scan

Before diving into screen reader testing, get a baseline. RatedWithAI scans your website for WCAG 2.2 violations in seconds — catching the 30-40% of issues that automated tools can detect. Fix those first, then use this guide to test the rest with NVDA, JAWS, or VoiceOver.

Scan Your Website Free →

Related Accessibility Guides

Best Accessibility Testing Tools Compared (2026)

12 tools reviewed — axe-core, WAVE, Lighthouse, Pa11y, and more

ADA Compliance Audit Guide 2026

7-step methodology for comprehensive accessibility audits

WCAG 2.2 Complete Guide

Every success criterion explained with real-world examples

Accessibility Widgets: Do They Actually Work?

Why overlays can't replace proper accessibility testing

Shopify ADA Compliance Guide 2026

Platform-specific accessibility guide for Shopify stores

Email Accessibility Guide 2026

99.89% of emails fail accessibility — how to fix yours

VPAT Guide: Accessibility Conformance Reports

Create VPATs for enterprise and government procurement

Section 508 Compliance Guide

Federal accessibility requirements for government websites

IAAP Certification Guide 2026

CPACC, WAS, and CPWA — study paths, costs, and career impact

Ecommerce Accessibility: ADA Compliance Guide

70% of ADA lawsuits target e-commerce — is your store compliant?

PDF Accessibility Guide 2026

How to make ADA-compliant PDFs — tagged structure, remediation, testing

ADA Compliance Checklist 2026

Step-by-step checklist for website ADA compliance

Sources