People Who Use Screen Readers
A screen reader reads your markup, not your design. Everything meaningful you expressed visually has to also exist in code.
The screen reader isn't reading your page. It's reading your HTML.
A screen reader user does not scan your page the way a sighted user does. They move through it — by heading, by landmark, by link, by form control — using keyboard shortcuts that jump between structures. A well-built page is fast to navigate this way: press H repeatedly and you hear the outline of the document; press D and you jump between banner, navigation, main, and footer. A badly built page collapses into a flat wall of "link, link, link, button, clickable, image" with no structure to skip through, and the only way to find anything is to listen to all of it in order.
Scale: About 1 million people in the U.S. are blind, and roughly 7 million adults report a visual disability. (Source: CDC. Survey-based disability figures undercount — treat this as a floor.)
What they're using
- JAWS and NVDA on Windows, usually with Chrome or Firefox
- VoiceOver on macOS and iOS, built into the operating system
- TalkBack on Android
- Refreshable braille displays, which render the same accessibility tree as text
6 barriers we find most often, and the criteria behind them.
Images that carry information but say nothing
A chart, a map, an infographic, a photo of a flyer with the event details in it. If the alternative text is empty, a filename, or "image," the information simply is not on the page for this user. Decorative images are the opposite problem: unmarked, they add noise to every pass through the document.
Success criteria: 1.1.1 Non-text Content A
Headings used for size instead of structure
When headings are chosen because they look right rather than because they describe the hierarchy, heading navigation stops working. An H4 used for a page title, or a section heading marked up as a styled paragraph, removes the landmark a screen reader user was going to jump to.
Success criteria: 1.3.1 Info and Relationships A · 2.4.6 Headings and Labels AA
Controls with no accessible name
Icon-only buttons, links that read "click here" out of context, form fields labeled only by placeholder text or by visual proximity. The user hears "button" and has to activate it to find out what it does — which is not an acceptable way to discover a Delete control.
Success criteria: 1.1.1 Non-text Content A · 2.4.4 Link Purpose (In Context) A · 3.3.2 Labels or Instructions A · 4.1.2 Name, Role, Value A
Custom widgets that lie about what they are
A div styled as a checkbox, a dropdown built from list items, a modal that does not announce itself. Without correct roles, states, and properties, assistive technology has no way to convey what the control is or whether it is currently checked, expanded, or selected.
Success criteria: 4.1.2 Name, Role, Value A · 1.3.1 Info and Relationships A
Changes that happen silently
Results filter, a total updates, an error appears above the form, a record saves. If the change is not in a live region, the screen reader user's focus is still where it was and they have no idea anything happened.
Success criteria: 4.1.3 Status Messages AA · 3.3.1 Error Identification A
Data tables without headers
Tables used for layout, or data tables whose header cells are not marked up as headers, produce a stream of disconnected values. The user hears "4,200" with no way to know which row and column it belongs to.
Success criteria: 1.3.1 Info and Relationships A
The changes that actually remove the barrier.
Write alternative text for meaning, not description
Ask what the image is doing on the page. A logo in the header is the site name. A chart is its finding. A decorative divider is empty alt. The same photo can need three different alt values in three different contexts.
Use native HTML elements before reaching for ARIA
A real button, a real checkbox, a real select. Native elements carry name, role, state, and keyboard behavior for free. The first rule of ARIA is not to use ARIA when HTML already does the job.
Make the heading outline match the visual hierarchy
Headings in order, no skipped levels, one H1 per page. If the visual design implies a section, that section gets a heading — even if it has to be visually hidden.
Announce what changes
Status messages in a live region, errors tied to their fields with aria-describedby, focus moved deliberately when a dialog opens and returned when it closes.
Three tests you can run before you call anyone.
- Turn on VoiceOver (Cmd+F5 on a Mac) or NVDA and navigate one key task end to end with the screen off.
- Pull up the heading list (VO+U on VoiceOver, Insert+F6 in NVDA) and read it like a table of contents. If it does not describe the page, neither does your markup.
- Tab through every control and listen. Any control announced only as "button" or "link" has no accessible name.
If any of those go badly, you have your answer and you did not need a vendor to get it. What a vendor is for is the part after: knowing which of the 55 criteria that maps to, how deep it goes, and what it costs to fix properly rather than patch.
Run the Free CheckerWhere this shows up in practice
Other people the standard was written for.
People With Low Vision
Far more people have low vision than are blind. Most of them are not using a screen reader — they are using your page at 300% zoom.
Read the profilePeople With Color Vision Deficiency
Color can carry meaning — it just cannot be the only thing carrying it. This is the cheapest WCAG failure to fix and one of the most common.
Read the profileAll 55 Success Criteria
Every Level A and AA criterion in plain language, with the failure we see most often for each.
Reference