Accessibility in HTML

Analogy categoryAnalogies

Introduction

Web accessibility means building pages that people with disabilities can perceive, navigate, and interact with, whether they use a screen reader, keyboard-only navigation, voice control, or magnification tools. HTML has accessibility built in when used correctly: semantic elements, alt text, labels, and ARIA attributes work together to expose meaning to assistive technology (AT). The Web Content Accessibility Guidelines (WCAG) provide the standard for what 'accessible' means.

🏏

Cricket analogy: WCAG is like the ICC's official playing conditions rulebook, a shared standard that ensures every match is playable fairly, whether the player uses a screen reader or a keyboard.

Syntax

html

<img src="chart.png" alt="Revenue increased 20% year-over-year">

<label for="email">Email address</label>
<input type="email" id="email" name="email" required>

<button aria-label="Close dialog">&times;</button>

<nav aria-label="Main navigation">
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/contact">Contact</a></li>
  </ul>
</nav>

Explanation

The alt attribute gives screen reader users a text alternative for images; it should describe the image's purpose, not just its appearance, and be left empty (alt="") for purely decorative images. The <label> element, associated with an input via matching for/id attributes, ensures screen readers announce the field's purpose and expands the clickable target. ARIA (Accessible Rich Internet Applications) attributes like aria-label and aria-labelledby supplement HTML when there is no visible text, such as an icon-only close button. Proper heading order (h1 through h6, without skipping levels) lets screen reader users navigate a page's outline the way sighted users skim visually.

🏏

Cricket analogy: Leaving alt="" on a purely decorative border image is like a commentator skipping mention of the ground's flower beds, irrelevant detail that would only clutter the broadcast.

Example

html

<form>
  <fieldset>
    <legend>Contact preferences</legend>
    <label>
      <input type="checkbox" name="newsletter">
      Subscribe to newsletter
    </label>
  </fieldset>
  <button type="submit">Save preferences</button>
</form>

<a href="#main-content" class="skip-link">Skip to main content</a>

Output

With correct markup, a screen reader announces the form's fieldset legend before reading each control, announces 'checkbox, not checked, Subscribe to newsletter', and lets a keyboard user tab through the skip link, form controls, and submit button in a logical order. Without these features, the same page might read as an unlabeled list of unnamed inputs, making it unusable for someone relying on assistive technology.

🏏

Cricket analogy: A well-run form is like a stadium PA announcing 'Powerplay overs, fielding restrictions in effect' before naming each fielder's position, context first, details after, in logical order.

Common accessibility mistakes to avoid: omitting alt attributes on informative images (screen readers fall back to reading the filename); using placeholder text as a substitute for a real <label>, which disappears once the user starts typing; relying on color alone to convey meaning (e.g., red text for errors with no icon or text cue); using non-semantic <div>/<span> elements with onclick handlers instead of real <button> or <a> elements, which breaks keyboard and screen reader support; and skipping heading levels (jumping from h1 to h4), which disorients screen reader navigation.

Key Takeaways

Always provide meaningful alt text for informative images; use alt="" for decorative ones.
Associate every form input with a <label> using matching for/id attributes.
Use ARIA attributes only to supplement HTML, not replace native semantics.
Maintain a logical, non-skipping heading hierarchy (h1-h6).
Ensure all interactive elements are reachable and operable via keyboard alone.