Semantic HTML for Accessibility

Introduction

Semantic HTML is the highest-ROI accessibility investment: native elements carry implicit roles, keyboard behavior, and form associations browsers expose to assistive technology without ARIA. Staff engineers reject div-soup component APIs that recreate button semantics poorly.

Business problem

Component libraries wrapping everything in div+role="button" accumulate keyboard and SR bugs — each custom widget is a WCAG 4.1.2 liability. Semantic HTML reduces maintenance cost and audit surface.

• Velocity myth: Div soup feels faster until a11y bugs block launch.
• Design systems: Must document when to use button vs a vs native dialog.

Why this feature exists

HTML living standard defines semantic elements (main, article, section, nav, button, details) so user agents implement consistent accessibility mappings — ARIA spec explicitly says prefer native semantics first.

• Landmarks: main, nav, header, footer — SR landmark navigation.
• Headings: h1–h6 outline — not styled p tags.
• Lists: ul/ol/li for grouped navigation and content.

Browser internals

Implicit roles: button → role button, input type=checkbox → checkbox. Browser handles Space/Enter activation on button — div needs tabindex=0 + keydown JS often buggy.

• Sectioning: article vs section — article is self-contained; affects SR document structure.
• Heading levels: Skipping h2→h4 creates confusing outline — not invalid HTML but bad UX.

Rendering workflow

Page skeleton first: html lang → skip link → header/nav → main (one per page) → footer. Build features inside landmarks before adding CSS framework wrappers.

• One main: Multiple main landmarks confuse SR — validate in axe.
• Buttons vs links: a href navigates; button submits/performs action — never interchange.

Feature deep dive

Semantic replacements for common anti-patterns:

• div onclick → button or a href for navigation.
• div modal → dialog with showModal() — focus trap built-in.
• div expand → details/summary — keyboard included.
• table layout → CSS grid — keep table only for tabular data with th scope.

<nav aria-label="Account">
  <ul>
    <li><a href="/profile">Profile</a></li>
    <li><a href="/orders" aria-current="page">Orders</a></li>
  </ul>
</nav>
<main>
  <article>
    <h1>Order #12345</h1>
    <table>
      <caption>Line items</caption>
      <thead><tr><th scope="col">Item</th><th scope="col">Qty</th></tr></thead>
      <tbody>...</tbody>
    </table>
  </article>
</main>

Accessibility analysis

Semantic HTML satisfies multiple WCAG criteria at once: 1.3.1 structure, 2.1.1 keyboard on native controls, 4.1.2 name/role/value without custom ARIA state sync.

• SR test: Rotor landmarks — should show one navigation, one main.
• Validator: html-validate or similar for landmark uniqueness rules.

SEO impact

Google Search uses headings and semantic structure for content understanding — same elements SR users rely on. article, time datetime benefit both.

• Micro benefit: Proper th scope helps table content indexing marginally.

Security considerations

Semantic forms with proper action/method enable CSRF token patterns — semantic clarity aids security review. Link vs button confusion can trigger accidental navigation on Enter in wrong element.

Performance impact

Native dialog/details avoid heavy JS focus libraries — smaller bundles, better INP. Semantic lists don't affect perf vs divs meaningfully.

Real production example

Design system rule: ESLint plugin bans onClick on div — enforce button/a:

• Docs: Decision tree: navigation? → a. Action? → button. Toggle panel? → button + aria-expanded.

// eslint-plugin-jsx-a11y + custom rule
// ❌ <div onClick={submit}>Pay</div>
// ✅ <button type="submit">Pay</button>

Enterprise usage

BBC, GOV.UK design systems lead with semantic HTML patterns — GOV.UK elements are reference implementations for accessible markup.

• CMS: Restrict WYSIWYG to semantic tags — no font tags, no empty headings.

Common production failures

All-div product grid — SR users hear flat text blob. Fake h tags via class="h1" — outline tools show no structure. Link styled as button causing middle-click opens new tab unexpectedly.

Architecture review questions

• Are interactive elements button or a — not div/span with handlers?
• Exactly one main landmark per page?
• Heading hierarchy reflects content outline?
• Tables used only for data with th scope?
• Lists used for grouped nav/items?

Hands-on project

Project: Convert marketing landing from div layout to landmarks + semantic headings + real buttons — axe before/after comparison.

Interview questions

Try it yourself

Edit the HTML, CSS, or JS panels — the preview updates as you type.

Summary

Semantic HTML for accessibility delivers implicit roles, keyboard support, and structure to assistive technology — staff engineers ban div-soup interactive patterns and enforce landmarks, headings, and native controls in design systems.