Semantic HTML: structure that means something

In the last chapter we saw the browser turn HTML into a tree of elements, the DOM. This chapter is about choosing those elements well. Semantic HTML means using the element that says what a piece of content is, not just how it should look: a <nav> for navigation, a <button> for a button, an <h2> for a section heading. The page can look identical either way. What changes is everything the browser, a screen reader and a search engine can understand about it without guessing.

01What semantic HTML means

HTML has two kinds of elements. Some carry meaning: <h1> is the main heading, <ul> is a list, <a> is a link. Others carry none: <div> and <span> are plain boxes that only exist so you can group or style things.

web.dev's semantic HTML lesson makes the point with two versions of the same page. The first is all <div> and <span>, and you cannot tell from the code what any part of it is. The second uses <header>, <nav>, <main>, <section> and <footer>, and even someone who does not code can read its structure.

Here is the difference at a small scale:

<!-- Says nothing about what it is -->
<div class="top">
  <div class="title">Northlight Studio</div>
  <div class="menu"><a href="/work">Work</a></div>
</div>

<!-- Says exactly what it is -->
<header>
  <p class="logo">Northlight Studio</p>
  <nav><a href="/work">Work</a></nav>
</header>

Who reads the meaning

You see a styled page. Plenty of readers do not:

• Screen readers read the page aloud to blind and low vision visitors. They let people jump from heading to heading or straight to the navigation, but only if those things are marked up as headings and navigation.
• Browsers give real elements behaviour for free: links open in a new tab with a middle click, buttons respond to the keyboard, form fields get autofill.
• Search engines and AI tools use headings and structure to work out what a page is about and which part answers which question.
• Reader modes and translation tools rely on finding the main content and skipping the rest.

Semantic HTML costs nothing extra to write. It is the same number of tags, just the right ones.

02The elements that give a page its structure

A handful of elements describe the large regions of a page. Screen readers treat several of them as landmarks, places a visitor can jump to directly.

The definitions come from the HTML Standard's sections chapter, which is maintained by WHATWG and is the actual rulebook browsers follow. Two details from it trip people up. Not every group of links needs a <nav>: keep it for major navigation, not three links in a footer paragraph. And <section> is not a generic container: when you need a box only for styling, the standard says to use a <div>.

03Headings, paragraphs and lists

Headings are the most useful structure on any page. They form an outline that people scan by eye and that screen reader users move through by keyboard. MDN's page on heading elements gives three rules:

1. Prefer a single <h1> per page, the title of the page.
2. Do not skip levels. An <h2> is followed by <h2> or <h3>, never straight to <h4>.
3. Do not choose a heading to get a certain text size. Pick the level for its place in the outline and set the size in CSS.

The outline of a small studio page might look like this:

h1  Northlight Studio
  h2  About
  h2  Services
    h3  Brand identity
    h3  Websites
    h3  Photography
  h2  Contact

Text that is not a heading is a paragraph, <p>. A set of similar items is a list: <ul> when the order does not matter, <ol> when it does. A screen reader announces "list, three items", which tells the visitor how much is coming before they hear it. A row of <div> elements gives them nothing.

04Links, buttons and forms

This is where the wrong element hurts most, because these elements do things.

A link goes somewhere, a button does something

Use <a href="..."> when the result is a new page or a different place on the same page. Use <button> when the result is an action on this page: open a menu, submit a form, play a video.

The common failure is a clickable <div>:

<!-- Looks like a button, is not one -->
<div class="btn" onclick="openMenu()">Menu</div>

<!-- Is a button -->
<button type="button" class="btn" onclick="openMenu()">Menu</button>

The <div> works with a mouse and nothing else. As MDN's guide to HTML and accessibility explains, a real button can be reached with the Tab key and pressed with Space or Enter, and screen readers announce it as a button. To match that with a <div> you would need a role, a tab index and keyboard handlers, and you would still miss details. The <button> gives you all of it for one tag.

Forms need labels

Every form field needs a visible label tied to it with for and id. The label is read out when the field gets focus, and clicking it moves focus into the field, which helps on small screens.

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

The type="email" also brings up the right keyboard on phones, and autocomplete lets the browser fill it in. Placeholder text is not a label: it disappears as soon as someone starts typing.

Images need alternative text

An <img> needs an alt attribute. If the image carries information, describe that information in a short sentence. If it is purely decorative, use an empty alt="" so screen readers skip it. We go further into images, focus and colour in accessibility basics.

05Semantic HTML first, ARIA second

ARIA (Accessible Rich Internet Applications) is a set of attributes, such as role="button" or aria-expanded="true", that tell assistive technology what an element is or what state it is in. It is useful for things HTML has no element for, like tabs or a menu that opens and closes.

It is also easy to get wrong. The W3C's guide to ARIA practices opens with a page called Read Me First, whose first heading is "No ARIA is better than Bad ARIA". The reason: ARIA only changes what assistive technology is told. A <div role="button"> is announced as a button but still does not respond to the keyboard. Its role is a promise the code then has to keep.

So the order is: use the native HTML element if one exists. Add ARIA only for states and patterns HTML cannot express, and test it. For a full review of a live site, our website accessibility checklist goes through the rest.

<header>
  <p class="logo">Northlight Studio</p>
  <nav><a href="#about">About</a> <a href="#services">Services</a> <a href="#contact">Contact</a></nav>
</header>
<main>
  <h1>Brand and web design for small, independent shops</h1>
  <section id="about"><h2>About</h2><p>Two sentences about who you are.</p></section>
  <section id="services"><h2>Services</h2>
    <ul><li>Brand identity</li><li>Websites</li><li>Photography</li></ul>
  </section>
  <section id="contact"><h2>Contact</h2><p><a href="mailto:you@example.com">you@example.com</a></p></section>
</main>
<footer><p>© 2026 Northlight Studio</p></footer>