Semantic HTML: Which Tags to Use and Why It Matters

What semantic HTML is

Semantic HTML means a tag describes what a piece of content is, not how it looks. A page header is a <header>, a menu is a <nav>, a button is a <button>. CSS handles appearance; HTML handles meaning.

If everything is built from <div> and <span>, the browser sees the page as a pile of unnamed boxes. A sighted user may not notice, but a screen reader, a search crawler and the next developer will.

The core tags and when to use them

A simple rule: a link goes somewhere, a button does something.

Before and after

Div-based markup:

<div class="header">
  <div class="logo">Shop</div>
  <div class="menu">
    <div onclick="go('/catalog')">Catalog</div>
  </div>
</div>
<div class="content">
  <div class="post">
    <div class="title">Autumn arrivals</div>
    <div class="btn" onclick="like()">Like</div>
  </div>
</div>

The same page, semantic:

<header>
  <a href="/">Shop</a>
  <nav>
    <a href="/catalog">Catalog</a>
  </nav>
</header>
<main>
  <article>
    <h2>Autumn arrivals</h2>
    <button type="button" onclick="like()">Like</button>
  </article>
</main>

Roughly the same amount of code, far more meaning.

Why button beats div

A <div onclick> looks like a button but isn't one. To make it behave like a real button you'd have to add by hand:

• tabindex="0" so it can be reached with Tab;
• handling for Enter and Space;
• role="button" so a screen reader announces it as a button;
• focus styles and a disabled state.

<button> gives you all of this for free. The same goes for <a href>: a real link opens in a new tab, can be copied and gets crawled; a div that navigates via JavaScript does none of that.

What semantics gives you in practice

• Accessibility. Screen readers build a map of the page from tags: users can jump straight to main or the navigation, or skim headings.
• Maintainability. <nav> and <article> read faster than div.wrapper-2, so new developers get up to speed sooner.
• Parsing. Search engines, browser reader modes and other parsers rely on structure to find the main content.
• Less JavaScript. Native elements already handle focus, keyboard input and form submission.

Common mistakes

• Several <main> elements on one page. There should be one visible main.
• <section> as a generic wrapper. If a block has no heading of its own and exists only for styling, use <div>.
• Headings chosen by size. Pick <h3> for its nesting level, not because it's smaller. Size belongs in CSS.
• A button inside a link, or a link without href. Both break keyboard navigation.
• Missing type on a button in a form. By default a <button> inside a <form> submits it.

How to check your markup

1. Turn off CSS and see whether the page structure still makes sense.
2. Navigate the page with the keyboard only: Tab, Enter, Space.
3. Open the accessibility panel in browser DevTools and check element roles.
4. Use the element reference on MDN.