Accessibility & Standards

Screen Reader

Definition

A screen reader does not look at pixels. It reads the accessibility tree the browser builds from your HTML, and announces each item as a name, a role, a value and a state — 'Contact us, link', 'Email, edit, required'. Users rarely listen top to bottom. They navigate by element type: H for the next heading, D for the next landmark in NVDA, a rotor gesture in VoiceOver, an elements list that filters every link or form field on the page. Reading web content happens in a virtual buffer, often called browse mode, and typing into a field switches to focus mode where keystrokes go to the control instead. The common desktop and mobile options are JAWS and NVDA on Windows, Narrator built into Windows, VoiceOver on macOS and iOS, and TalkBack on Android.

Why It Matters

WebAIM's screen reader user survey, now in its tenth round, puts JAWS and NVDA each at roughly four users in ten, with VoiceOver around one in ten — so testing against a single product tests roughly half your audience. The same surveys find headings are the first tool people reach for on an unfamiliar page, ahead of landmarks and the browser find command. That is why structure beats decoration here: a page of styled div elements offers nothing to jump to, and a page with a sensible h1 to h3 outline can be scanned in seconds. It is also why an unnamed control is worse than an ugly one. 'Button, button, button' gives a listener no way to choose, and they either guess or leave.

How It Works

The browser exposes the accessibility tree through a platform API — UI Automation or IAccessible2 on Windows, NSAccessibility on macOS — and the screen reader queries it and keeps a linear buffer of the page. Changes matter: content inserted by script is picked up when the buffer refreshes, but nothing is spoken unless it is inside a live region or the focus is moved there deliberately. Elements hidden with display of none or the hidden attribute are absent from the tree; elements moved off-screen with CSS are still in it and still read. aria-hidden removes a subtree from the tree while leaving it visible and, dangerously, still focusable. Braille output follows the same tree, one line at a time, which is why very long labels are worse on braille than in speech.

Real-World Example

A candidate publishes a CV as one HTML file at j-okafor-cv.99helpers.site. Listening to it with NVDA takes four minutes because the whole thing is div elements with font sizes, so there are no headings to jump between. Marking the name as h1, each role as h2 and each employer line as ordinary text gives seven headings, and the same page is scannable in about twenty seconds. Nothing visual changes. 99helpers serves the file exactly as uploaded and runs no audit of its own, so the listening test is something you do locally before you publish.

Common Mistakes

  • Testing with the screen reader you already have and stopping there — JAWS and NVDA differ in how they announce ARIA, and a control that works in one can be silent in the other
  • Hiding something with aria-hidden while leaving it focusable — a keyboard user tabs into an element the screen reader refuses to name
  • Assuming injected content is announced — a message added by script is read only if focus moves to it or it sits in a live region

Related Terms

Put a file online in seconds

Drop in a document, an image, a page or a whole static website and share the link — free, with no build step and no server to set up.

Host a file free →