Semantic HTML and accessibility

Structure a page with the right elements so browsers, search engines, keyboards and screen readers all understand it.

Semantic HTML

What: Using elements for their meaning: header, nav, main, article, button, a, h1 to h6, ul, table, instead of generic div and span for everything.
Why: Semantic elements come with built in keyboard support, focus, roles and search engine meaning for free. A real button fixes most accessibility bugs before they start.

HTML

<header>
  <nav aria-label="Main">
    <a href="/products/">Products</a>
  </nav>
</header>
<main>
  <h1>Running shoes</h1>
  <button type="button">Add to basket</button>
</main>

Watch out

A clickable div with an onclick: it cannot be focused or activated with Enter or Space.

Accessible forms

Also called label, form validation

What: Every input has a visible label tied to it with for and id (or by nesting), the right type and autocomplete, and errors linked with aria-describedby so screen readers announce them.
Why: Labels give inputs an accessible name and a bigger click target, and correct types bring the right mobile keyboard and browser autofill.

HTML

<label for="email">Email</label>
<input id="email" name="email" type="email"
  autocomplete="email" required
  aria-describedby="email-error">
<p id="email-error">Enter a valid email address.</p>

Watch out

Using placeholder as the only label: it disappears while typing and is often too low contrast.

Alt text

What: The alt attribute describes what an image communicates. Decorative images get an empty alt="" so assistive technology skips them.
Why: Screen reader users hear the alt text instead of the image, and it shows when an image fails to load.

Watch out

Leaving alt off entirely, so screen readers read the file name aloud.

Keyboard navigation and focus

Also called tabindex, focus management, focus-visible, keyboard navigation

What: Everything interactive must be reachable with Tab in a logical order and show a visible focus style. Dialogs move focus in and return it when closed.
Why: Keyboard users, switch users and many screen reader users cannot use a mouse. The native dialog element handles focus for you when opened with showModal().

Watch out

Removing outlines with outline: none and adding no :focus-visible style, so keyboard users lose track of where they are.

ARIA

Also called WAI-ARIA, aria-label, role

What: Attributes such as role, aria-label, aria-expanded and aria-live that add or override accessibility information where HTML alone cannot express it.
Why: Needed for custom widgets like tabs, menus and live status messages. The first rule of ARIA is not to use it when a native element already does the job.

Watch out

Adding role="button" to a div and forgetting you now also owe it focus and Enter and Space key handling.

Headings and landmarks

What: One h1 per page and headings in order without skipping levels, plus landmark elements (header, nav, main, footer) that outline the page.
Why: Screen reader users jump between headings and landmarks to scan a page, the same way sighted users skim. It also helps search engines understand structure.

Colour contrast

Also called WCAG contrast

What: WCAG AA asks for a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text and interface parts such as input borders and focus rings.
Why: Low contrast text is unreadable for people with low vision and for everyone on a phone in sunlight. DevTools and Lighthouse report it.

Watch out

Signalling state with colour alone, such as a red border for an error with no text or icon.

Go deeper