QuestionsAccessibility

Semantic HTML & landmark regions

Semantic HTMLEasyAccessibility

Why prefer <nav>, <main>, <button> over <div>s? What do landmarks give a screen-reader user?

What it tests

Whether you reach for the element that carries built-in semantics before adding ARIA.

Approach & answer

Semantic elements come with a role, keyboard behaviour, and state for free — a <button> is focusable, fires on Enter/Space, and exposes the 'button' role; a <div> you turn into a button gives you none of that until you add tabindex, key handlers, role, and aria-pressed by hand. Landmark elements — <header>, <nav>, <main>, <aside>, <footer>, <section> with a label, <form> — build a structural map of the page. Screen readers expose a landmarks rotor so a user can jump straight to 'main' or 'navigation' instead of tabbing through everything, the way a sighted user's eye skips to the content. The guiding principle is 'the first rule of ARIA': if a native element with the semantics and behaviour you need exists, use it rather than repurposing a generic element with an ARIA role. There should be exactly one <main>, and landmarks that repeat (multiple <nav>s) should be distinguished with aria-label so they read as 'primary navigation' vs 'footer navigation'. Semantic markup is also the substrate everything else stands on: alt text, headings, and labels only help because the element they describe already has a meaningful role.

Use this technique when

Choosing markup for any component; justifying why native elements beat div+ARIA reconstructions.

Code

<!-- Reconstructed from divs: no role, no focus, no keyboard, no landmarks -->
<div class="btn" onclick="save()">Save</div>
<div class="top-bar">...</div>

<!-- Semantic: roles, focus, keyboard, and a landmark map for free -->
<header>...</header>
<nav aria-label="Primary">...</nav>
<main>
  <button type="button" onclick="save()">Save</button>
</main>
<footer>...</footer>

References