Screen Reader – Making Digital Content Audible and Accessible for Blind and Visually Impaired Users

How a Screen Reader Works

A screen reader differs fundamentally from a simple text-to-speech application: it does not merely read text aloud but interprets the complete structure of a web page and makes all content and elements navigable. Rather than processing the visual display, a screen reader accesses the browser's accessibility tree via accessibility APIs – a structured representation of all accessible elements on a page. These APIs (for example Microsoft UI Automation on Windows, NSAccessibility on macOS) give the screen reader access to the roles, names, states and descriptions of all elements, enabling reliable output of digital content.

A screen reader's primary output is speech synthesis: a text-to-speech engine converts all captured content into spoken language. Blind users adjust speed, voice and volume to their individual preferences – experienced screen reader users often work at very high speaking speeds that are barely intelligible to others. Optionally, a screen reader also outputs content via a Braille display, which renders text tactilely in Braille – particularly essential for deafblind users.

Screen reader users experience web content non-linearly. They navigate using different modes: in heading mode, the screen reader jumps from heading to heading – blind users can quickly discover which sections a page contains. In link mode, all links are listed. In landmark mode, the screen reader jumps directly to semantic areas such as nav, main or footer. In form mode, users encounter form fields and their labels. All of these navigation modes require correct semantic markup of the page's elements.

• ✓ Speech synthesis: Text, headings and interactive elements are converted to spoken language; users adjust speech rate and voice to their individual needs and experience level
• ✓ Braille display (optional): Screen readers can output content tactilely on a Braille display – particularly for deafblind users this is the preferred output method
• ✓ Accessibility APIs: Screen readers do not read the visual display but access the accessibility tree via APIs (Windows: UI Automation, Apple: NSAccessibility)
• ✓ Structural navigation: Users navigate via keyboard through headings, links, landmarks and form elements – each navigation method requires correct semantic markup of the relevant elements
• ✓ Status announcements: Screen readers announce states and changes, for example when a menu opens, a loading process completes or an error occurs in a form field
• ✓ Customisability: Users configure speech rate, voice, verbosity and keyboard shortcuts individually – experienced screen reader users often work at speeds unintelligible to sighted listeners

JAWS, NVDA, VoiceOver and TalkBack: Screen Readers for Different Platforms and Devices

Screen readers are available for different operating systems, devices and use cases. Blind and visually impaired users rely on different screen reader solutions depending on their device and operating system. They vary in functionality, licence model and navigation, but all pursue the same goal: making digital content accessible for everyone and providing access to the digital world.

• ✓ JAWS – Job Access With Speech (Windows): The world's most widely used commercial screen reader for Windows. JAWS offers extensive configuration options, supports numerous applications and Braille displays, and is frequently used in professional and educational settings. Blind users gain full access to Windows applications and websites through JAWS.
• ✓ NVDA – NonVisual Desktop Access (Windows): A free, open-source screen reader for Windows. NVDA is powerful, regularly updated, supports many languages and Braille displays, and gives blind users worldwide access to digital content without licence costs. Developers most efficiently test screen reader compatibility using NVDA with Chrome.
• ✓ VoiceOver (Apple – macOS, iOS, iPadOS): The built-in screen reader on all Apple devices. VoiceOver enables blind and visually impaired users to fully operate iPhones, iPads and Mac computers via speech synthesis, keyboard shortcuts and touch gestures. VoiceOver is available immediately on all Apple devices without installation and is the world's most widely used mobile screen reader.
• ✓ TalkBack (Android): The built-in screen reader for Android smartphones and tablets. TalkBack enables full operation of Android devices via speech synthesis and gestures and comes pre-installed on all modern Android devices. TalkBack makes mobile applications and websites accessible for blind users in everyday life.
• ✓ Other screen readers: Narrator is built into Windows and provides basic screen reader functionality. Orca is an open-source screen reader for Linux desktop computers. ChromeVox is a screen reader extension for the Chrome browser, particularly common on Chromebook devices in education.

Desktop screen readers such as JAWS and NVDA for Windows computers or VoiceOver for macOS are primarily used by users who work at a computer and require full access to all applications and websites. Mobile screen readers such as VoiceOver on iOS and TalkBack on Android enable independent smartphone operation – a key factor for the digital participation of blind people in daily life. Websites must work reliably with different screen readers across different devices: a truly accessible web offer functions correctly regardless of which screen reader or platform a user chooses.

What Websites Need for Screen Reader Compatibility

For screen readers to correctly read out digital content and make it navigable for blind users, websites must be technically well-built. A screen reader reads only what is present in the HTML code – not what is visually displayed. Incorrect or missing semantic markup means that blind users cannot experience or navigate content. The requirements can be summarised in a few key points:

• ✓ Semantic HTML elements: nav, main, header, footer, article and section inform the screen reader about the role and structure of each page area; a generic div element, by contrast, is meaningless to a screen reader – see Semantic HTML
• ✓ Clear heading hierarchy: h1 through h6 structure content for screen reader navigation; blind users navigate via headings – missing or skipped heading levels make it impossible for screen reader users to efficiently experience content
• ✓ Alternative texts for images: All informative images require meaningful alt texts; screen readers read the alt text aloud – without an alt text, blind users cannot experience what the image shows; see Alternative Text
• ✓ Labelled form elements: Every form field requires an associated label element; the screen reader reads the label when users focus the field – missing labels make forms unusable for blind users
• ✓ Full keyboard operability: Screen reader users navigate exclusively by keyboard; all interactive elements – links, buttons, form fields – must be reachable via Tab and operable via Enter or Space; see Keyboard Accessibility
• ✓ ARIA attributes where needed: When native HTML elements are insufficient, ARIA attributes (aria-label, aria-expanded, aria-live) supplement missing information for screen readers; ARIA is always a last resort after native semantic elements

The technical requirements for screen reader compatibility are defined in the WCAG. WCAG 2.1 Level AA has been legally mandatory for many businesses across the EU under the EAA since 28 June 2025. Websites that fail to meet these requirements cannot be fully used by screen reader users – and are in breach of applicable law.

Screen Readers and Headings: Navigating Web Content

Heading navigation is one of the most frequently used features when operating a screen reader. Blind and visually impaired users can jump directly from heading to heading, retrieve a list of all headings on a page, and navigate straight to a specific section – similar to how sighted users visually scan a page. This requires headings to be correctly marked up as h1 through h6 in the HTML code, not merely styled visually via CSS to appear large.

Beyond headings, screen reader users rely on further navigation methods that all require correct semantic markup:

• ✓ Heading navigation: Screen readers list all h1 through h6 headings; users jump from heading to heading and can quickly experience the structure of content-rich pages
• ✓ Landmark navigation: Semantic elements such as nav, main and aside are recognised by screen readers as landmarks; users jump directly to navigation, main content or complementary content
• ✓ Link list: Screen readers can list all links on a page; meaningful link text is essential – "click here" is meaningless to blind users without context
• ✓ Form mode: Screen readers switch to form mode when users focus a form field; correct label elements provide the screen reader with the field's description
• ✓ Skip links: Skip links allow screen reader users to bypass repeated navigation elements and jump directly to the main content – one of the most important measures for efficient screen reader navigation

Websites optimised for screen readers benefit doubly: they provide access for blind and visually impaired users and simultaneously rank better in search engines. Semantically clean content, clear heading structures and alternative texts for images are advantageous both for screen readers and for search engine crawlers. Accessibility and SEO share the same goal: making content structured, understandable and accessible.

Frequently Asked Questions about Screen Readers