Short answer: Semantic HTML means using each HTML element for what it means, not for how it looks: header, nav, main and footer for the parts of a page, h1 to h6 for headings, button for buttons. Browsers turn that meaning into the accessibility tree that screen readers read.
What semantic HTML means
In web.dev’s words, semantic means “relating to meaning,” and semantic HTML structures content by what each element means, not by how it looks.
MDN gives the h1 as an example: it tells the browser that its text is the top level heading of the page. You can make any element look like a heading, but it won’t carry that meaning. In MDN’s words, presentation is the sole responsibility of CSS.
How browsers and screen readers use it
web.dev explains that the browser builds the document object model and the CSS object model, and then an accessibility tree. Screen readers use that tree, which web.dev calls a semantic version of the DOM.
The header and footer elements become the banner and contentinfo landmarks when they aren’t nested in other landmarks. Screen reader users can move between them, and our screen reader guide walks through it.
The elements that carry the most meaning
| Element | What it tells browsers and screen readers | Use it for |
|---|---|---|
| header | The page banner, when it isn’t inside another landmark | Logo and site menu |
| nav | A block of navigation links | The primary menu, named when there are several |
| main | The main content of the page | One per page |
| footer | The page footer, when it isn’t inside another landmark | Contact details and legal links |
| h1 to h6 | Headings that build the page outline | Usually one h1, then h2 to h6 without skipping levels |
| ul, ol | A list without an order, or with one | Features, menus and steps |
| button | A control that does something, ready for the keyboard | Opening a menu or sending a form |
From WebAIM, web.dev and MDN, read November 5, 2026.
Not every group of links needs a nav, WebAIM notes, and when a page has more than one nav, each should get its own aria-label.
When a div is fine and when it isn’t
web.dev calls div and span elements with no semantic value. They’re fine for layout and styling, as long as the meaning sits in the elements around them.
A div used as a button loses the keyboard access a real button has, and its default styling, as MDN notes. Adding them back takes a tabindex, a role and script for the keys.
A real button already works: people can reach it with Tab and press it with Space, Return or Enter. Our what is ARIA guide covers when a role is the right tool.
How to check your pages
- Check that each page has one main and, like most pages, one header and one footer.
- Check that there’s one h1 and that the headings below it don’t skip levels; the first one has its own H1 tag guide.
- Check that every control is a button element and every link is an a element with an href.
- Check that lists of items are ul or ol elements, not paragraphs that start with a symbol.
- If a page has more than one nav, make sure each carries its own aria-label.
- Open the accessibility tree in your browser’s developer tools and read the landmarks and headings it lists.
- Test the page with the keyboard and a screen reader; for the keyboard part, see our keyboard navigation guide.
What we found on our own pages
On November 5, 2026, we looked at how our home page, one of our guides and our contact page are built, in both languages, at desktop and phone widths. Each view had one banner, one main and one footer landmark. Each had one h1 as its first heading, with no skipped levels below it.
Every link had an href, no div or span acted as a button, and every image carried an alt attribute. At desktop width, the home page still uses 162 div elements, and they carry layout, not meaning.
One name was missing. On a computer, a guide offered four navigation landmarks: three had names, Breadcrumb, Table of contents and Legal, but the header menu had none. We named it “Primary”, as in WebAIM’s example, and not a single pixel of the pages changed.
Before you publish
- Each page has one main, plus one header and one footer at page level.
- The page has a single h1 and no skipped heading levels.
- Buttons are button elements and links are a elements with an href.
- Lists are marked up as lists.
- Each nav has its own name when there’s more than one.
- No div or span stands in for a control.
RememberPick each element for what it means and let CSS handle the look. The meaning in your markup is what browsers and screen readers read.
We build every page on this structure in our web design service.
Quick answers about semantic HTML
What is semantic HTML?
Using HTML elements for what they mean, not for how they look: a button element for a button, nav for a menu, h2 for a section title. web.dev defines it as structuring content based on each element’s meaning, not its appearance.
Why does semantic HTML matter for accessibility?
Browsers turn semantic elements into the accessibility tree that screen readers read. A real button can be reached with Tab and pressed with Space, Return or Enter without extra code, as MDN explains. A div styled as a button gets none of that.
Is it wrong to use div elements?
No. A div has no meaning, so it’s fine for layout. If a div stands in for a button, a heading or a list, assistive technologies don’t know what it is, and you have to rebuild its behavior yourself.
How many h1 headings should a page have?
WebAIM says a page should typically have only one h1, which describes the page as a whole and should be similar to its title. The h2 to h6 headings that follow form an outline, so don’t skip levels going down the page.
Should every group of links be a nav element?
No. WebAIM suggests nav mainly for the primary navigation, not around every list of links. When a page has more than one nav, give each its own aria-label, such as Primary or Breadcrumb, so screen reader users can tell them apart.
Sources
Read on November 5, 2026. MDN Web Docs: Semantics and HTML: A good basis for accessibility. web.dev: Semantic HTML. WebAIM: Semantic Structure: Regions, Headings, and Lists. Our case: our own pages, read in a browser on November 5, 2026.