Screen Reader

A screen reader is a software application that interprets what is displayed on a computer or mobile device screen and presents it to the user through synthesized speech or a refreshable braille display. Screen readers are one of the most important categories of assistive technology, enabling people who are blind, visually impaired, or have certain learning disabilities to use computers, browse the web, read documents, and interact with applications. Screen readers work by accessing the operating system's accessibility API, which provides a structured representation of the user interface. On the web, screen readers rely on the browser's accessibility tree — a parallel structure to the DOM (Document Object Model) that contains semantic information about every element on the page. This is why semantic HTML and proper ARIA markup are so critical: they directly determine what information the screen reader can convey to the user. The major screen readers in use today include JAWS (Job Access With Speech) by Freedom Scientific, which dominates the professional and enterprise market; NVDA (NonVisual Desktop Access), a free and open-source screen reader for Windows; VoiceOver, Apple's built-in screen reader available on Mac, iPhone, and iPad; TalkBack, Google's screen reader for Android devices; and Narrator, Microsoft's built-in screen reader for Windows. According to the WebAIM Screen Reader User Survey, JAWS and NVDA together account for roughly 70% of desktop screen reader usage, while VoiceOver dominates on mobile devices. These usage patterns matter for developers because each screen reader has slightly different behaviors and levels of support for various HTML and ARIA features.

Screen readers are essential for digital inclusion. The World Health Organization estimates that at least 2.2 billion people globally have a near or distance vision impairment, with approximately 43 million people who are blind. Without screen reader compatibility, websites and applications are completely inaccessible to these users. From a legal perspective, the Americans with Disabilities Act (ADA) and Section 508 of the Rehabilitation Act require that digital content be accessible. Courts have consistently held that websites must work with screen readers. In the landmark case Robles v. Domino's Pizza (2019), the Ninth Circuit ruled that the ADA applies to websites and that the plaintiff's inability to use the site with a screen reader constituted discrimination. For businesses, screen reader accessibility also means reaching a larger audience. People with disabilities represent over $490 billion in disposable income in the United States alone, according to the American Institutes for Research. A website that does not work with screen readers is losing customers and exposing the business to legal liability. Screen reader compatibility also benefits users beyond those with visual impairments. People with dyslexia, attention disorders, or temporary situational limitations (such as driving or multitasking) often rely on screen reading technology. Building for screen readers generally improves the experience for all users by enforcing good content structure and clear labeling.

When a user opens a web page, the browser parses the HTML and builds both a visual rendering and an accessibility tree. The accessibility tree strips away visual presentation and organizes content into a structured hierarchy of roles, names, states, and relationships. The screen reader reads this tree, not the pixels on the screen. Screen reader users navigate using keyboard commands rather than a mouse. Common navigation methods include: **Reading modes.** Most screen readers have a "browse" or "virtual" mode where arrow keys move through content line by line or element by element, and an "application" or "forms" mode where keyboard input goes directly to interactive controls like form fields. **Heading navigation.** Users press the H key (in JAWS and NVDA) to jump between headings. This is why a proper heading hierarchy (H1, H2, H3) is critical — it serves as a table of contents for screen reader users. **Landmark navigation.** Screen readers can jump between ARIA landmarks and HTML5 sectioning elements like `<nav>`, `<main>`, `<header>`, and `<footer>`. These landmarks let users skip directly to the section they want. **Link lists and form lists.** Users can pull up a list of all links or all form fields on a page, allowing rapid scanning without reading through every line of content. **Tab key navigation.** The Tab key moves between focusable interactive elements: links, buttons, form inputs, and anything with `tabindex`. This is the primary way users interact with controls. For content to be read correctly, every meaningful element needs an accessible name. Images need `alt` text. Form inputs need associated `<label>` elements. Buttons and links need descriptive text content. Icon buttons need `aria-label` attributes. Without these names, the screen reader announces elements as "unlabeled button" or "graphic" — leaving users stranded.

**Good: Properly structured page.** A website uses semantic HTML with a clear heading hierarchy, descriptive alt text on images, labeled form fields, and ARIA landmarks. A screen reader user can navigate by headings to find sections quickly, understands what images depict, and can complete forms independently. **Bad: Image with no alt text.** A product page displays the product name only as an image. Without alt text, the screen reader announces "graphic" or reads the filename like "IMG_3847.jpg." The user has no idea what product they are looking at. **Bad: Custom dropdown built with divs.** A developer creates a dropdown menu using `<div>` elements and CSS. Because these elements have no semantic meaning, the screen reader does not announce them as a menu or indicate which item is selected. Using `<select>`, or proper ARIA roles like `role="listbox"`, would fix this. **Good: Dynamic content with live regions.** A shopping cart updates the item count when a user adds a product. Using `aria-live="polite"` on the cart count element, the screen reader announces "Cart: 3 items" without interrupting the user's current task. **Bad: Focus trap in a modal.** A modal dialog opens but focus is not moved to it, so the screen reader continues reading the page behind the modal. Worse, when the user tabs, focus wraps around the underlying page instead of staying within the modal. The user cannot find the modal content or the close button.

**Relying on visual-only cues.** Color changes, icons without text labels, and spatial positioning ("click the button on the right") convey nothing to a screen reader. Every visual cue must have a text-based equivalent. **Missing or unhelpful alt text.** Writing `alt="image"` or `alt="photo"` is nearly as bad as having no alt text. Alt text should describe the content and function of the image. For decorative images, use `alt=""` (empty alt) so the screen reader skips them entirely. **Breaking heading hierarchy.** Jumping from H1 to H4 or using headings purely for visual styling confuses screen reader navigation. Headings should form a logical outline of the page content. **Inaccessible custom components.** Building interactive widgets like tabs, accordions, or menus from scratch using `<div>` and `<span>` without adding proper ARIA roles, states, and keyboard support makes them invisible or unusable to screen readers. **Auto-playing audio or video.** Content that plays automatically interferes with screen reader audio output. Users cannot hear the screen reader over the media. WCAG requires that auto-playing audio lasting more than 3 seconds must have a mechanism to pause or stop it. **Incorrect use of ARIA.** Adding `role="button"` to a `<div>` but not adding keyboard event handlers (Enter and Space key) creates a "button" that screen readers announce but that keyboard users cannot activate. Misusing ARIA is often worse than not using it at all. **Not testing with actual screen readers.** Automated accessibility testing tools catch roughly 30-40% of accessibility issues. They cannot detect whether the screen reader experience is coherent, whether reading order makes sense, or whether dynamic interactions work correctly. Manual testing with JAWS, NVDA, or VoiceOver is essential.