40 of 86 rules
Blind and screen reader users
A screen reader turns the page into speech, or into braille under somebody's fingers, and it can only hand on what the code actually said. Anything left out of the markup does not exist here. Which is why most of this list is about names, structure and reading order, and almost none of it is about how the page looks.
What tends to break
Headings carry more of this than anything else. Asked how they get around a long page, seven in ten screen reader users move through the headings, one in seven uses the browser's find, and fewer than one in twenty-five starts from landmarks, so a skipped level is a wrong turn on the only map somebody has. Names come next. An image with no alt text, a button that announces as nothing but "clickable", a heading that is really a styled div. Each one quietly takes away something a sighted reader is handed for free. Two things are worth knowing before you test. Around two in five read part of the page on a braille display, where speech rate and audio cues do nothing and structure carries the whole experience. And nine in ten use a screen reader on a phone as well, so testing that stops at a laptop has stopped well before the audience does.
Level A, 23 rules
- 1.1.1 Non-text Content
Blind and screen reader users meet this rule first, because for them the alt text is the image. Deafblind users read the same words on a braille display, which makes the text the only route in. People browsing with images switched off on a slow connection get whatever you wrote and nothing else. So does anyone having the page read aloud by a voice assistant.
- 1.2.1 Audio-only and Video-only (Prerecorded)
Deaf and hard-of-hearing users cannot follow a podcast without a transcript. Blind users cannot follow a silent demo without narration or written steps. Deafblind users depend on the text version, because braille is the only route into either one. Anyone in a quiet office or a loud train reads the transcript too.
- 1.2.3 Audio Description or Media Alternative (Prerecorded)
Blind and low-vision viewers hear the soundtrack and miss the on-screen text, the actions and the context a sighted viewer picks up without noticing. People with cognitive disabilities who find it hard to work out what is happening on screen benefit from hearing the same thing named aloud.
- 1.3.1 Info and Relationships
Screen reader users depend on this rule above everyone else, and braille display users read the same structure. Voice control users need a control's visible label to match its accessible name, or the spoken command finds nothing to act on. Reader-mode users, and anyone whose browser or extension rebuilds the page, rely on the same markup underneath.
- 1.3.2 Meaningful Sequence
Screen reader users hear the page in code order, so a scrambled order reaches them as a scrambled page. Braille display users read the same sequence. So does anyone using a reader mode, a custom stylesheet or a print stylesheet, since all three throw the visual arrangement away.
- 1.3.3 Sensory Characteristics
Blind users have nothing to search for when a control is identified only by where it sits. Colorblind users cannot find "the green one". Screen magnifier users see a small slice of the layout at a time, so "top right" means the top right of what they can currently see rather than of the page.
- 1.4.2 Audio Control
Screen reader users are hit hardest, because the sound competes with the speech they navigate by. Users who are both blind and hard of hearing have no way out at all when the screen reader shares the system volume. People with attention or auditory processing difficulties lose their place the moment unexpected sound starts.
- 2.1.1 Keyboard
This affects blind users driving a screen reader from the keyboard, speech-input users whose software sends keystrokes on their behalf, people using sip-and-puff systems, on-screen keyboards, scanning software or an alternate keyboard, people with tremors or limited hand dexterity, and low-vision users who find tracking a pointer harder than pressing a key.
- 2.1.2 No Keyboard Trap
This affects every keyboard-dependent visitor, including screen-reader users, switch-device users, speech-input users whose software sends keystrokes, and sighted people who simply prefer typing to clicking.
- 2.2.1 Timing Adjustable
This affects screen-reader users hearing a form one field at a time, slow typists, people with cognitive or motor disabilities, deaf users for whom the page text is a second language or who are working through a sign language interpreter, and anyone for whom a form takes longer than it did in the demo.
- 2.2.2 Pause, Stop, Hide
This affects people with ADHD and other cognitive disabilities, people with vestibular disorders who get dizzy or nauseous from on-screen motion, screen-magnifier users trying to track a target that keeps moving, screen-reader users whose linear read is interrupted by content changing underneath them, and anyone who reads stationary text slowly.
- 2.4.1 Bypass Blocks
This affects keyboard and switch users, who would otherwise press Tab dozens of times on every page, screen-reader users jumping by landmark or heading, screen-magnifier users hunting for where the main content starts, and people for whom repeated keystrokes are physically painful.
- 2.4.2 Page Titled
This affects screen-reader users orienting themselves on arrival, people with visual disabilities telling several open pages apart, people with cognitive disabilities, limited short-term memory or reading disabilities, people with severe mobility impairments who work by audio while moving between pages, and everyone scanning a page of search results.
- 2.4.3 Focus Order
This affects keyboard and screen-reader users moving through the page in sequence, magnification users at high zoom who can read a field in the wrong context entirely, and people with reading or cognitive disabilities who lose their place when focus lands somewhere unexpected.
- 2.4.4 Link Purpose (In Context)
This affects screen-reader users navigating by link list, voice-control users who speak a link's visible name to follow it, people with motion impairments who need to know which links to skip, and anyone reading search results where the link text is the whole preview.
- 2.5.1 Pointer Gestures
This affects people with limited dexterity or tremors, people using a head pointer, eye-gaze system, prosthetic or speech-controlled mouse emulator, people working one-handed, screen-reader users on touchscreens whose own software eats the gesture before the page sees it, and people with cognitive or learning disabilities who can fall back on a plain tap where a custom gesture makes no sense to them.
- 2.5.3 Label in Name
This affects voice-control users, whose spoken commands target the labels they can see, screen-reader users who hear one thing while a sighted colleague reads another, people using text-to-speech alongside the visible page, and people with cognitive difficulties who use speech and would otherwise memorise a second name for every control.
- 3.1.1 Language of Page
Screen reader users hear the whole page mispronounced when the attribute is missing or wrong, because their software has nothing else to go on. People who find reading hard, and who use text-to-speech to get through a page, hit the same wall for the same reason. Braille displays and translation tools depend on the attribute too. So do people relying on captions, since a media player uses the page language to decide which track to show.
- 3.2.1 On Focus
Keyboard and screen reader users pass through every control on the way to any control, so a page that acts on focus touches almost everything they try to do. People with motor impairments are hit twice, since a tremor or a switch makes an unintended focus more likely in the first place. Users with cognitive disabilities lose their place when a page moves on its own instead of waiting to be asked.
- 3.2.2 On Input
Screen reader users learn about a context change only once it has happened, because nothing warned them. People with low vision may not see a new window appear at all. People with reading or intellectual disabilities, and anyone who finds visual cues hard to read, need the change said in words rather than shown. Users with cognitive disabilities lose their thread when the page acts without being asked.
- 3.3.1 Error Identification
Screen reader users learn only that something failed, with no way to tell which field caused it. Colorblind users may not read a red border as different from any other border. People with cognitive, language and learning disabilities need the reason spelled out, because the shape of a form does not always make it obvious. Everybody else just loses the time.
- 3.3.2 Labels or Instructions
Users with cognitive disabilities lose the instruction the instant its placeholder disappears, and they are the people least able to rebuild it from memory. Screen reader users meet a field that was never labeled at all. People with low vision struggle with placeholder text in particular, since browsers usually render it at a contrast that would fail the contrast rule if it were ordinary text. And everybody guesses at date formats nobody stated.
- 4.1.2 Name, Role, Value
Screen reader users hear nothing useful, or hear only that something is clickable, which is what VoiceOver says about any element carrying a click handler. Either way they cannot tell what the control does, or whether it is a control at all. Voice-control users cannot speak the name to activate it, because there is no name to speak. And a user working a slider through their own assistive technology cannot move it when the value is exposed but not settable. That satisfies half this rule and fails the other half.
Level AA, 8 rules
- 1.2.5 Audio Description (Prerecorded)
Blind and low-vision viewers depend on the soundtrack to carry everything the video communicates, because nothing on screen reaches them any other way. Viewers with cognitive disabilities who find it hard to interpret what is happening on screen get the same benefit from hearing it named.
- 2.4.5 Multiple Ways
This affects people with cognitive disabilities who find deep hierarchies hard to hold in mind, screen-reader users for whom search beats a menu tree, magnification users reading a large navigation bar a slice at a time, and people who would rather move through a site in sequence, page after page.
- 2.4.6 Headings and Labels
This affects screen-reader users skimming by heading list, people with limited short-term memory or reading disabilities who rely on predicting what a section holds, people with cognitive disabilities orienting by signposts, and every reader who scans a page before committing to it.
- 3.1.2 Language of Parts
Multilingual screen reader users are who this rule is for, because they cannot recognize their own language when the page mispronounces it. Anyone using a language switcher needs their language's name spoken well enough to pick it out of a list. Braille readers need it too, since language decides which contractions the software may use. And people relying on captions use it to spot a language change in a soundtrack.
- 3.2.3 Consistent Navigation
Screen reader users move through a page in sequence, so a link that has moved is a link they now have to hunt for. People with low vision using magnification see a small window of the screen at a time and rely on the layout holding still. Users with cognitive and intellectual disabilities depend on the routine staying put. And sighted users with no disability at all navigate by spatial memory too, which is why this one turns up in usability testing as well as in audits.
- 3.2.4 Consistent Identification
Users with cognitive disabilities need a function they have already learned to look the same next time. Screen reader users rely on that same familiarity, and they lose the ability to find a control by searching for its name when the name keeps moving. People who find text hard to read get the most out of consistent icons, because a familiar icon lets them skip the words entirely, and that only holds while the icon means one thing.
- 3.3.3 Error Suggestion
People with cognitive and learning disabilities are hit hardest, because knowing something is wrong is not the same as knowing what to do. Blind and low-vision users need the fix described rather than shown, since the field will not look wrong to them. People with motor impairments pay for every extra attempt in effort. Everybody else is stuck in the same loop with less at stake.
- 4.1.3 Status Messages
Screen reader users add something to the cart, apply a filter, or submit a form, and hear nothing back, so they have no way to know whether anything happened. Blind and low-vision users of assistive technology are the audience the criterion names. There is a second benefit further out. Software that can identify a status message can also hold it back, delay it, or push it forward for a user who wants that. None of it is possible until the message is marked.
Level AAA, 9 rules
No law names AAA as a blanket duty, but these are where the remaining barriers for people who cannot see the screen usually sit.
- 1.2.7 Extended Audio Description (Prerecorded)
Blind viewers and people with low vision who cannot see the screen feel this first, and W3C names a third group beside them. People with cognitive disabilities who find it hard to work out what is happening visually.
- 1.2.8 Media Alternative (Prerecorded)
Deafblind readers on a braille display depend on this most. So does anybody who needs the content as text rather than as time-based media.
- 2.2.3 No Timing
W3C names blind readers first, then people with low vision, then people with cognitive limitations and people with motor impairments, and adds deaf readers for whom written text is a second language.
- 2.2.4 Interruptions
People with attention differences feel this most, along with screen reader users and people with low vision whose reading gets cut across by an update they never asked for.
- 2.2.5 Re-authenticating
Anybody who works through a form more slowly. W3C names people with cognitive limitations who read slowly, screen reader users working through a complicated form, and people using alternative input devices.
- 2.4.9 Link Purpose (Link Only)
People with motion impairments, people with cognitive limitations, and screen reader users pulling up a list of a page's links are the three groups W3C names.
- 2.4.10 Section Headings
Blind readers, keyboard users, people with learning disabilities and anybody skimming rather than reading straight through all use the same structure.
- 3.1.6 Pronunciation
Blind readers, readers with low vision, and readers with reading disabilities are the three groups W3C names, along with anybody whose technology reads the words out loud.
- 3.2.5 Change on Request
Screen reader users, people with low vision, people with motor impairments and people with cognitive limitations are the four groups W3C names.
How this list was made
Each rule appears here because its own note about who it affects names people who cannot see the screen. That keeps this page and the rule pages saying the same thing, and it makes the list narrower than every rule that could matter, because a rule helping these readers without saying so does not turn up. Start with this, then read the full Level AA set, which is what the laws actually name.
Other groups
- Low vision35 rules
- Deaf and hard of hearing9 rules
- Motor and keyboard-only33 rules
- Voice control13 rules
- Cognitive and learning50 rules
- Seizures and vestibular disorders4 rules