Semantic HTML: The Accessibility and SEO Payoff of Getting Tags Right

We took over a booking flow last year where the “Continue” control was a <div> with a click handler, a cursor: pointer and a background colour. It worked fine for everyone using a mouse. It was invisible to keyboard users, unreachable in the VoiceOver rotor, and when the client’s legal team ran an accessibility audit, that single element generated four separate WCAG failures: no name, no role, not focusable, no keyboard activation.

The fix was deleting the div and typing <button type="button">. Eleven characters of real work. That ratio, trivial effort against disproportionate payoff, is why semantic HTML keeps coming back as a topic even though the tags themselves have been stable since 2014.

What has changed by 2026 is who reads your markup. It used to be browsers, screen readers and Googlebot. Now it’s also Reader Mode, Safari’s summarisation, half a dozen LLM crawlers running Readability-style extraction, and whatever your own RAG pipeline is doing to your docs. All of them use the same heuristics: find the main content, find the headings, ignore the boilerplate. Div soup fails all of them at once.

Semantic HTML is a contract with the accessibility tree

When a browser parses your page it builds the DOM, then derives a second structure from it: the accessibility tree. Each node in that tree carries a role (what kind of thing this is), an accessible name (what it’s called), and states and properties (expanded, checked, disabled, required). Assistive technology reads that tree, not your CSS.

Native elements come pre-wired. <button> arrives with role=button, a name computed from its text content, focusability, Enter and Space activation, and a default type=submit inside forms. To reproduce that with a div you need role, tabindex="0", keydown handlers for two separate keys, and a disabled state you have to invent yourself. People do it. It is almost always the wrong choice.

Open Chrome DevTools, Elements panel, Accessibility pane, and look at what your markup actually produces. This is the single most useful habit I can recommend. It turns an abstract argument about tags into a concrete list of nodes labelled “generic”. If your page is a wall of generic, nothing downstream can make sense of it.

A worked example of how brittle this gets. Everyone resets list bullets:

/ Safari + VoiceOver: this removes the list semantics entirely /
ul.nav-links {
  list-style: none;
  padding: 0;
}

<!-- restore them explicitly -->
<ul class="nav-links" role="list">
  <li><a href="/work">Work</a></li>
</ul>

That role="list" looks redundant and reviewers will flag it. It isn’t. Safari drops the list role when list-style is none, so VoiceOver stops announcing “list, 5 items”, and users lose the count they were using to decide whether to skim or step through.

The SEO payoff is real, but not where the listicles put it

Wrapping your content in <article> and <section> does not improve rankings. Google has said this more or less every time it’s been asked, and nothing in a decade of our own client data contradicts it. If a post tells you to add <aside> for SEO, close the tab.

What does get used:

• Heading text and hierarchy. Headings are a documented input to understanding page structure, and they are where featured snippets and “jump to” links come from. Our list-type H2s get pulled into snippets constantly. Styled divs never do.
• Link text. Anchor text is a ranking input for the target page. “Read more” is a wasted signal and a terrible screen reader experience simultaneously.
• Tables. Properly marked up tables with a <caption> and header cells feed comparison snippets. A grid of divs does not.
• Main content detection. Search engines and extraction tools strip boilerplate before they index. <main>, <nav>, <footer> and <header> make that trivial instead of probabilistic.

Here’s the free test for that last point. Open your article page in Safari and hit Reader Mode, or Firefox’s reader. If it refuses to activate, or it activates and swallows your pull quotes and headings, your markup is failing the same class of heuristic that LLM crawlers and your competitors’ scrapers use. Fixing it is usually one <main> and one <article>. If you’re also feeding your own content into a retrieval pipeline, that same structure is what lets you chunk by heading instead of by arbitrary character count, which matters more than most people realise once you start building retrieval over your own docs.

Structured data is a separate layer. JSON-LD does the work semantic tags are often credited with: author, publish date, product price, FAQ entities. Use both. Don’t expect <time datetime> to produce a date in the SERP, because the datePublished in your JSON-LD is what gets read.

Which HTML5 semantic elements actually earn their keep

Not all of them pull their weight. Here’s how I rank them after a few hundred builds.

Always worth it

<main>, one per page, as the skip-link target. <nav> for each navigation block, each with a label when there’s more than one. <header> and <footer> at page level, which map to banner and contentinfo landmarks only when they are not nested inside sectioning content. <button>, <a>, <label>, <table>, <fieldset>. These are load-bearing.

<a class="skip-link" href="#main">Skip to content</a>

<nav aria-label="Primary">...</nav>
<nav aria-label="Breadcrumb">...</nav>

<!-- tabindex="-1" is required or Chrome and Safari won't move focus here -->
<main id="main" tabindex="-1">...</main>

Worth it with a condition attached

<section> earns its role only with an accessible name. Without one it exposes nothing, and you’ve added a landmark-shaped element that isn’t a landmark. Name it from its own heading:

<section aria-labelledby="pricing-h">
  <h2 id="pricing-h">Pricing</h2>
  ...
