Who accessibility is for
Accessibility means that people can use your page whatever their abilities and whatever device they use. A person who is blind uses a screen reader. A person with a tremor may use only a keyboard or a switch. A person with low vision zooms to 400 per cent or uses high-contrast mode. A person who is deaf needs captions. A person with a cognitive difference needs clear language and layout. And on any day, anyone can be in bright sunlight, holding a baby in one arm, or on a slow connection.
Doing this well is also a legal requirement in many countries and, usually, simply good engineering. The good news is that most accessibility is just correct HTML.
1. Use the right elements
The previous lessons were accessibility lessons in disguise:
- Real headings (
h1–h6) in order, so people can navigate by them. - Real lists, tables with
th, and landmarks (header,nav,main,footer). buttonfor actions andawithhreffor navigation. Adivwith a click handler gets no keyboard focus, no Enter key support and no role.labelon every form control.
Native elements arrive with behaviour, focus handling and meaning for assistive technology. Rebuilding them from div boxes means recreating all of that by hand, usually badly.
2. Text alternatives for images
<img src="chart.png" alt="Bar chart: sales rose from 40 to 65 units between January and June">
<img src="divider.png" alt="">- Informative images need alt text that conveys the same information, not "image of…".
- Decorative images get
alt=""so screen readers skip them. - If the image is a link or button, the alt describes the destination or action ("Go to home page").
- Complex charts need a longer description in the page text.
3. Keyboard access and focus
Put your mouse aside and press Tab. Can you reach every link, button and field? In a sensible order? Can you see where you are? Does Enter or Space activate things, and Escape close pop-ups?
- Never remove the focus outline (
outline: none) without replacing it with something equally visible. - Do not trap focus: a dialog should keep focus inside while open but be closable by Escape.
- Provide a skip link as the first thing in the body, so keyboard users can jump past the menu:
<a href="#main" class="skip">Skip to main content</a>
<header>…</header>
<main id="main">…</main>4. Colour and contrast
- Normal text needs a contrast ratio of at least 4.5:1 against its background (WCAG level AA); large text (about 24px or 19px bold) needs 3:1.
- Never use colour as the only signal: "fields in red are required" excludes people with colour blindness. Add text, icons or patterns.
- Support zoom: do not disable pinch zoom or use fixed pixel heights that clip text.
Free tools such as browser DevTools' contrast checker show the ratio of any text.
5. Media
- Videos need captions; audio needs a transcript.
- Nothing should flash more than three times a second.
- Do not autoplay sound.
6. ARIA, used carefully
ARIA (Accessible Rich Internet Applications) is a set of attributes such as role, aria-label and aria-expanded that add information for assistive technology. Its first rule: if a native HTML element does the job, use it. A <button> beats <div role="button" tabindex="0"> plus the scripts to make it behave.
When you do need it, for example an icon-only button:
<button type="button" aria-label="Close menu">✕</button>
<button type="button" aria-expanded="false" aria-controls="menu">Menu</button>
<ul id="menu" hidden><li><a href="#">Home</a></li></ul>ARIA changes only how things are announced, not how they behave or look. Wrong ARIA is worse than none.
7. Plain language and layout
Short sentences, plain words, a consistent layout and clear link text help everyone. Write the language in <html lang>, and mark foreign phrases with lang as well: <span lang="hi">नमस्ते</span>.
Testing your pages
- Keyboard test: use only Tab, Shift+Tab, Enter, Space and Escape.
- Zoom to 200–400 per cent; nothing should be lost or overlap.
- Automated checkers (Lighthouse in Chrome DevTools, axe, WAVE) catch roughly a third of problems quickly.
- Screen reader test: VoiceOver on Mac and iPhone, TalkBack on Android and NVDA on Windows are free. Even five minutes teaches a lot.
- Real users with disabilities are the best test of all.
Common mistakes
- Clickable
divandspanelements. alt="image"or alt text repeating the visible caption.- Removing focus outlines.
- Low-contrast grey text on white.
- Information conveyed only by colour or position.
- ARIA stuffed everywhere to patch bad HTML.
Exercise
Fix the problems in this snippet: a clickable div, an image with no alt, and a placeholder-only field.
<div onclick="save()">Save</div>
<img src="team.jpg">
<input placeholder="Email">Show one possible answer
<button type="button" onclick="save()">Save</button>
<img src="team.jpg" alt="The five-person design team standing in front of the office" width="800" height="450">
<label for="email">Email</label>
<input type="email" id="email" name="email" autocomplete="email">Key points
- Accessible HTML lets people with visual, hearing, motor and cognitive differences use your page, and it helps everyone else too.
- Most accessibility comes from using the right element: real headings, lists, buttons, links and labels.
- Every meaningful image needs useful alt text; decorative images get an empty alt.
- Everything must work with a keyboard alone, with a visible focus indicator and enough colour contrast.
- ARIA fills gaps only when no native element exists; the first rule of ARIA is to not use ARIA if HTML can do it.