HTML Accessibility

Web accessibility means anyone can use your site — including people who navigate by keyboard, use screen readers, have low vision, or process information differently. Most accessibility is achieved with plain HTML choices, not code. Google also considers usability signals (mobile-friendliness, structure) in ranking, so accessible HTML is doubly valuable.

The four principles (POUR)

1. Write meaningful text alternatives

<!-- ✅ Describes the image's purpose -->
<img src="chart.png" alt="Sales grew 40% between Q1 and Q4 2026">

<!-- ✅ Purely decorative: empty alt makes screen readers skip it -->
<img src="divider-flourish.svg" alt="">

<!-- ✅ Icon-only button needs an accessible name -->
<button type="button" aria-label="Close dialog">&times;</button>

2. Associate every input with a label

Recap from Forms: <label for="id"> must match the control's id. Placeholder text is not a label. Buttons need visible text or aria-label.

3. Keyboard operability

• Every interactive element must be reachable with Tab and activatable with Enter/Space.
• Native elements (<button>, <a>, <input>) are keyboard-accessible for free. A <div onclick> is not — this is the single biggest argument for semantic HTML.
• Provide a skip link as the first focusable element (see Semantic Layout).
• Never remove the focus outline without replacing it: :focus-visible { outline: 2px solid #4f46e5; }.

4. Structure with landmarks and headings

<header>...</header>
<main>
  <h1>Order summary</h1>
  <h2>Items (3)</h2>
  ...
</main>
<footer>...</footer>

Screen reader users jump between landmarks and skim headings instead of reading linearly. One h1, sequential levels, descriptive text — this is the same checklist SEO wants.

5. ARIA: the last resort, not the first

The first rule of ARIA: don't use ARIA when a native element does the job.

<!-- ❌ A div pretending to be a button: no focus, no Enter key, no role -->
<div class="btn" onclick="submitForm()">Send</div>

<!-- ✅ Native button: keyboard + screen reader support out of the box -->
<button type="button" onclick="submitForm()">Send</button>

<!-- ✅ ARIA used correctly: communicating state a native element can't -->
<button aria-expanded="false" aria-controls="menu-1">Menu</button>
<ul id="menu-1" hidden>...</ul>

When you do need ARIA, remember its three properties: role (what it is), aria-label/aria-labelledby (what it's called), aria-expanded/aria-pressed/aria-current (what state it's in).

6. Colour is never the only signal

<!-- ❌ "Red text = error" is invisible to many users -->
<p class="error">Invalid card number</p>

<!-- ✅ Icon + text + colour together -->
<p class="error" role="alert">⚠ Invalid card number — check the 16 digits.</p>

Also verify a contrast ratio of at least 4.5:1 for body text (3:1 for large text) — use a contrast checker when choosing colours.

7. Media accessibility

• Captions (<track>) for video audio — see Multimedia.
• Do not autoplay with sound.
• Give iframes a title.

Real-life use case

A government tender form built with semantic HTML: every field labelled, errors announced via role="alert", a skip link past the header, logical Tab order, and radio groups inside <fieldset>. Result: it passes accessibility audits and works for all 100% of its users — including employees using assistive tech.

Common mistakes

• Accessibility as a "phase 2" task — retrofitting is 10× harder than building in.
• Click-to-open divs — replace with <button> + aria-expanded.
• Empty links (icon-only <a> with no text) — add aria-label.
• Reading order ≠ visual order — CSS can reorder visuals while Tab order stays broken; test with keyboard only.
• Ignoring zoom — never set fixed small font sizes; support 200% browser zoom (WCAG requirement).

Best practices & testing checklist

• Unplug your mouse and Tab through the entire page.
• Turn on VoiceOver (Mac: Cmd+F5) or Narrator (Windows) and navigate by headings.
• Run Lighthouse's accessibility audit in Chrome DevTools (also flags contrast issues).
• Validate HTML — invalid markup is assistive-tech guesswork.
• Test at 200% zoom and with images disabled.

What's next?

Package all of this for search engines in HTML & SEO, then finish with Validation, Debugging & Next Steps.