Web accessibility means that people with disabilities can perceive, understand, navigate and interact with websites and apps, and contribute to them. It is not a feature you add at the end. It is a quality of the code and content you already write.
This lesson explains who accessibility is for, how people actually use the web, and why it matters to developers, organisations and the law.
Disability is a mismatch, not a defect
The World Health Organization estimates that about 1.3 billion people, around 16% of the world's population, experience significant disability. Many more have temporary or situational limitations.
A useful way to think about disability on the web is as a mismatch between a person and a design. A blind person is not "unable to use" a website. A website that only conveys information visually is unusable by a blind person. The barrier is in the design, and that means developers can remove it.
How people use the web
Disabilities vary widely, and the same person may have several. These broad groups help you think about barriers.
| Group | Examples | What helps on the web |
|---|---|---|
| Visual | Blindness, low vision, colour vision deficiency | Text alternatives, real headings, good contrast, zoom without breaking the layout |
| Auditory | Deaf and hard of hearing people | Captions, transcripts, no information conveyed only by sound |
| Motor | Tremor, limited reach, paralysis, repetitive strain injury | Full keyboard support, large targets, no precise gestures or time limits |
| Cognitive and learning | Dyslexia, ADHD, memory impairments, learning disabilities | Clear language, consistent navigation, helpful error messages, no distractions |
| Seizure and vestibular | Photosensitive epilepsy, vestibular disorders | No flashing content, a way to reduce motion |
| Speech | People who do not speak or whose speech is hard for software to recognise | Alternatives to voice-only input |
Assistive technologies
Many disabled people use assistive technology: software or hardware that sits between them and the page. It can only work with what your code exposes.
- Screen readers such as NVDA, JAWS, VoiceOver and TalkBack read the page aloud or output it to a braille display. Users navigate by headings, landmarks, links and form fields, not by looking at the layout.
- Screen magnifiers enlarge part of the screen, so the user sees only a small area at a time.
- Keyboard and switch access lets people operate everything with a keyboard, a single switch, or a device that emulates key presses.
- Voice control such as Dragon or the voice control built into Windows and macOS lets people say "click Submit". It relies on visible labels matching the accessible name.
- Browser settings such as zoom, larger default fonts, high contrast modes and reduced motion change how your page is displayed.
All of these depend on the same thing: a page whose structure and meaning are in the code, not only in how it looks.
<!-- A screen reader announces: "Search, button" -->
<button type="submit">Search</button>
<!-- A screen reader may announce only "clickable" or nothing at all -->
<div class="btn" onclick="search()">Search</div>The first example works with a keyboard, a screen reader and voice control for free. The second works only with a mouse. You will fix examples like this throughout the course.
Accessibility helps everyone
Features built for disabled people regularly help many others. Microsoft's Inclusive Design toolkit describes disability as permanent, temporary or situational.
| Permanent | Temporary | Situational |
|---|---|---|
| One arm | Arm injury | Holding a baby |
| Blind | Eye surgery recovery | Bright sunlight on a phone screen |
| Deaf | Ear infection | Noisy train carriage |
Captions help people watching in a quiet office. Good contrast helps on a cheap screen outdoors. Clear error messages help everyone filling in a form in a hurry. Keyboard support helps power users. Semantic structure also helps search engines and AI tools understand your content.
Accessibility is not the same as usability, but they overlap heavily. An accessible site is almost always easier for everyone to use.
The legal case
Many jurisdictions require accessibility, especially for public bodies, and increasingly for private companies selling products and services. Examples include the Americans with Disabilities Act and Section 508 in the United States, the European Accessibility Act and the Web Accessibility Directive in the European Union, the Equality Act in the United Kingdom, and the Disability Discrimination Act in Australia.
Most of these laws and the standards they reference point to the Web Content Accessibility Guidelines (WCAG), usually at level AA. You will learn what that means in the next lesson. Laws differ in detail and change over time, so organisations should check the rules that apply to them with a qualified adviser.
The business case
- Reach: a site that more people can use has more potential customers, readers and staff.
- Quality: accessible code is usually cleaner, more semantic and easier to maintain and test.
- Search and performance: meaningful headings, link text and text alternatives also help search engines.
- Lower cost: fixing barriers during design and development is far cheaper than retrofitting a finished product.
- Reputation and risk: organisations avoid complaints and legal action, and show that they take all their users seriously.
What accessibility is not
- Not a separate site. A "text-only version" quickly falls out of date and treats disabled users as second class.
- Not an overlay. Third-party widgets that promise to make a site compliant with one line of JavaScript cannot fix missing labels, broken keyboard support or poor structure, and they can interfere with users' own assistive technology. Fix the code itself.
- Not only about screen readers. Keyboard users, people with low vision and people with cognitive disabilities often meet more barriers than screen reader users.
- Not finished at launch. New content and features can introduce new barriers, so accessibility is part of every release.
The fastest way to understand barriers is to try a page yourself. Unplug your mouse and use only the keyboard for five minutes on a site you know. You will meet focus traps, invisible focus and unreachable menus very quickly.
Summary
- Web accessibility means disabled people can perceive, understand, navigate and interact with the web.
- Barriers come from design choices, so developers can remove them.
- Visual, auditory, motor, cognitive, seizure, vestibular and speech disabilities each create different needs.
- Assistive technologies rely on structure and meaning exposed in the code.
- Accessibility benefits everyone, is required by law in many places, and is cheapest when built in from the start.
- Overlays and separate text-only sites are not solutions.
In the next lesson you will learn how WCAG organises accessibility into principles, success criteria and conformance levels.