Screen Reader Testing: How to Check Your Website Works for Blind Users

Screen readers are software applications that convert on-screen content to synthesised speech or braille output, enabling blind and visually impaired users to navigate the web using keyboard commands. Around 2% of the UK population is blind or has severe visual impairment, and a much larger number uses screen readers as a result of other disabilities. Building a website that works with screen readers is both an ethical commitment and a legal requirement under the Equality Act.

Testing with a real screen reader reveals issues that automated tools can’t detect — confusing reading order, unlabelled buttons, inaccessible modal dialogs, and navigation patterns that make sense visually but become bewildering when read aloud. This guide introduces the two most widely used screen readers and gives you a practical testing routine to follow.

The Two Main Screen Readers: VoiceOver and NVDA

VoiceOver is built into Apple devices — Mac, iPhone, and iPad. On a Mac, activate it with Command + F5. It works with Safari (Apple’s preferred browser for VoiceOver compatibility) and is the most widely used screen reader on mobile. NVDA (NonVisual Desktop Access) is a free, open-source screen reader for Windows, used by approximately 41% of screen reader users according to the WebAIM Screen Reader User Survey. It works best with Firefox or Chrome. JAWS is the most widely used screen reader in enterprise environments but costs several hundred pounds per year — for most web developers, NVDA is the practical testing tool.

Both screen readers work differently from normal browsing. Users navigate using keyboard shortcuts to jump between headings (H key), links (K key), form elements (F key), and landmarks (D key). They rarely read a page from top to bottom — they scan by structural elements. This is why heading structure, landmark regions (<nav>, <main>, <header>, <footer>), and descriptive link text are so critical for screen reader usability.

A Practical Screen Reader Testing Routine

When testing a page with a screen reader, work through this checklist: Start at the top of the page and listen to the first few elements announced — does the page title, skip link (to bypass navigation), and top heading make sense? Navigate by headings only (H key in NVDA) — does the heading structure create a meaningful outline of the page content? Navigate by links (K key) — are link texts descriptive in isolation ("Download our price list PDF") or vague ("Click here", "Read more")? Tab through interactive elements — are all buttons, form fields, and links reachable by keyboard? Are they labelled correctly?

Test form submission carefully. When a form has errors, does the screen reader announce which fields failed and why? Is focus moved to the error message or the first failing field? Test modals and popups — when a modal opens, is focus moved into it? When it closes, is focus returned to the triggering element? These interactive patterns are where most screen reader issues cluster on modern websites.

Common Issues Found in Screen Reader Testing

The most frequently discovered problems: Icon-only buttons with no accessible label — a button that shows only a magnifying glass icon with no aria-label="Search" is announced as "button" with no context. Images without alt text — decorative images should have alt="" so the screen reader skips them; meaningful images need descriptive alt text. Poor form labels — form fields must have associated <label> elements or aria-labelledby attributes; placeholder text alone is not a label. Custom interactive components — carousels, accordions, tabs, and dropdowns built with div elements rather than semantic HTML require ARIA roles and properties to communicate their state to screen readers.

Links that open in new tabs are another common issue — screen readers don’t always announce this automatically. Adding a visually hidden "(opens in new tab)" span, or an aria-label that includes this information, prevents confusion when the user’s browser history behaves unexpectedly. At Xpose, we include screen reader testing in our quality assurance process for all site launches, alongside automated accessibility checking.