What is it?
Semantic HTML means picking tags that describe what content is, not
what it should look like. A <button> is for actions, a <nav> wraps
navigation, an <article> is a self-contained piece of content. Browsers,
screen readers, and search engines all read semantic markup differently
than <div> soup.
Why it matters
Hiring managers spot semantic HTML before they spot framework choices. It tells them you think about users beyond the visible viewport — keyboard users, screen reader users, search crawlers. It also gives you free browser behavior (focus rings, form submission, in-page search) that nobody has to write or maintain.
What to learn
- Document landmarks:
<header>,<nav>,<main>,<aside>,<footer> - Content containers:
<article>,<section>,<figure>,<figcaption> - Heading hierarchy: one
<h1>per page, then<h2>→<h6>in order - Interactive elements:
<button>vs<a>(and when each is right) - Lists with meaning:
<ul>,<ol>,<dl>and when description lists fit - The HTML spec's content model — what tags are allowed inside what
Common pitfall
Using <div onclick> instead of <button> for interactive UI. Buttons
are keyboard-focusable, screen-reader-announced, and respond to Enter and
Space for free. A clickable div needs four extra attributes plus
JavaScript to match — and most teams forget two of them.
Resources
Primary (free):
- MDN — Semantics in HTML · docs
- HTML5 Doctor — Element flowchart · article
- web.dev — HTML basics for accessibility · docs
Practice
Take any landing page you've built — yours or a clone — and audit it tag
by tag. Replace every <div> with the most specific semantic element
that fits. Run WAVE or the browser's
accessibility tree inspector. Done when WAVE reports zero structural
errors.
Outcomes
- Pick the most specific semantic tag for any UI element.
- Build a page with a valid heading hierarchy from a single
<h1>. - Read the accessibility tree in devtools and spot missing landmarks.
- Argue against
<div>soup with concrete reasons (keyboard, AT, SEO).