Screen Readers — NVDA, JAWS & VoiceOver Guide

DodaTech Updated 2026-06-21 11 min read

In this tutorial, you'll learn about Screen Readers. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.

Screen readers convert digital text into synthesized speech or braille, and testing with them is the only reliable way to know whether your website truly works for blind and low-vision users.

What You'll Learn

By the end of this guide, you will understand the five major screen readers (NVDA, JAWS, VoiceOver, TalkBack, and Orca), know their essential keyboard shortcuts and setup procedures, be able to follow a systematic testing workflow, write HTML that screen readers interpret correctly, create effective alt text for every image type, use ARIA live regions for dynamic announcements, and identify the most common screen reader failures.

Why Screen Reader Testing Matters

Over 285 million people worldwide are blind or have low vision. Screen readers are their primary tool for accessing the web. Automated Accessibility tools catch only about 30 percent of screen reader issues — the remaining 70 percent require testing with actual screen readers. At DodaTech, Doda Browser includes a Screen Reader Preview mode in DevTools that approximates how content is exposed to assistive technologies, helping developers catch common issues during development.

Screen Readers Learning Path

flowchart LR
  A[Accessibility Overview] --> B[WCAG Compliance]
  B --> C[ARIA Guide]
  C --> D[Keyboard Navigation]
  D --> E[Screen Reader Guide]
  E --> F[Accessible Forms]
  E --> G[Accessible Images]
  E:::current

  classDef current fill:#f90,color:#fff,stroke:#333,stroke-width:2px

{{< callout type="info" icon="sparkles" >}} Prerequisites: Familiarity with HTML5 semantics and ARIA basics. Understanding of keyboard navigation. No screen reader experience is required. {{< /callout >}}

Screen Reader Testing Workflow

Step 1: Choose and Install a Primary Screen Reader

For most developers, NVDA is the best starting point — it is free, widely used, and works with all major browsers.

Step 2: Learn the Basics

Practice navigating your own operating system with the screen reader before testing a website. Focus on:

Navigating by heading (H key)
Navigating by landmark (D key)
Activating links and buttons (Enter)
Reading form fields and labels

Step 3: Create a Testing Checklist

## Screen Reader Testing Checklist

### Navigation
- [ ] Can I find the main heading (H1)?
- [ ] Can I navigate through all headings (H1-H6)?
- [ ] Can I find all landmarks (nav, main, footer)?
- [ ] Does the skip link work?
- [ ] Can I navigate by links (K key)?

### Forms
- [ ] Are all form fields announced with clear labels?
- [ ] Are required fields announced as required?
- [ ] Are error messages announced when they appear?
- [ ] Can I submit the form successfully?
- [ ] Is success confirmed after submission?

### Dynamic Content
- [ ] Are content changes announced (aria-live)?
- [ ] Are modal dialogs announced when they open?
- [ ] Is focus moved into modals automatically?
- [ ] Are status messages announced (loading, saving)?

### Images
- [ ] Do informative images have meaningful alt text?
- [ ] Are decorative images properly hidden (alt="")?
- [ ] Do complex images have detailed descriptions?

Step 4: Disable Your Monitor

The single most effective technique: close your eyes or turn off the monitor and try to complete key tasks. If you can navigate, find information, and complete forms without seeing the screen, your site is likely accessible.

Semantic HTML for Screen Readers

Screen readers rely on semantic HTML to convey meaning. Here is how different elements are announced:

<!-- Headings — navigable by level -->
<h1>Page Title</h1>           → "Page Title, heading level 1"
<h2>Section</h2>              → "Section, heading level 2"
<h3>Subsection</h3>           → "Subsection, heading level 3"

<!-- Lists — announced with item count and position -->
<ul>
  <li>Item A</li>             → "List, 3 items" then "Item A, 1 of 3"
  <li>Item B</li>             → "Item B, 2 of 3"
  <li>Item C</li>             → "Item C, 3 of 3"
</ul>

<!-- Links — announced as "link" -->
<a href="/page">Read more</a> → "Read more, link"

<!-- Buttons — announced as "button" -->
<button type="submit">Submit</button> → "Submit, button"

