Screen Readers — Complete Guide

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

Screen readers convert digital text into speech or braille output, enabling blind and low-vision users to navigate websites, applications, and documents by interpreting the Accessibility tree.

What You'll Learn

• How screen readers interpret web content
• Popular screen readers: NVDA, VoiceOver, JAWS, TalkBack
• How to test your website with a screen reader
• Common screen reader navigation commands
• How semantic HTML improves screen reader experience

Why It Matters

• Over 250 million people worldwide have visual impairments
• Screen readers are the primary tool for blind users to access the web
• Poorly coded sites create frustrating experiences for screen reader users
• Testing with screen readers catches issues automated tools miss

Real-World Use

• A blind user shopping on Amazon using VoiceOver on iPhone
• A low-vision professional using NVDA to read and respond to emails
• A deafblind user accessing content through a braille display
• A developer testing their site with JAWS before a government contract launch

flowchart LR
  A[HTML/CSS/JS] --> B[Browser]
  B --> C[Accessibility Tree]
  C --> D[Screen Reader]
  D --> E[Speech/Braille]
  F[User Input] --> D
  D --> C

How Screen Readers Work

A screen reader is a software application that translates visual information on a screen into non-visual output. It sits between the operating system and the user, intercepting what the computer displays and converting it to speech or braille.

The key concept to understand is the accessibility tree. When a browser renders a web page, it creates both a DOM tree (for visual rendering) and an accessibility tree (for assistive technologies). The accessibility tree strips away purely visual information and exposes semantic structure: headings, landmarks, links, buttons, form controls, and their states and properties.

Screen readers do not read the page visually like a sighted user does. They navigate the accessibility tree, allowing users to jump between headings, read by paragraph, list all links, or navigate through form controls. This is why semantic HTML is so critical — it populates the accessibility tree correctly.

Popular Screen Readers

NVDA (NonVisual Desktop Access): Free and open-source for Windows. The most widely used screen reader for testing because it is free and highly capable. NVDA supports over 30 languages.

JAWS (Job Access With Speech): Paid screen reader for Windows. The most popular in enterprise and government settings. JAWS has a steeper learning curve but offers advanced features like scripting.

VoiceOver: Built into macOS and iOS at no extra cost. No installation required. VoiceOver uses gesture-based navigation on iOS and keyboard shortcuts on macOS.

TalkBack: Built into Android devices. Activated in accessibility settings. Similar to VoiceOver but for the Android ecosystem.

Orca: Free and open-source for Linux desktops. Less common but important for Linux-based workflows.

Code Example: Screen Reader Announcements

<!-- Screen reader announces structure via semantic HTML -->
<header>
    <h1>My Website</h1>
    <nav aria-label="Main">
        <ul>
            <li><a href="/">Home</a></li>
            <li><a href="/products">Products</a></li>
            <li><a href="/contact">Contact</a></li>
        </ul>
    </nav>
</header>

<main>
    <h2>Welcome</h2>
    <p>Explore our collection of handcrafted items.</p>

    <button aria-label="Add to cart: Handcrafted Vase, $45">
        Add to Cart
    </button>
</main>

Expected output: NVDA user presses H to jump between headings, D to jump to landmarks, Tab to move between links and buttons. The screen reader announces "Main navigation, list, 3 items" then "Home link" etc.

Code Example: Live Region for Dynamic Content

<!-- Live regions announce changes without focus movement -->
<div aria-live="polite" aria-atomic="true" id="cart-status">
    Your cart has 3 items.
</div>

<button onclick="updateCart()">Add Item</button>

<script>
function updateCart() {
    const status = document.getElementById('cart-status');
    const count = parseInt(status.textContent.match(/\d+/)[0]) + 1;
    status.textContent = `Your cart has ${count} items.`;
}
</script>

Expected output: When the cart updates, screen readers announce "Your cart has 4 items" automatically without the user needing to navigate to the status element. The aria-live="polite" means the announcement waits until the user is idle.

Code Example: Screen Reader Testing Script

<!-- Test page for screen reader behavior -->
<!DOCTYPE html>
<html lang="en">
<head>
    <title>Screen Reader Test Page</title>
</head>
<body>
    <h1>Screen Reader Test</h1>

    <h2>Heading Level 2</h2>
    <p>This is a paragraph with a <a href="#">link inside</a>.</p>

    <h3>Heading Level 3</h3>
    <ul>
        <li>List item one</li>
        <li>List item two</li>
        <li>List item three</li>
    </ul>

    <form>
        <label for="name">Name:</label>
        <input type="text" id="name" required>

        <fieldset>
            <legend>Shipping Method</legend>
            <label><input type="radio" name="shipping" value="standard"> Standard</label>
            <label><input type="radio" name="shipping" value="express"> Express</label>
        </fieldset>

        <button type="submit">Submit Order</button>
    </form>
</body>
</html>

Expected output: When testing with VoiceOver on macOS, press VO+U to open the rotor and see a list of headings, links, and form controls. The screen reader announces "heading level 1" then "heading level 2" etc. Form inputs announce their labels automatically.

Common Mistakes

1. Missing or incorrect heading hierarchy — Screen reader users navigate by headings. Skipping from h1 to h4 or using headings only for visual styling destroys navigation.
2. Images without alt text — The screen reader reads the filename when alt text is missing. "Image, IMG_20250628.jpg" is meaningless.
3. Using CSS to hide content versus actual hiding — display: none removes from accessibility tree. visibility: hidden also removes it. Use aria-hidden="true" for decorative content.
4. Auto-playing media — Screen readers mix their speech with media audio, making both incomprehensible.
5. Custom elements without proper ARIA — A div styled as a dropdown menu needs role="listbox", aria-expanded, and keyboard handling.
6. Relying on mouse-only interactions — Screen reader users navigate with keyboard shortcuts. Every interaction must be keyboard accessible.
7. Not testing with an actual screen reader — Simulators and automated tools do not catch speech output issues, context problems, or confusing navigation flows.

Practice Questions

1. What is the accessibility tree and how is it different from the DOM tree? The accessibility tree is a subset of the DOM that exposes only semantic information to assistive technologies, stripping away purely visual elements.
2. Name three popular screen readers and which operating systems they work on. NVDA (Windows), VoiceOver (macOS/iOS), TalkBack (Android).
3. What does the aria-live attribute do and when would you use it? It tells screen readers to announce changes in dynamic content. Use aria-live="polite" for updates that should not interrupt the current task.
4. Why is heading hierarchy important for screen reader users? Screen reader users navigate by jumping between headings using keyboard shortcuts. A logical hierarchy (h1, h2, h3) creates a navigable outline of the page.
5. Challenge: Install NVDA (Windows) or enable VoiceOver (Mac) and navigate a popular website without looking at the screen. Document three accessibility issues you encounter.

FAQ

Mini Project

Create a product listing page with at least 5 products. Each product should have a name, price, description, image, and an "Add to Cart" button. Ensure the page is fully screen reader accessible by using proper heading hierarchy, alt text, form labels, and ARIA landmarks. Test with VoiceOver or NVDA and fix any issues you find. Write a brief report describing what you tested and what changes you made.

What's Next

Continue with Lesson 4: Keyboard Accessibility to understand how users who cannot use a mouse navigate web interfaces.