Screen Reader

What is a screen reader?

A screen reader is software that reads digital content aloud or sends it to a braille display. It allows people who are blind or have severe low vision to use websites, apps, and documents. Screen readers are also used by people with dyslexia and other reading difficulties.^[1]

How do screen readers work on websites?

A screen reader does not "see" the visual layout of a page. Instead, it reads the Accessibility Tree — a structured map that the browser builds from the HTML code and ARIA attributes. This means fonts, colors, and layout do not matter to a screen reader. What matters is clean HTML, correct heading levels, and accurate ARIA markup.

Screen reader users navigate differently from sighted users:

• Headings — Users jump between H1, H2, and H3 elements to scan the page, much like sighted users scan visually. Clear heading structure is essential.
• Tab key — Pressing Tab moves focus between links, buttons, and form fields. The screen reader announces each element's name, role, and state.
• Landmarks — Users jump to page regions like navigation, main content, and footer using keyboard shortcuts.
• Forms mode — When entering a form or interactive widget, the screen reader switches to a mode that passes keys to the application rather than using them for navigation.

Which screen readers do people use?

Several screen readers are in wide use, each with its own behavior:

• JAWS — The most common screen reader in corporate settings, especially on Windows. It is commercial software with a significant license cost.^[2]
• NVDA — A free, open-source Windows screen reader. Widely used for testing because it is free and predictable.
• VoiceOver — Built into every Apple device at no extra cost. It is the main screen reader on iPhone and Mac.
• TalkBack — Built into Android devices. Uses swipe gestures instead of a keyboard.
• Narrator — Built into Windows. Less common in professional testing but relevant as a default option.

According to the WebAIM 2024 Screen Reader User Survey, JAWS and NVDA together account for over 70% of desktop screen reader usage.^[2]

Why does screen reader testing matter?

Automated accessibility tools can find structural issues — missing alt text, empty buttons, low color contrast. But they cannot tell you whether a page actually makes sense when read aloud. Only screen reader testing reveals problems like:

• Confusing reading order on complex layouts
• Custom menus that cannot be operated by keyboard
• Dynamic content updates (like search results) that are never announced
• PDFs with no text layer, which sound completely empty
• Keyboard traps that prevent users from leaving a widget^[3]

IT teams should test with at least two screen reader and browser combinations. The most common pairings are NVDA with Chrome or Firefox on Windows, and VoiceOver with Safari on Mac and iOS.

What happens when a site is not screen reader friendly?

When a website is not built for screen readers, the problems go beyond inconvenience. Users cannot complete tasks at all. A government form without proper labels is impossible to fill in. A banking portal with unlabeled buttons blocks users from managing their accounts. An e-commerce checkout with a keyboard trap stops the purchase entirely.

For organizations with high-traffic, regulated websites — healthcare providers, insurers, universities, government agencies — these failures are both a user experience problem and a legal risk. Accessibility laws in the EU, UK, and US treat screen reader access as a core requirement, not an optional extra.

How Askem Helps

The structural issues that most commonly break screen reader compatibility — missing alt text, empty or unlabeled buttons, incorrect ARIA roles, and missing form labels — can be caught by automated scanning tools. For large regulated sites where new pages and components are added regularly, continuous scanning catches problems before they reach users. Tools like Askem provide a clear list of affected pages and the specific WCAG criteria involved, making it straightforward to hand findings to the developer responsible for a fix. No installation or scripts are needed on the site being monitored.

Sources

1. W3C WAI — How People with Disabilities Use the Web — Blindness: https://www.w3.org/WAI/people-use-web/user-stories/
2. WebAIM — Screen Reader User Survey: https://webaim.org/projects/screenreadersurvey10/
3. W3C WAI — Involving Users in Evaluating Web Accessibility: https://www.w3.org/WAI/test-evaluate/involving-users/