Testing With Screen Readers — Systematic Testing Workflow and Checklist

In this tutorial, you will learn about Testing With Screen Readers. We cover key concepts, practical examples, and best practices to help you master this topic.

Systematic screen reader testing workflow with a comprehensive checklist for testing navigation, forms, dynamic content, and ARIA widgets across multiple screen readers.

In this tutorial, you'll learn a repeatable Screen Readers testing process.

What You'll Learn

By the end of this lesson, you'll have a systematic testing workflow, a comprehensive checklist, and a bug reporting template for screen reader issues.

Why It Matters

Systematic testing catches more issues than ad-hoc testing. A repeatable process ensures you do not miss critical accessibility problems.

Real-World Use

DodaTech's QA team uses this systematic workflow for every release, ensuring consistent accessibility across all products.

Testing Workflow

flowchart TD
  A[1. Automated scan] --> B[2. Keyboard audit]
  B --> C[3. Screen reader: NVDA]
  C --> D[4. Screen reader: VoiceOver]
  D --> E[5. Dynamic content test]
  E --> F[6. Mobile screen reader]
  F --> G[7. Bug reporting]
  G --> H[8. Regression test]
  H --> B

Step-by-Step Testing Process

Step 1: Automated Scan

Run axe-core, WAVE, or Lighthouse to catch obvious issues.

Step 2: Keyboard Audit

Navigate the entire page with Tab, Shift+Tab, Enter, Escape, and arrow keys.

Step 3: NVDA Testing

Test with NVDA on Windows Firefox/Chrome. Use browse mode and focus mode.

Step 4: VoiceOver Testing

Test with VoiceOver on macOS Safari. Use the Rotor.

Step 5: Dynamic Content

Test live regions, modal dialogs, and AJAX updates.

Step 6: Mobile Testing

Test with VoiceOver on iOS Safari and TalkBack on Android Chrome.

Comprehensive Testing Checklist

## Screen Reader Testing Checklist

### Page Structure
- [ ] Page title is descriptive
- [ ] Heading hierarchy is logical (h1, h2, h3)
- [ ] Landmarks are present and labeled
- [ ] Content reads in logical order

### Navigation
- [ ] Skip link is available
- [ ] Tab order follows visual order
- [ ] All links have descriptive text
- [ ] All interactive elements are focusable

### Forms
- [ ] All inputs have labels
- [ ] Required fields are marked
- [ ] Error messages are linked and announced
- [ ] Auto complete / suggestions are accessible

### Dynamic Content
- [ ] Loading states are announced
- [ ] Error messages are announced
- [ ] Content updates are announced via live regions
- [ ] Modal dialogs trap focus

### ARIA
- [ ] Roles match behavior
- [ ] States update with interaction
- [ ] aria-live regions work
- [ ] aria-expanded syncs with visibility

Bug Reporting Template

### Bug Report: [Screen Reader Name] - [Issue Description]

**Screen Reader**: NVDA 2024.x
**Browser**: Firefox 130
**URL**: https://example.com/page

**Steps to Reproduce**:
1. Open URL
2. Press Tab 3 times
3. Press Enter

**Expected**: "Start scan button announced"
**Actual**: "Start scan image announced"

**ARIA/HTML**:
```html
<div role="button" tabindex="0" onclick="scan()">
  <img src="scan-icon.png" />
</div>

Suggested Fix: Add aria-label="Start scan" to the div or replace img with text.

## Common Mistakes

- **Testing with only one screen reader**: Each screen reader has unique behavior.
- **Not testing keyboard navigation first**: Screen reader issues often stem from keyboard issues.
- **Skipping mobile testing**: Mobile screen readers have different interaction patterns.
- **Not testing dynamic content**: Live region issues are only visible during actual updates.
- **Not documenting exact screen reader and version**: Behavior varies across versions.

## Practice and Challenge

**1. What is the first step in the testing workflow?**
Automated scan with tools like axe-core or WAVE.

**2. Why test keyboard navigation before screen readers?**
Screen reader navigation depends on keyboard accessibility.

**3. How many screen readers should you test with?**
At least NVDA and VoiceOver as a minimum.

**4. What should every bug report include?**
Screen reader, browser, URL, steps, expected vs actual, and a suggested fix.

**5. Challenge**: Run the full testing workflow on your website. Create a bug report for each issue found.

## FAQ

<details style="margin-bottom:12px;border:1px solid #e2e8f0;border-radius:10px;overflow:hidden"><summary style="cursor:pointer;padding:14px 18px;font-weight:600;font-size:1.05rem;background:#f8fafc;border-bottom:1px solid #e2e8f0;color:#1e293b">How often should I test with screen readers?</summary><div style="padding:14px 18px;color:#475569;line-height:1.7;background:#fff"><p>Every release, and whenever significant UI changes are made.</p>
</div></details>

<details style="margin-bottom:12px;border:1px solid #e2e8f0;border-radius:10px;overflow:hidden"><summary style="cursor:pointer;padding:14px 18px;font-weight:600;font-size:1.05rem;background:#f8fafc;border-bottom:1px solid #e2e8f0;color:#1e293b">Can I automate screen reader testing?</summary><div style="padding:14px 18px;color:#475569;line-height:1.7;background:#fff"><p>Some aspects can be automated with tools like axe-core, but manual testing is essential for 70% of issues.</p>
</div></details>

<details style="margin-bottom:12px;border:1px solid #e2e8f0;border-radius:10px;overflow:hidden"><summary style="cursor:pointer;padding:14px 18px;font-weight:600;font-size:1.05rem;background:#f8fafc;border-bottom:1px solid #e2e8f0;color:#1e293b">Which screen reader should I test with first?</summary><div style="padding:14px 18px;color:#475569;line-height:1.7;background:#fff"><p>NVDA is a good starting point because it is free and widely used.</p>
</div></details>

<details style="margin-bottom:12px;border:1px solid #e2e8f0;border-radius:10px;overflow:hidden"><summary style="cursor:pointer;padding:14px 18px;font-weight:600;font-size:1.05rem;background:#f8fafc;border-bottom:1px solid #e2e8f0;color:#1e293b">How long does a full screen reader audit take?</summary><div style="padding:14px 18px;color:#475569;line-height:1.7;background:#fff"><p>For a standard page, 30-60 minutes. For complex applications, several hours.</p>
</div></details>

<details style="margin-bottom:12px;border:1px solid #e2e8f0;border-radius:10px;overflow:hidden"><summary style="cursor:pointer;padding:14px 18px;font-weight:600;font-size:1.05rem;background:#f8fafc;border-bottom:1px solid #e2e8f0;color:#1e293b">Should I test with screen readers during development?</summary><div style="padding:14px 18px;color:#475569;line-height:1.7;background:#fff"><p>Yes. Testing early catches issues before they reach QA.</p>
</div></details>

## Mini Project

Create a screen reader testing protocol for your team. Include the testing checklist, bug report template, and instructions for setting up NVDA and VoiceOver. Run the protocol on your website.

## What's Next

This completes the Screen Readers series. Continue to Keyboard Navigation to learn about keyboard accessibility fundamentals.