Skip to main content

Testing Guides

Screen Reader Testing Guide

Screen readers convert page content to synthesized speech or braille output. Testing with a screen reader is the closest you can get to experiencing your site the way a blind or low-vision user does. Automated tools like SweepHound catch structural issues (missing alt text, broken ARIA) but can't evaluate whether your site actually makes sense when read aloud.

Screen readerPlatformCost
VoiceOvermacOS, iOSFree (built-in)
NVDAWindowsFree (open source)
JAWSWindowsPaid ($95/yr or $1,000 perpetual)
TalkBackAndroidFree (built-in)

For web testing, start with VoiceOver (if you're on a Mac) or NVDA (if you're on Windows). Both are free and cover the majority of real-world screen reader usage on desktop.

VoiceOver quick start (macOS)

  • Toggle on/off: Cmd + F5
  • Next element: VO + Right Arrow (VO = Ctrl + Option)
  • Previous element: VO + Left Arrow
  • Activate: VO + Space
  • Read all: VO + A
  • Open rotor (landmarks, headings): VO + U

NVDA quick start (Windows)

  • Toggle on: Ctrl + Alt + N
  • Next element: Tab or Down Arrow
  • List headings: NVDA + F7 (NVDA = Insert or Caps Lock)
  • Next heading: H
  • Next landmark: D
  • Read all: NVDA + Down Arrow

What to test

Focus your screen reader testing on these areas:

  • Heading structure — can you navigate by headings and understand the page hierarchy?
  • Link text — does each link make sense out of context? "Click here" and "Read more" are meaningless to a screen reader user scanning a list of links.
  • Form labels — does every input announce its label? Are error messages associated with inputs?
  • Image alt text — do informative images convey their content? Are decorative images skipped?
  • ARIA landmarks — can you jump to the main content, navigation, and footer?
  • Dynamic content — are notifications, loading states, and live updates announced?

Semantic HTML over ARIA

The first rule of ARIA is: don't use ARIA if you can use native HTML. Screen readers understand semantic elements out of the box:

  • <button> instead of <div onclick>
  • <nav> instead of <div role="navigation">
  • <main> instead of <div role="main">
  • <h1><h6> for logical heading hierarchy

Use ARIA only when native HTML doesn't cover your use case — custom comboboxes, tab panels, tree views. Even then, follow the ARIA Authoring Practices Guide patterns exactly.

ARIA landmarks

Landmarks let screen reader users jump directly to major page sections. Every page should have these:

HTML elementARIA rolePurpose
<header>bannerSite header (logo, primary nav)
<nav>navigationNavigation links
<main>mainPrimary page content
<footer>contentinfoSite footer (legal, secondary nav)

Common screen reader issues

  • "Click here" links — screen reader users often navigate by listing all links on a page. "Click here" repeated 12 times is useless.
  • Unlabeled icon buttons — a hamburger menu icon announced as "button" tells the user nothing. Add aria-label="Open menu".
  • Missing heading hierarchy — jumping from h1 to h4 makes the page structure incomprehensible when navigating by heading.
  • Unannounced dynamic content — toast notifications, loading spinners, and live search results need aria-live regions to be announced.

SweepHound's dual-engine scanner catches many of these structural issues automatically — missing landmarks, broken heading hierarchy, unlabeled buttons, and missing alt text. Try a free scan to flag common structural issues that affect screen reader users on scanned pages.