accessibility
Screen readers
How do screen readers change the way an interface is experienced?
A screen reader is software that speaks (or sends to a braille display) what's on screen, letting blind and low-vision people use a computer by ear. Crucially, it turns a two-dimensional visual layout into a one-dimensional stream - read in source order, element by element - so the experience is linear, sequential, and entirely dependent on the meaning in your markup.
Also known as: screen reader, screen readers, assistive technology, linearised reading
Prefer to watch?
Watch the recap 0:54
The demo
A tidy 2D layout - to your eyes. Step through it the way a screen reader does, one element at a time in source order, and watch the grid flatten into a single queue.
Press “Next” to start reading.
What this demo shows (text version)
A layout shows a heading, a row of three product cards (each with an image, title, price and "add" button), and a footer - the kind of thing you take in at a glance. The demo lets you step a cursor through it the way a screen reader does: in source order, one element at a time, highlighting each and showing what it would announce ("heading level 1, Trainers", "image, blue running shoe", "button, add Aero to basket", and so on).
Stepping through reveals that the two-dimensional grid is experienced as a one-dimensional stream. That's why reading order must match logical order, every element needs a real accessible name (alt text, button labels), and headings and landmarks matter so much - they're the only way to skim and jump by ear. The picture sighted users see is not the page a screen-reader user receives.
A screen reader linearises your page: it reads in source order, one element at a time, with no glance-and-scan. So reading order must match logical order, every element needs a real accessible name (images need alt text, buttons need labels), and structure - headings, landmarks, lists - is what lets users skim and jump instead of hearing everything top to bottom. Design the sequence and the names, not just the picture.
Step through the layout the way a screen reader does and the neat 2D grid became a single-file queue: image, heading, price, button, image, heading… one after another, no skimming. Suddenly it's obvious why source order, alt text and headings matter so much - by ear, they're the only things to navigate by. The picture you see is not the page they get.
The defining shift is from spatial to sequential. Sighted users glance around and grasp a layout at once; a screen-reader user receives it as a stream, in DOM order, one item at a time. So visual order must match source order (CSS can reorder things visually and leave the reading order nonsensical), and anything conveyed by position or colour alone is simply gone.
Every element has to carry its own meaning, because there's no surrounding picture to lean on. Images need alt text, icon buttons need labels, form fields need associated labels, and decorative things should be hidden from the reader. A control that announces as "button" with no name, or an image read as its filename, is a dead end by ear.
Structure is navigation. Screen-reader users rarely listen start to finish - they jump by heading, list, landmark and link, the way you'd skim a page with your eyes. That only works if the structure is real (semantic HTML), so good headings and landmarks aren't decoration; they're the table of contents and the map. Test by turning your screen off and using a real screen reader.