Glossary / Screen readers
Screen readers
Screen readers are assistive technologies that expose content and interaction through speech, braille, or both. They consume a browser’s accessibility tree, which is derived from DOM semantics, names, roles, states, and relationships; they do not simply read pixels or source code. Users navigate in different modes—by reading text, headings, landmarks, links, form controls, or interacting with widgets—so accessible markup must communicate structure and behavior, not just a spoken description.
What to know
- Common desktop combinations include NVDA with Firefox/Chrome, JAWS with Chrome/Edge, and VoiceOver with Safari; mobile users commonly use VoiceOver on iOS and TalkBack on Android. Behavior differs by browser/OS/AT version.
- Browse/virtual mode supports reading and structural navigation; focus/forms mode routes keystrokes to interactive controls. Users may switch modes automatically or manually.
- The accessibility tree contains computed role, accessible name, description, value, state, and relationships. Inspect it in browser developer tools.
- Headings, landmarks, lists, tables, labels, button names, expanded/selected/checked states, and live announcements support efficient navigation.
- Screen-reader output is not a reliable proxy for all accessibility: keyboard users may not use a screen reader, and users may use speech input, magnification, braille, or combinations.
- Test common tasks, not just isolated announcements; verbosity and exact phrasing are user-configurable.
Testing workflow
Start with semantic HTML and keyboard testing. Then test critical journeys with representative browser/AT pairs: navigate by headings and landmarks, use forms, operate composite widgets, open/close dialogs, submit invalid data, and observe async status messages. Verify that labels are useful, hidden content is truly hidden, focus stays coherent, and repeated controls have distinguishable names. Check the browser accessibility tree when an announcement is surprising. Do not add ARIA based only on what one screen reader says; it may mask a semantic defect or create duplicate announcements.
Interview questions
- What does a screen reader read? The browser accessibility tree and its exposed semantics, with browser and assistive-technology behavior affecting presentation.
- Why test more than one browser/AT combination? Accessibility APIs and support differ, and no single pairing represents all users.
- What is browse mode? A reading/navigation mode that lets users move through document text and structures; it differs from interacting directly with form controls.
- How should you debug an incorrect announcement? Inspect computed name/role/state/relationships, test keyboard behavior, and reduce the issue to the smallest semantic and AT combination.
- Can accessibility be validated by screen reader alone? No. Combine semantics, keyboard, zoom, contrast, automation, and user evaluation.