How Screen Readers Work — Accessibility Tree, Browse Mode and Focus Mode

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

Screen readers work by accessing the browser's accessibility tree and converting it to speech, using browse mode for document navigation and focus mode for interactive element control.

In this tutorial, you'll learn the technical underpinnings of Screen Readers.

What You'll Learn

By the end of this lesson, you'll understand the accessibility tree, the difference between browse mode and focus mode, and how ARIA attributes affect screen reader output.

Why It Matters

Understanding how screen readers work helps you write code that they will interpret correctly. You will avoid common patterns that break screen reader navigation.

Real-World Use

Doda Browser's accessibility panel shows the accessibility tree directly, helping developers see what screen readers perceive.

Screen Reader Architecture

flowchart LR
  A[HTML/CSS] --> B[DOM Tree]
  B --> C[Accessibility Tree]
  D[ARIA Attributes] --> C
  C --> E[Platform Accessibility API]
  E --> F[Screen Reader Engine]
  F --> G[Speech Synthesizer]
  F --> H[Braille Display]

The Accessibility Tree

Browsers create two trees from web content: the DOM tree and the accessibility tree. The accessibility tree contains only the information that assistive technologies need:

<!-- DOM has everything -->
<div>
  <div aria-hidden="true">Decorative</div>
  <button>Scan</button>
  <div role="alert">Complete</div>
</div>

The accessibility tree contains: button (Scan) and alert (Complete) but not the decorative div.

Browse Mode vs Focus Mode

Screen readers have two primary modes:

Browse mode (also called virtual cursor mode): The user navigates the document with arrow keys, reading by character, word, line, or paragraph. All content is accessible.

Focus mode (also called application mode): The user interacts with form controls and widgets. Keys are passed through to the browser. Tab moves between focusable elements.

<!-- In browse mode: arrow keys read text -->
<!-- In focus mode: Enter/Space activate controls -->
<button>Submit</button>
<input type="text" />

NVDA toggles between modes with NVDA+Space. JAWS toggles with Insert+Z. VoiceOver does not have a browse/focus distinction but uses the Rotor.

How ARIA Affects the Accessibility Tree

<!-- Without ARIA: generic element in accessibility tree -->
<div>Click me</div>

<!-- With ARIA: appears as a button in accessibility tree -->
<div role="button" tabindex="0" aria-pressed="false">Click me</div>

Common Mistakes

• Assuming browse mode is always active: Interactive elements switch to focus mode, changing keyboard behavior.
• Not testing in both modes: Content must be navigable in browse mode; controls must work in focus mode.
• Using CSS display:none vs aria-hidden: display:none removes from both trees; aria-hidden only from accessibility tree.
• Forgetting that screen readers may skip hidden content: Content hidden during initial load may not be discovered.

Practice and Challenge

1. What is the accessibility tree? A parallel tree to the DOM that contains only accessibility-relevant information.

2. What is the difference between browse mode and focus mode? Browse mode is for reading content. Focus mode is for interacting with controls.

3. Which key toggles browse and focus mode in NVDA? NVDA+Space.

4. What happens to the accessibility tree when you set aria-hidden="true"? The element and its descendants are removed from the accessibility tree.

5. Challenge: Open your browser's accessibility inspector (Chrome DevTools or Firefox Accessibility panel) and inspect the accessibility tree of any page.

FAQ

Mini Project

Create a test page with various elements. Open the browser's accessibility inspector and compare the DOM tree to the accessibility tree. Note which elements are present in both.

What's Next

Continue to JAWS to learn about the JAWS screen reader on Windows.