</section>

Don’t name twenty of them. Six to eight landmarks on a page is navigable. Twenty-five is noise, and screen reader users will abandon the landmark rotor and go back to headings, which is what the WebAIM survey has shown they mostly prefer anyway.

Mostly decorative

<aside>, <hgroup>, <mark>, <article> on pages that aren’t articles. <strong> and <em> are the interesting case: most screen readers don’t announce them at default verbosity, so their value is semantic honesty for future readers and extraction tools, not an audible difference today. Use them correctly. Don’t expect applause.

Interactive patterns: where div soup actually hurts

Static content tolerates sloppy markup. Interactive components do not, because that’s where role and state have to stay in sync with what’s on screen.

Three rules that have saved us the most rework:

1. If it navigates, it’s an <a href>. If it acts, it’s a <button>. A button that navigates breaks middle-click and Cmd-click. A link that submits a form breaks expectations and gets prefetched by browsers, which is how we once had a “Delete” link fire on hover.
2. Always set type on buttons inside forms. The default is submit. A toggle button with no type will reload your page, and you’ll spend twenty minutes blaming your framework.
3. Use <dialog> and <details> before you write JavaScript. dialog.showModal() gives you focus trapping, an inert background, Escape to close and a top-layer backdrop, supported across all current browsers since Safari 15.4 in 2022. <details name="faq"> gives you an exclusive accordion with zero script.

<button type="button" data-open="signup">Sign up</button>

<dialog id="signup" aria-labelledby="signup-h">
  <h2 id="signup-h">Create an account</h2>
  <form method="dialog">
    <button value="cancel">Cancel</button>
  </form>
</dialog>

<script>
document.querySelector('[data-open="signup"]')
  .addEventListener('click', () => signup.showModal());
</script>

Where this advice stops applying: genuinely complex widgets. Combobox with async filtering, a multi-select tree, a data grid with roving tabindex. There’s no native element for those, so you build to the ARIA Authoring Practices and you test with NVDA, JAWS and VoiceOver, because the APG patterns are specs, not guarantees of support. The decision to build one of those should be deliberate. We get there far less often than clients expect, which is the same instinct behind shipping the HTML first and layering behaviour on top.

Forms: where accessible HTML pays off fastest

Forms are the highest-value markup on most commercial sites, and they’re where I see the most damage. A placeholder is not a label. It vanishes on input, it fails contrast in nearly every design system I’ve reviewed, and it leaves the field nameless in the accessibility tree.

<form action="https://webforms.to/submit/YOUR_ID" method="POST" novalidate>
  <label for="email">Work email</label>
  <input
    id="email"
    name="email"
    type="email"
    autocomplete="email"
    required
    aria-describedby="email-hint email-err"
    aria-invalid="false">
  <p id="email-hint">We'll only use this to reply.</p>
  <!-- populate and flip aria-invalid on validation; keep the node in the DOM -->
  <p id="email-err" role="alert"></p>

  <button type="submit">Request access</button>
</form>

Four things doing real work there. for/id pairing makes the label a click target and the field’s accessible name. type="email" changes the mobile keyboard. autocomplete="email" satisfies WCAG 1.3.5 and measurably reduces abandonment on phones. And role="alert" on an error container that already exists in the DOM means the message gets announced when you fill it, which is more reliable across screen readers than inserting a new alert node.

That endpoint is WebForms, which is what we point static builds at so a contact form doesn’t drag a backend along with it. The markup above is the whole integration. Note novalidate: browser-native validation bubbles are inconsistently announced, so once you’re handling errors yourself, turn them off rather than running two competing systems.

Auditing this in an afternoon

Run these in order. Each one takes minutes and finds a different class of bug.

1. Tab through the page. No mouse. Can you reach everything interactive, is the focus ring always visible, does the order match the visual layout, and does focus get trapped anywhere it shouldn’t? This finds more real blockers than any scanner.
2. Run axe DevTools or Lighthouse. Fast, near-zero false positives, and it catches missing names, contrast and alt problems. It won’t tell you your tab order is nonsense, which is why it’s step two and not step one.
3. Check the landmarks and headings list. VoiceOver rotor, or NVDA’s elements list. Read the headings aloud as a flat list. If they don’t describe the page like a table of contents, your heading levels are wrong. We lean on this hard when structuring landing pages, because a page that reads well as headings almost always converts better too.
4. Zoom to 400% and set a 320px viewport. Semantic, flow-based markup reflows. Absolutely positioned div grids explode.
5. Hit Reader Mode. Your free extraction sanity check, per the earlier section.

Frameworks are not an excuse here. Bootstrap 5 outputs reasonable elements if you use the documented components, and when we rebuilt the demo set for Canvas we went through the markup specifically to get buttons, labels and landmarks right, because a template’s HTML gets copy-pasted into a thousand projects and every shortcut multiplies. Utility-first CSS is where it slips: nothing in Tailwind stops you shipping a clickable div, and nothing warns you either.