Who accessibility serves

Why this matters

Accessibility means people with disabilities can perceive, understand, navigate and interact with what you build. It is not a niche. The World Health Organization estimates that about 1.3 billion people, roughly one in six, live with a significant disability, and almost everyone has a temporary or situational limitation at some point: a broken wrist, a bright screen in the sun, a noisy train, an aging parent's eyesight. When an interface is accessible, it usually works better for everyone.

It is also part of the job. Software developers, UI developers and product designers are expected to ship interfaces that meet the Web Content Accessibility Guidelines (WCAG), and many organisations are legally required to. You will meet WCAG properly in the next lesson; this one is about the people.

Who uses the web differently

The W3C's How People with Disabilities Use the Web groups needs into a few broad areas. Real people often have more than one.

• Visual. Blindness, low vision and colour vision deficiency. Blind users rely on a screen reader, which speaks the page (or sends it to a refreshable braille display). Low-vision users zoom to 200 or 400 percent, use screen magnifiers, increase text spacing or switch to high-contrast modes. About 1 in 12 men has some form of colour vision deficiency, so colour alone cannot carry meaning.
• Auditory. Deaf and hard-of-hearing users need captions for video and transcripts for audio. Some are fluent in a sign language and read written English as a second language, so plain wording helps.
• Motor and physical. Tremors, paralysis, arthritis, missing limbs or repetitive strain injury. People may use only a keyboard, a switch (one or two buttons that step through options), voice control ("click Submit"), a head pointer or eye tracking. Small click targets and drag-only interactions shut them out.
• Cognitive, learning and neurological. Dyslexia, ADHD, memory loss, autism, epilepsy and more. Clear language, predictable layouts, no surprise time limits, and no flashing content (which can trigger seizures) all matter.
• Speech. Interfaces that only accept voice input exclude people who cannot speak clearly.

Assistive technology in practice

Assistive technology sits between the person and your page. It does not see pixels; it reads the browser's accessibility tree, a simplified version of the DOM that exposes each element's role (button, link, heading), name ("Search"), and state (checked, expanded). That is why semantic HTML matters so much:

<!-- Exposed as: button, name "Save draft". Works with keyboard, screen readers and voice control. -->
<button type="button">Save draft</button>

<!-- Exposed as: generic text. No role, not focusable, invisible to "click Save draft" voice commands. -->
<div class="btn" onclick="save()">Save draft</div>

Both look identical once styled. Only the first one is usable without a mouse.

Common tools you should know by name:

Worked example: one product page, five people

Imagine a shoe shop's product page, and walk it through five visitors.

1. Amira is blind and uses NVDA. She presses H to jump between headings. If the product name is a styled <div>, there is nothing to jump to. If the size picker is a set of coloured squares with no text, she hears "clickable, clickable, clickable".
2. Ben has a tremor and uses only the keyboard. He presses Tab to move. If the "Add to bag" control is a <div>, Tab skips it and he cannot buy anything.
3. Chen has low vision and zooms to 400 percent. If the layout does not reflow, he has to scroll sideways on every line.
4. Dana is colour-blind. "Out of stock sizes are shown in red" means nothing to her unless the size is also crossed out or labelled.
5. Eli is Deaf. The product video explains the fit, but has no captions.

None of these fixes is exotic: headings, real buttons, text labels, a layout that reflows, and captions. That is most of accessibility.

The social model

Disability advocates describe a social model: a person is disabled by barriers in the environment, not only by their body. A blind person is not "unable to shop"; the site with unlabelled buttons is what blocks them. As a builder, you control those barriers. That framing is useful because it turns accessibility from charity into engineering: find the barrier, remove it, test it.

Common mistakes

• Treating accessibility as a final checklist. Retrofitting a finished design costs far more than choosing a real <button> on day one.
• Assuming "screen reader user" means everyone. Keyboard-only, zoom, voice and cognitive needs are just as common.
• Building an "accessible version". Separate text-only sites fall out of date. Make the one site work.
• Relying on overlays. Third-party "accessibility overlay" widgets do not fix inaccessible code, and many disabled users actively avoid them.
• Never meeting users. Watching a real assistive technology user for ten minutes teaches more than hours of reading.

Quick recap

• About one in six people has a significant disability, and situational limits affect everyone.
• Needs fall into visual, auditory, motor, cognitive and speech areas.
• Assistive technology reads the accessibility tree: role, name and state.
• Native HTML elements give you most of that for free.
• Further reading: W3C WAI: Introduction to Web Accessibility.

Try it

Open the Do tab for a short quiz on who accessibility serves.