<!-- Landmarks — navigable via Rotor or D key -->
<nav>...</nav>                → "Navigation landmark"
<main>...</main>              → "Main landmark"
<footer>...</footer>          → "Content info landmark"

<!-- Tables — announced with structure -->
<table>
  <caption>Monthly Revenue</caption>
  <tr>
    <th>Month</th>
    <th>Amount</th>
  </tr>
  <tr>
    <td>January</td>
    <td>$5,000</td>
  </tr>
</table>
→ "Table with 2 columns and 2 rows, Monthly Revenue"
→ "January, $5,000"

Alt Text Best Practices

Alt text is the single highest-impact Accessibility improvement you can make:

<!-- Informative image — describe the content and function -->
<img src="chart-q2-2026.png"
     alt="Bar chart showing Q2 2026 revenue: April $120K, May $145K, June $160K">

<!-- Functional image (link) — describe the action -->
<a href="/download">
  <img src="download-icon.SVG" alt="Download quarterly report PDF">
</a>

<!-- Decorative image — hide from screen readers entirely -->
<img src="decorative-border.SVG" alt="" role="presentation">

<!-- Complex image — link to a detailed description -->
<figure>
  <img src="organizational-chart.png"
       alt="DodaTech organizational chart. Full description below."
       aria-describedby="org-desc">
  <figcaption id="org-desc">
    <h3>Organizational Structure</h3>
    <p>CEO: Alex Chen. Direct reports: CTO Sarah Johnson,
       CPO Michael Park, CFO Lisa Wong.</p>
  </figcaption>
</figure>

ARIA Announcements for Dynamic Content

<!-- Shopping cart — announces changes automatically -->
<div aria-live="polite" aria-atomic="true" id="cart-status">
  Cart: 3 items (Total: $45.00)
</div>

<script>
function addToCart(item) {
  // ... update logic ...
  document.getElementById('cart-status').textContent =
    `Cart: ${cart.count} items (Total: $${cart.total.toFixed(2)})`;
}
</script>

<!-- Critical error — interrupts immediately -->
<div role="alert" id="error-message">
  Connection lost. Changes saved locally.
</div>

<!-- Form submission status -->
<div role="status" id="form-status" aria-live="polite">
  <!-- populated after submission -->
</div>

Accessibility Tree Logger

// a11y-tree-logger.js — paste in DevTools console
(function() {
  function logAccessibilityTree(root) {
    const items = [];
    function walk(el) {
      const tag = el.tagName.toLowerCase();
      const role = el.getAttribute('role') || 'implicit';
      const name = el.getAttribute('aria-label') ||
                   el.textContent?.trim()?.substring(0, 40) || '(none)';
      items.push({ element: `<${tag}>`, role, accessibleName: name,
        hidden: el.hasAttribute('aria-hidden'),
        disabled: el.disabled || el.getAttribute('aria-disabled') === 'true',
        tabIndex: el.tabIndex
      });
      [...el.children].forEach(C => { if (C.nodeType === 1) walk(C); });
    }
    walk(root || document.body);
    console.table(items);
  }
  window.logA11yTree = logAccessibilityTree;
  console.log('Usage: logA11yTree(document.querySelector("nav"))');
})();

Expected behavior: The console shows a table with each element's tag, role, accessible name, hidden/disabled State, and tabindex — exactly what screen readers perceive.

Common Screen Reader Failures

1. Missing or Bad Alt Text

Images without alt text cause screen readers to announce the file name: "chart-q2-dot-png." Users have no idea what the image shows.

2. Unlabeled Form Fields

An <input> without a <label> or aria-label is announced as "edit, blank." Users cannot tell what to type.

3. No Heading Structure

Pages without proper heading hierarchy force users to listen to every word. Without headings, users cannot skip to sections.

4. Dynamic Content Not Announced

Content loaded via JavaScript without aria-live is invisible to screen readers. Users never know new content appeared.

5. Unexpected Focus Changes

When a modal opens or content rearranges without moving focus, screen reader users are left disoriented.

6. Custom Widgets Without ARIA

A <div> styled as a tab but missing role="tab", aria-selected, and aria-controls is announced as a generic "div" with no interactive meaning.

7. Auto-Updating Content Without Live Regions

