Screen reader

A screen reader is a separate program sitting between the browser and the person using it: NVDA and JAWS on Windows, VoiceOver on Apple platforms, TalkBack on Android, Narrator shipped with Windows. What it reads is not your CSS and not your HTML. It reads the accessibility tree, the structure the browser derives from the markup, where every node has a role, an accessible name, and a set of states. A control that ends up in that tree as a div with no name is announced as nothing useful, however obvious it looks on screen.

It also brings its own keyboard, which is the part most sighted developers never see. Alongside Tab, which visits only what is focusable, there is a virtual cursor that walks everything in reading order including plain text, plus an element list or rotor that jumps straight to the next heading, link, landmark, or form field. That is why headings and landmarks are navigation rather than decoration, and why a page’s tab order is only part of what somebody actually traverses.

Two mistakes follow from thinking of it as a preview. The first is writing for one product: announcements differ between readers and between browsers, so verbosity fixes aimed at a single one usually break another, and the durable answer is correct roles, names, and states rather than tuned text. The second is confusing the software with its output. The reader is the thing that speaks; a change it announces without being sent there needs a live region, and a result it must report is a status message. Turn one on and use your own site with the screen off for five minutes: it costs an afternoon and replaces most guessing.