Screen Reader

Computers were built from the start on the assumption that somebody is looking at the screen. For a person who can't see it, the screen carries no information at all. A printed book could be transcribed into braille ahead of time, but a screen changes with every keystroke, so transcribing it in advance was never going to keep up.

The job of reading the screen therefore went to software. A screen reader takes what the operating system reports about the current screen and sends it out as speech. The person moves from one position to the next with the keyboard and finds out by ear what sits at each position they land on.

The arrival of that software added one responsibility on the building side, because what reaches the user isn't the shape on screen but the name and structure attached to that shape. When Theo at Pagedeck closed his eyes and listened to a document list screen he had built himself, what he heard was "button, button, button." Share, comment and delete icons sat in a row and none of them had a name. Accessibility — designing so that a product works regardless of disability or circumstance — splits into standards, implementation and assistive technology, and a screen reader is the last of those, the piece that delivers the result to the person.

The work this tool takes on is replacing the scan of an eye with the ear. Eyes take in a whole screen at once and jump straight to the part they want, whereas sound can only arrive one piece at a time, in order. Reading a long screen start to finish would make it impossible to find anything, so what the software actually offers is scanning rather than narration.

1. Scanning by structure. Jump from heading to heading, pull out a list of every link, or step through form fields alone. On a document screen that means hearing twenty subheadings and going straight to the relevant one.
2. Reading names. The drawing in an icon doesn't travel; the name attached to it does. Without names, three controls read as "button, button, button"; with names, they read as "share button, comment button, delete button." Same screen — one carries nothing, the other works as a table of contents.
3. Reading roles. With semantic markup, which uses the tag that matches what an element actually is, a button is announced as a button and a heading as a heading at its level. A box merely styled to look like a button is announced as a box, and the keyboard can't reach it either.
4. Reading images. A picture makes no sound of its own, so the sentence written as alt text is read instead. "Third-quarter revenue chart" and "third-quarter revenue chart, up 12 percent against July" are different pieces of information to somebody listening.
5. Reading state. A "saving" indicator that appears in a corner and fades is visible only to the eye. It reaches speech only when announced through ARIA, the attribute specification that reports roles and states to assistive technology.

All of the operating happens through the keyboard. Anything reachable only by mouse is, for a screen reader user, a place that doesn't exist, so a screen without keyboard navigation can be read but not pressed. For sighted people working by keyboard, the focus ring that outlines the current position does the same job that speech does here.

There are several other assistive options on the user's side, and none of them substitutes for this one. Magnification that scales the screen up, and inverted colors that raise contrast, are both ways of putting remaining vision to work; where there is no vision at all, no channel is available other than sound. A refreshable braille display sends what the screen reader has read out to braille cells instead of a speaker, which makes it an output format rather than an alternative. Voice control suits people who have trouble using their hands and doesn't tell anyone what's on the screen.

On the building side, the alternative to switching a screen reader on is an automated checker. These programs crawl a screen and hand back a list of rule violations, and what they catch is limited to what a machine can judge on its own. A button with an empty name gets flagged; a button with a wrong name passes. Alt text containing the raw file name passes too, because the field isn't blank. Review documents that tick off items from WCAG, the international standard for web accessibility, share the same limit.

So teams in practice layer three things. Run the automated check to clear out what's missing, switch on a screen reader and listen through one complete flow, and where possible hand the same flow to somebody who uses the tool every day.

"These icon buttons have no names, so a screen reader just reads button, button, button."

The pictures on screen convey nothing at all in speech.

"The modal opened but focus didn't move into it, so it keeps reading the list behind it."

Keyboard focus wasn't moved to the new window, which leaves the user stuck outside it.

"Have you gone through this flow with a screen reader on? I got stuck on the third screen."

A request to discuss what somebody actually heard rather than what a document claims.

These conversations multiplied at Pagedeck in the quarter it had to submit accessibility answers for a public-sector procurement review. Noa started writing the name each icon should announce alongside the mockup, and Theo listened through every new screen with a screen reader before asking for review. The only thing the two of them changed was the order of the work, and the number of items coming back from review dropped sharply.

The most common assumption is that only people with no sight at all use it. The word "reader" invites that reading. In practice, people who find text hard to process use speech and text together, and the same feature gets switched on temporarily — while recovering from eye surgery, or while driving. Scoping the audience to blind users alone makes the number of people involved look far smaller than it is, and that undercount is the number quoted when the work gets pushed to the bottom of the priority list.

The other frequent mistake is treating it as something bolted on at the end of development, since it looks like a matter of adding a few attributes in code. But whether there is anything to announce gets decided in the mockup. Choosing icons with no labels, distinguishing states by color alone, drawing a tap area smaller than the touch target minimum — each of those changes the structure of the screen. Catch it at the code stage and the screen has to be redrawn from scratch, and with no room left in the schedule it slides to next quarter.