Developer reviewing semantic HTML landmarks and page structure

What makes HTML semantic?

An element is semantic when its name communicates a role or relationship that matters to the document. A heading says that a section follows. A list says that items belong together. A button says that an action can be triggered. A generic div says much less; it is useful when the group has no more specific meaning.

The WHATWG HTML Standard defines the meaning and content model of the elements. Semantic markup is therefore more than a naming convention: it is information that browsers, developers, assistive technologies, and other tools can interpret.

  • Meaning: the element describes what the content is, not only how it looks.
  • Relationship: headings, lists, labels, and table headers connect information in a way tools can expose.
  • Behavior: native links, buttons, forms, and controls provide expected interaction semantics before custom code is added.
  • Scope: the markup communicates the structure that was actually delivered; it cannot describe content that is missing from the response.

Use landmarks to describe the page

Landmarks divide a page into major regions that people may want to navigate directly. Use header for introductory material, nav for a major navigation block, main for the dominant content, aside for complementary material, and footer for closing information. The W3C WAI page-regions guidance explains these regions and how labels help distinguish repeated navigation areas.

<body>\n  <header>\n    <a href='/'>Example Co.</a>\n    <nav aria-label='Primary'>...</nav>\n  </header>\n  <main>\n    <article>\n      <h1>Repairing a leaking tap</h1>\n      <p>Turn off the water before you begin.</p>\n    </article>\n    <aside aria-label='Related guides'>...</aside>\n  </main>\n  <footer>Contact details</footer>\n</body>

The example has a site header, a labelled primary navigation, one main region, a self-contained article, related content, and a footer. It does not claim that every page needs exactly this layout. Use only the regions that match the information architecture.

  • If the same landmark appears more than once, give each instance a label that tells the user how it differs.
  • Do not add aria-label merely to repeat a visible name or to make a generic container sound semantic.
  • A single main region is usually enough for a document's primary content.
  • A section should have a real thematic purpose and, when needed, an accessible name; it is not a styled div.

Prefer native elements for content and controls

The most practical semantic improvement is often choosing the native element that already matches the job. Replacing every div is not the goal. Avoid making a generic element pretend to be a control when a native element can supply the name, role, focus behavior, and keyboard expectations.

Less useful structure\n\n<div class='link' onclick='openGuide()'>Read the guide</div>\n<div class='button' onclick='saveForm()'>Save</div>\n\nMore truthful structure\n\n<a href='/guides/source'>Read the guide</a>\n<button type='button'>Save</button>

The second version communicates navigation and action directly. It still needs working destinations, visible focus, sensible names, and interaction testing, but the browser has a meaningful starting point. ARIA can fill a genuine gap; it does not automatically add the complete behavior of a native link or button.

  • Use p for a paragraph and headings for sections, not for text that only needs a larger font.
  • Use ul or ol when items are a list, with a list item for each entry.
  • Use table for data that has row or column relationships, and associate headers with the data they describe.
  • Use label with form controls so the purpose of an input is available beyond its visual placement.
  • Use figure and figcaption when a diagram or image has a caption that belongs with it.
  • Use a real link for navigation and a real button for an in-page action.

Treat headings as an information hierarchy

Headings help readers, browsers, and assistive technologies understand how content is organized. The W3C WAI headings tutorial recommends nesting heading ranks to reflect the page organization and avoiding confusing jumps where possible. A skipped rank is a signal to inspect the structure, not an automatic search penalty.

  • Give the page's main topic a clear H1.
  • Use H2 for major sections that sit under the page topic.
  • Use H3 and lower ranks only when a section contains a real subsection.
  • Write labels that still make sense when someone scans only the headings.
  • Use CSS for visual size; do not choose an H2 or H3 simply because it looks right.

For a source-order outline and a practical fix loop, use How to Check HTML Heading Structure. It is often more useful to improve an unclear section label than to change a level mechanically.

How semantic HTML relates to SEO

Meaningful HTML can make a document's content and relationships clearer to people maintaining it and to tools that parse the returned markup. That is a good engineering and accessibility practice. It is not a promise that replacing a generic container with a semantic element will raise rankings, make a page eligible for a search feature, or fix weak content.

Google's people-first content guidance puts usefulness, reliability, and the reader's purpose above content made only to attract search traffic. Keep the SEO question separate from the accessibility question: semantic HTML improves the structure you deliver, while search visibility also depends on content, links, crawlability, rendering, and other signals.

  • Source inspection can show whether the semantic elements were returned.
  • A live-DOM inspection can show whether scripts changed or replaced them.
  • Keyboard and assistive-technology testing can reveal whether the controls work as intended.
  • Search tools can verify different delivery and indexation questions; none should be inferred from the tag name alone.

Run a practical semantic HTML review

Review the markup in the same order a reader encounters the page: region, section, content, and interaction. Keep the conclusion tied to what you tested.

  • Start with View Source and identify the main content, navigation, and complementary regions in the returned HTML.
  • Check whether each landmark contains the content its name suggests and whether repeated landmarks have useful labels.
  • Run Heading Checker to read the H1-H6 outline in source order; inspect unusual levels in context.
  • Check links, buttons, forms, lists, tables, and images for native elements and meaningful names.
  • Use a keyboard to reach and operate interactive controls. A semantic element does not repair a hidden focus state or broken event handler.
  • Compare the live DOM when client-side code changes the document after load.
  • Record a specific finding such as “the returned HTML uses a div for a navigation control” rather than “the page is inaccessible.”

For the larger document model, continue with the HTML document structure guide. For a text-only review of one document, use HTML Extractor without treating its output as a complete semantic audit.

Frequently asked questions

Is a div always bad for accessibility?

No. A div is appropriate when a generic grouping is the honest description. The problem is using it to imitate a link, button, heading, list, or landmark while omitting the semantics and behavior people expect from the native element.

Does ARIA replace semantic HTML?

No. W3C's ARIA Authoring Practices treats ARIA as a way to communicate roles and states where needed, not as a reason to ignore native HTML. Prefer a native control when it already expresses the content or interaction, then test any ARIA pattern you add.

Is semantic HTML enough for accessibility?

No. It is one part of an accessible page. Names, contrast, focus visibility, keyboard operation, dynamic updates, error messages, language, and the actual user flow still need review.

Should every section have an H2?

A section should have a meaningful purpose and normally a heading when the user needs to understand it as a named part of the document. Do not add empty or keyword-only headings just to create a visual outline.

Does semantic HTML guarantee better rankings?

No. It can improve clarity and maintainability, but it cannot guarantee rankings, indexing, traffic, or a search feature. Judge the page using the evidence relevant to its actual purpose.

Sources

Continue exploring

Editorial note

SolViewer develops the tools linked in this guide. They are included when they help with the next practical step; they do not replace browser testing, official documentation, or professional review where those are needed.