Topic 7.1
Why Accessibility Matters
In one line
Accessibility means people with disabilities can use your page with their own tools; WCAG is the shared rulebook, AA is the level most laws ask for, and good HTML gets you most of the way.
Think of it like this
A building with a ramp next to the stairs. The ramp was added for wheelchair users, but parents with prams, delivery workers with trolleys and people with suitcases use it every day. Accessible web pages are the same: captions help deaf viewers and people in a noisy train; keyboard access helps blind users and power users; clear text helps people with dyslexia and people reading in a second language.
Words you'll meet
New words in this topic, in plain English. Come back here whenever one feels fuzzy.
- Accessibility (a11y)
- Making pages that people with disabilities can perceive, understand, navigate and use.
- Assistive technology
- Tools that help people use computers, like screen readers, magnifiers, voice control and switches.
- Screen reader
- Software that reads the page aloud (or to a braille display) and lets the user move by headings, links and controls.
- Accessibility tree
- The browser's simplified copy of the page with each item's role, name and state. Assistive tech reads this tree.
- Role
- What an element is to assistive tech: button, link, heading, checkbox, list.
- Accessible name
- What an element is called when assistive tech announces it, like "Search" for a search button.
- WCAG
- Web Content Accessibility Guidelines: the international rulebook for accessible web content, with levels A, AA and AAA.
- Success criterion
- One testable WCAG rule, like "text has a contrast ratio of at least 4.5:1".
- Contrast ratio
- How different two colours are in brightness, from 1:1 (same colour) to 21:1 (black on white).
Step by step
01Meet the people
Picture four users of the same checkout page: Meera is blind and uses NVDA; Tom has a tremor and uses only the keyboard; Li has low vision and zooms to 300%; Sam is deaf and watches product videos with captions.
Each one needs something different from your HTML: Meera needs names and roles, Tom needs focus he can see and reach, Li needs layouts that reflow and good contrast, Sam needs captions. The rest of this phase covers each need.
02See what assistive tech sees
The browser turns your HTML into the DOM, then into the accessibility tree. Only elements with meaning appear; plain layout divs are usually skipped. A screen reader announces each node as name, role, state: "Subscribe, checkbox, not checked".
03Compare a real button with a fake one
Both look the same once styled. The first is in the accessibility tree as "Save, button", is reachable with Tab and works with Enter and Space. The second is announced as plain text "Save", can't be reached with Tab and ignores the keyboard.
<button type="button">Save</button>
<!-- looks the same with CSS, but is not a button to assistive tech -->
<div class="btn" onclick="save()">Save</div>04Measure against WCAG
WCAG turns "be accessible" into testable checks. Teams usually commit to WCAG 2.2 level AA: every A and AA success criterion must pass on every page.
Some criteria can be measured by a tool (contrast, missing alt, missing labels); many need a human (is this alt text actually useful? is the focus order logical?). Topic 7.6 shows both kinds of testing.
05Fix the most common failures first
The yearly WebAIM Million study tests the home pages of a million popular sites and keeps finding detectable WCAG failures on about 95% of them. The same six problems top the list every year: low-contrast text, missing alt text, missing form labels, empty links, empty buttons and a missing page language.
All six are fixed with plain HTML and CSS you already know. The rest of this phase covers each one.
Try it yourself
- 1
Find a passing grey
Predict first: will
#767676pass AA on white? Add it to the list in the first example and run it. (It does, at about 4.54:1: it's the lightest grey that passes.) - 2
Fix the audit
In the second example, add
lang="en"to<html>,alt="Summer sale banner"to the image,aria-label="Cart"to the link, a<label>for the email input, and the textSearchinside the button. Predict the output, then run it: every count should be 0. - 3
Use the page without a mouse
Open any website you use often, put the mouse aside and press
Tabrepeatedly. Can you always see where you are? Can you reach the menu and the search? Write down the first place you get stuck.
Code & diagrams
The famous #777 grey fails AA for normal text by a hair. #595959 is the lightest grey that reaches 7:1 (AAA) on white.
Preview
Console
Nothing logged yet.Expected console output
#777777 on white: 4.48:1 fails AA
#595959 on white: 7.00:1 passes AA
#000000 on white: 21.00:1 passes AAReal tools (axe, Lighthouse) do this far more carefully. Fix each failure in the HTML and run again until every count is 0 and the language is set.
Preview
Console
Nothing logged yet.Expected console output
Page language set? false
Images without alt: 1
Inputs without a label: 1
Empty links: 1
Empty buttons: 1Break it on purpose
Errors are the best teachers. Make each change, read the error, guess what went wrong, then reveal the answer.
Break #1
Build a button from a div
Replace <button type="button">Save</button> with <div class="btn" onclick="save()">Save</div> and try it with the keyboard.
Myth vs fact
Myth
Accessibility only helps a small number of blind users.
Fact
About 1 in 6 people has a significant disability, and most of them aren't blind. Captions, keyboard access, contrast and clear writing also help older users, people on phones in sunlight and everyone in a hurry.
Myth
Accessibility is a feature to add at the end.
Fact
Retrofitting a finished site is slow and expensive. Choosing the right element as you write the HTML costs nothing and fixes most problems before they exist.
Myth
An overlay widget or plugin can make a site accessible automatically.
Fact
Overlays can't fix wrong structure, missing names or broken keyboard support in your code, and they often interfere with users' own assistive tech. Many disabled users and accessibility experts actively object to them. Fix the source.
Myth
Accessible sites must look plain.
Fact
Accessibility constrains contrast, focus visibility and structure, not style. Beautiful, modern sites can meet WCAG AA.
Pro corner
Extra depth for experienced readers. New to this? Skip it for now and come back later.
- ▸
Browsers expose the accessibility tree to the operating system's accessibility API: UI Automation and MSAA/IAccessible2 on Windows, NSAccessibility on macOS, AT-SPI on Linux, and the Android and iOS accessibility APIs. Screen readers talk to those APIs, not to the DOM, so the same HTML can be announced slightly differently by different browser and screen reader pairs.
- ▸
WCAG 2.2 removed success criterion 4.1.1 Parsing (it is now treated as always satisfied for HTML), because modern browsers parse HTML in a fully specified way. Valid HTML is still worth having for other reasons (Topic 7.6). WCAG 2.2 also added nine criteria, including 2.4.11 Focus Not Obscured (Minimum) (AA), 2.5.7 Dragging Movements (AA), 2.5.8 Target Size (Minimum) (AA) and 3.3.8 Accessible Authentication (Minimum) (AA).
- ▸
"Large text" in WCAG means at least 18 point (24 CSS px) regular, or 14 point (about 18.66 CSS px) bold. Non-text elements that you need to see to use a control, like input borders and focus indicators, need 3:1 against neighbouring colours (1.4.11 Non-text Contrast).
- ▸
WCAG 3 is in development as a W3C working draft with a different scoring model. It is not a standard yet; laws and contracts still reference WCAG 2.x (often 2.1 AA, increasingly 2.2 AA).
Remember this
- 1
Disability is common. The World Health Organization estimates about 1.3 billion people, roughly 1 in 6, live with a significant disability. Web-relevant groups are visual (blindness, low vision, colour blindness), hearing (deafness, hard of hearing), motor (can't use a mouse, tremors, paralysis, missing limbs), cognitive (memory, attention, dyslexia, learning disabilities) and seizure conditions (flashing content can trigger them). Disabilities can be permanent (one arm), temporary (a broken wrist) or situational (holding a baby in one arm). Designing for the first group helps all three.
- 2
People use assistive technology (AT): hardware or software that changes how they use a computer. A screen reader reads the page aloud or sends it to a braille display (a device with pins that form braille letters); common ones are NVDA and JAWS on Windows, VoiceOver on Mac and iPhone, TalkBack on Android and Narrator on Windows. Others use screen magnifiers (zoom 400% or more), voice control ("click Submit"), switch access (one or two big buttons that step through controls) or only the keyboard.
- 3
Assistive tech doesn't read your pixels. The browser builds an accessibility tree from your HTML: a simplified copy of the DOM where every useful node has a role (what it is: button, link, heading), a name (what it's called: "Submit"), a state (checked, expanded, disabled) and a value. Screen readers read that tree. A
<button>gets the role button for free; a<div>styled to look like a button gets nothing. That is why semantic HTML (Phase 2) is the base of accessibility. - 4
WCAG (Web Content Accessibility Guidelines), from the W3C, is the shared rulebook. The current version is WCAG 2.2 (October 2023). It is organised under four principles, POUR: Perceivable (people can sense the content: alt text, captions, contrast), Operable (they can use it: keyboard, enough time, no seizures), Understandable (clear language, predictable behaviour, helpful errors) and Robust (works with current and future assistive tech: valid, correct roles and names).
- 5
Each rule, called a success criterion, has a level: A (the minimum; without it some people can't use the page at all), AA (the standard target, and the level most laws reference) and AAA (the highest; not required for whole sites because some content can't meet it). Examples: 1.1.1 Non-text Content (A) needs text alternatives for images; 1.4.3 Contrast Minimum (AA) needs a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text; 2.1.1 Keyboard (A) needs everything to work from a keyboard; 2.5.8 Target Size Minimum (AA, new in 2.2) needs click targets of at least 24 by 24 CSS pixels or enough space around them.
- 6
There is a legal case: the Americans with Disabilities Act and Section 508 in the US, the European Accessibility Act (in force for many products and services since 28 June 2025, pointing to the EN 301 549 standard, which builds on WCAG), the UK Equality Act, and India's Rights of Persons with Disabilities Act 2016 with the government's GIGW guidelines. Lawsuits over inaccessible sites happen every year. There is also a business case: more customers, better SEO (search engines read the same headings, alt text and link text), fewer support calls, and code that is easier to test. And there is the simplest case: it is the right thing to do.
Explain it without notes
What is the accessibility tree, and why does it matter which HTML element you choose?
What do the four POUR principles mean? Give one example of each.
What is the difference between WCAG levels A, AA and AAA, and which level do teams usually target?
Give three reasons a business should invest in accessibility.
Practice
Write the HTML for a newsletter sign-up with one email field and a button so that a screen reader announces the field's name and the button's name. Make the page language English.
Using the contrast function from the first example, check #ffffff text on a #1a73e8 blue button. Does it pass AA for normal text?
Trade-offs
- ↔
Targeting AAA everywhere limits colour palettes and media choices; AA is the practical standard, with AAA applied where it is cheap (e.g. body text contrast).
- ↔
Accessibility work at design time costs a little extra thought on every component; fixing it after launch costs rework, retesting and sometimes legal fees.
Done when you can
I can name the main groups of disabilities and the assistive tech people use.
I can explain the accessibility tree: role, name, state.
I can explain POUR and the difference between A, AA and AAA.
I know the AA contrast rules: 4.5:1 for normal text, 3:1 for large text and UI parts.
I can list the six most common failures and fix each in HTML.