Semantic HTML

Semantic HTML means using HTML elements according to their intended meaning (<nav> for navigation, <h1> through <h6> for headings, <button> for buttons), rather than styling generic elements to look like something they are not. Semantic HTML is the foundation of web accessibility because it tells browsers, search engines, and assistive technologies what each part of the content actually is.

Category: Accessibility (also: Front End, Web Development)

Author: Atomic Glue Team

## Definition

Semantic HTML is the practice of marking up content using HTML elements that carry inherent meaning about the structure and role of the content. A <button> element is semantically a button: it is focusable, clickable, activates on Enter and Space, and is announced correctly by screen readers. A <div> styled to look like a button has none of those properties unless the developer manually adds tabindex, role, keyboard handlers, and ARIA attributes. Semantic HTML goes beyond elements to include correct heading hierarchy (<h1> through <h6>), proper use of landmark elements (<nav>, <main>, <aside>, <footer>), ordered and unordered lists for grouped items, tables for tabular data only (not layout), and forms with properly associated <label> elements. The benefit is threefold: better accessibility, better SEO (Google parses semantics), and easier maintenance (code that says what it means is easier to understand and refactor).

## The accessibility tree starts with semantic HTML

Browsers build an accessibility tree from the DOM, and assistive technologies use this tree to present content to users. When you use semantic HTML, the browser automatically infers roles, states, properties, and relationships. A <table> with <th> elements automatically provides column and row relationships. A <form> element with properly associated <label> elements exposes the label as the accessible name of the input. A <button> is inherently interactive and keyboard accessible. When you substitute <div> and <span> with JavaScript event handlers, you strip all of this built-in semantic meaning and must recreate it manually, often imperfectly. Semantic HTML is the most efficient way to build accessible interfaces because the browser does most of the work for you.

## Common non-semantic patterns and their accessible replacements

<div onclick="..."> instead of <button>: lose keyboard accessibility, focusability, and built-in activation behaviour. Replace with <button>. <div class="heading"> instead of <h1> through <h6>: lose the heading role, keyboard navigation by heading, and SEO structure. Replace with proper heading tags. <div> for every section instead of <nav>, <main>, <aside>: lose landmark regions that screen reader users jump between. Use landmark elements. <table> for layout: screen readers announce the table structure and navigate cell by cell, which is confusing for layout content. Use CSS Grid or Flexbox for layout and reserve <table> for data tables. <span> for inline functional elements: use <a> for links and <button> for actions. <br> for paragraph spacing: use <p> for paragraphs. The pattern is the same: use the element that matches the meaning.

## In code

<!-- Non-semantic: everything is a div -->
<div class="nav">
  <div class="nav-item" onclick="goHome()">Home</div>
  <div class="nav-item" onclick="goAbout()">About</div>
</div>

<!-- Semantic: elements match their meaning -->
<nav aria-label="Main navigation">
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/about">About</a></li>
  </ul>
</nav>

<!-- Non-semantic: styled div as button -->
<div class="btn" onclick="submitForm()">Submit</div>

<!-- Semantic: native button -->
<button type="submit">Submit</button>

## Common questions

Q: Does semantic HTML really matter if my site works visually?

A: Yes. Your site may look correct to a sighted user but be completely unusable to a screen reader user. Semantic HTML is not about visual appearance. It is about meaning. A form that looks fine but lacks label-input associations forces a screen reader user to guess what each field is for. That is a WCAG violation and a real barrier.

Q: Can I use ARIA instead of semantic HTML?

A: ARIA is a supplement for when semantic HTML does not provide the needed semantics. It is not a replacement. Using role="navigation" on a <div> is more work than using <nav>, and you still need to ensure keyboard behaviour. Use the right element first, then add ARIA only when the element cannot express what you need.

## Key takeaways

• Semantic HTML uses elements according to their intended meaning, not their visual appearance.
• The browser and assistive technologies derive the accessibility tree from semantics.
• Using <div> for everything is the most common and most avoidable accessibility mistake.
• Buttons, headings, landmarks, lists, tables, and forms all have built-in semantics.
• Semantic HTML also improves SEO and code maintainability.

## Related entries

• [Landmark Elements](atomicglue.co/glossary/landmark-elements)
• [Heading Hierarchy](atomicglue.co/glossary/heading-hierarchy)
• [Accessible Forms](atomicglue.co/glossary/accessible-forms)
• [ARIA](atomicglue.co/glossary/aria)
• [Accessibility (a11y)](atomicglue.co/glossary/accessibility)

Last updated July 2026. Permalink: atomicglue.co/glossary/semantic-html-accessibility