Countdown timers, live feeds, and stock tickers that update without aria-live either are not announced or produce constant noise.

Practice Questions

1. What is the difference between Browse mode and Focus mode in NVDA? Browse mode (default) lets users navigate with arrow keys and quick keys (H, K, D). Focus mode passes keystrokes through to the application, needed for forms and custom widgets. NVDA+Space toggles between them.

2. Why is heading structure important for screen reader users? Screen reader users navigate by headings using the H key or the Rotor. A logical heading structure lets them jump to any section quickly without listening to all content.

3. What is the VoiceOver Rotor and how is it accessed? The Rotor (Ctrl+Option+U on Mac) is a circular menu listing all headings, links, landmarks, form controls, and other elements. Users spin through categories to navigate directly to specific items.

4. Why should you test with the monitor off? It forces you to experience the page as a blind user would. If you can complete tasks — finding information, filling forms, navigating pages — without seeing the screen, your site is genuinely accessible.

5. Challenge: Install NVDA (Windows) or enable VoiceOver (Mac). Navigate a website you built without looking at the screen. Complete three tasks: find the page title, navigate to a specific section, and submit a form. Document every issue.

Real-World Task

Create a screen reader testing protocol for your team. Include a standard testing checklist, instructions for installing NVDA or VoiceOver, and a defect reporting template that captures the exact screen reader output received versus expected output.

FAQ

Which screen reader should I start with? Start with NVDA (free, most widely used on Windows) or VoiceOver (free, built into Mac). For mobile, test with VoiceOver on iOS and TalkBack on Android.

Do I need to learn screen reader shortcuts to test effectively? Yes, at minimum the basics: navigate by headings, links, and landmarks; activate items; and toggle between Browse and Focus modes in NVDA.

How many screen readers should I test with? At minimum, one desktop screen reader (NVDA or VoiceOver) and one mobile screen reader (VoiceOver iOS or TalkBack Android). For government or enterprise projects, add JAWS.

Can the Chrome DevTools Accessibility Tree replace screen reader testing? No. The Accessibility Tree shows what information is exposed to assistive technology, but it cannot tell you how a screen reader processes, prioritizes, or announces that information in practice.

What is the most common screen reader issue developers miss? Dynamic content announcements. Developers forget to add aria-live to regions that update dynamically, so screen reader users never know that new content appeared.

Try It Yourself

Build a screen reader testing helper that logs the Accessibility tree for any selected element:

// inspect-a11y-tree.js
function inspectAccessibilityTree(selector) {
  const el = document.querySelector(selector) || document.body;
  const results = [];

  function analyze(node) {
    const tag = node.tagName.toLowerCase();
    const computedRole = node.getAttribute('role') || 'implicit';
    const accessibleName = node.getAttribute('aria-label') ||
      (node.labels && node.labels[0]?.textContent) ||
      node.textContent?.trim()?.substring(0, 30) || '(none)';
    results.push({
      tag: `<${tag}>`,
      role: computedRole,
      name: accessibleName,
      focusable: node.tabIndex >= 0 || /^(a|button|input|select|textarea)$/i.test(tag),
      ariaHidden: node.getAttribute('aria-hidden') || 'false'
    });
    [...node.children].forEach(child => {
      if (child.nodeType === 1) analyze(child);
    });
  }

  analyze(el);
  console.table(results);
}

// Usage: inspectAccessibilityTree('nav');

Expected output: A console table showing every descendant element's tag, ARIA role, accessible name, focusability, and hidden State.

What's Next

Color Contrast — WCAG Compliance & Tools Guide

Accessible Forms Guide

Accessible Images Guide

Congratulations on completing this Screen Readers guide! Here is where to Go from here:

Practice daily — Navigate one page per day with NVDA or VoiceOver
Build a project — Create a screen reader testing harness for your team
Explore related topics — Learn color contrast next
Join the community — Discuss with other learners and share your progress

Remember: every expert was once a beginner. Keep coding!

← Previous Keyboard Navigation — Accessible Interactions Guide Next → Color Contrast — WCAG Compliance & Tools Guide

Built by the developers of DodaTech

Doda Browser, DodaZIP & Durga Antivirus Pro

Home Browse Accessibility