Screen Readers and Assistive Technology Basics

A screen reader is software that turns the visible page into spoken audio, in real time, so a user who cannot see the screen can still navigate, read, and interact. For a sighted tester, even five minutes with a screen reader is the single most eye-opening exercise in accessibility — it converts every abstract WCAG rule into a vivid, audible experience. This lesson teaches you what screen readers do, how to fire one up, and what to listen for when you test with one.

What a screen reader actually does

Screen readers read the rendered page in document order, announcing one element at a time. Users navigate with single-key shortcuts: jump to the next heading (H), the next link (K), the next form field (F), or the next landmark region (D). They do not read every pixel — they read the semantic structure. A <button> is announced as "button"; a <div> styled to look like a button is announced as a generic group with no role. The semantic difference is the entire game.

Screen readers depend on three things from the HTML to do their job well:

• Semantic elements — <nav>, <main>, <button>, <h1>–<h6>. Each one announces its role.
• Accessible names — every interactive element needs a name the screen reader can read aloud (label text, aria-label, alt text). An unlabelled icon button is read as just "button," with no clue what it does.
• Logical DOM order — the order the screen reader reads in is the order elements appear in the DOM, not the order they appear visually. CSS that reorders content visually but leaves the DOM scrambled produces an experience that "looks fine" but reads like a randomised list.

The major screen readers

Every operating system ships with at least one. As a tester, you should know all four by name:

• VoiceOver — built into macOS and iOS. Free, available on every Mac and iPhone. Start it on macOS with Cmd+F5; navigate with Ctrl+Option+Arrow. The fastest way for any tester on a Mac to get started.
• NVDA — Windows, free, open-source. The most common second-opinion screen reader after VoiceOver. Install from nvaccess.org.
• JAWS — Windows, commercial. Despite the licence cost it is the most-used screen reader in enterprise environments, especially in finance, healthcare, and government. If your product targets enterprise customers, you must test on JAWS at least occasionally.
• TalkBack — built into Android. Different keyboard model from desktop screen readers (gesture-driven on touch devices). Test on TalkBack for Android-app-shaped products.

For day-to-day manual testing on a Mac, VoiceOver is the right starting point. The five-minute investment to learn Cmd+F5 and four navigation keys pays back many times over.

What sighted users see vs what screen reader users hear

The single most useful exercise is to imagine the same page from both perspectives. Below is a shortened login form as a sighted user sees it on screen, and as a typical screen reader announces it when navigated by Tab.

The two highlighted rows are the bugs. They are invisible to the sighted user — the page looks perfect — and obvious within seconds to a screen reader user. The fixes are tiny: real <label> elements on the inputs, and an aria-label="Show password" on the eye icon.

Common bugs screen readers catch

Five patterns appear over and over:

• Unlabelled icon buttons. The <svg> looks obvious; the screen reader has nothing to read.
• Filename or missing alt text. "Logo dot png" announced aloud is worse than skipping.
• "Click here" links. Screen reader users often pull a list of all links on the page — fifty "click here" entries are unusable.
• Dynamic content that doesn't announce. A toast appears visually but the screen reader is silent. Fix: aria-live="polite" (or assertive for critical updates).
• Visual vs DOM order. A button in the top-right that is last in the DOM forces users to Tab forty times before they reach it.

You do not need to be an expert

A common worry: "I am not blind — surely my screen reader testing isn't valid." It is. You will not catch every nuance a daily user catches, but you will catch the patterns above the first time you try. The point of running a screen reader once is not to certify your product as accessible — it is to feel viscerally what an inaccessible product is. The first time a screen reader announces "button, button, button, button" on a screen full of unlabelled icons, you will not need anyone to explain why labels matter.

⚠️ Common mistakes

• Listening only to the first sentence and assuming the rest is fine. Most products have one well-handled main heading and a series of broken interactive elements below. Always navigate the full screen, not just the entry point.
• Confusing what you see with what the screen reader announces. They are not the same. A page that looks fully labelled visually can be effectively label-less to a screen reader.
• Treating screen reader testing as a one-time check. Dynamic content, modals, and inline errors are exactly the places screen reader bugs creep back into a product after release. Re-test on every significant change to a flow, not just at launch.

🎯 Practice task

Spend 30 minutes meeting your screen reader for the first time.

1. Turn on VoiceOver on macOS (Cmd+F5) — or NVDA on Windows. Spend the first 5 minutes just tabbing through any familiar website with your eyes open. Listen to what is announced for each element.
2. Now close your eyes for the next 10 minutes and try to complete a single common task — sign in, search for something, read an article — using only the keyboard and the audio. Do not peek.
3. Open your eyes and write down: where did you get stuck? Which elements were confusing? Which were silent? Which were over-announced?
4. Pick the most serious bug you found and write the bug report — title naming the screen reader and OS, repro steps, expected vs actual announcement, and the impact on a real user. This is the chapter's capstone artefact: a bug filed from real assistive-technology testing, of the kind that no automated tool would have ever caught.