HTML Accessibility Fundamentals

Accessibility means building pages that people using screen readers, keyboard-only navigation, voice control, or other assistive technology can use just as effectively as anyone else. Much of accessibility isn't a separate skill layered on top of HTML — it's simply the result of writing correct, semantic HTML in the first place.

Why it matters

Around one person in six lives with a disability, and many more use a keyboard, a small screen or a slow connection. An inaccessible site shuts them out and, in many countries, breaks the law. Most accessibility comes free from using the right HTML elements, which is why it is treated as a core skill and not as an extra.

Semantic Structure as the Accessibility Foundation

Screen readers build a navigable model of a page from its underlying structure: heading levels, landmark elements (<nav>, <main>, <header>), lists, and form labels. A page built from correctly chosen semantic elements is, by default, far more accessible than one built entirely from generic <div> and <span> elements with visual styling standing in for structure.

Text Alternatives and ARIA Basics

Every meaningful image needs descriptive alt text, as covered in HTML images. When native HTML elements and attributes can't fully express a UI pattern's role or state — a custom tab widget or an expandable accordion, for example — ARIA (Accessible Rich Internet Applications) attributes like role, aria-label, and aria-expanded can fill the gap. The first rule of ARIA, though, is to prefer a native HTML element over an ARIA-patched generic one whenever possible — a real <button> is more robust than a <div role="button"> that must have keyboard handling added manually.

• alt — required text alternative for meaningful images.
• aria-label — provides an accessible name when visible text isn't sufficient or present.
• aria-expanded — communicates whether a collapsible element is currently open or closed.
• role — declares an element's purpose when no native element expresses it, used sparingly.

Keyboard Navigation

Every interactive element — links, buttons, form controls — must be reachable and operable using only a keyboard, without requiring a mouse. Native elements like <a>, <button>, and <input> handle this automatically (they're focusable via Tab and activatable via Enter or Space by default). Custom interactive widgets built from non-interactive elements lose this behavior entirely unless it's added back manually, which is another strong reason to prefer native elements.

Example

<button aria-expanded="false" aria-controls="details-panel" id="toggle-btn">
  Show Details
</button>
<div id="details-panel" hidden>
  <p>Additional details appear here once expanded.</p>
</div>

Displays a "Show Details" button; when JavaScript toggles aria-expanded to "true" and removes the hidden attribute, screen readers announce the button as expanded and the panel content becomes available to all users, including keyboard users tabbing to the button.

Exercise

The page below has three accessibility faults: a clickable div that cannot be reached or activated with the keyboard, an image with no text alternative, and an input with no label. Fix all three using native HTML.

Expected result: the Save control is a real button that logs Saved to the console when activated with the mouse or the keyboard, the logo has the alternative text WebNest Studio, and the field has the visible label Search.

<img src="logo.png">

<div onclick="console.log('Saved')">Save</div>

<input type="text" name="q">

<img src="logo.png" alt="WebNest Studio">

<button type="button" onclick="console.log('Saved')">Save</button>

<label for="q">Search</label>
<input type="text" id="q" name="q">

Quick quiz

Interview questions