<article>
  <header>
    <h1>How to Build Accessible Forms</h1>
    <time datetime="2026-03-15">March 15, 2026</time>
    <address>By Jane Doe, <a href="mailto:jane@example.com">jane@example.com</a></address>
  </header>
  <section aria-labelledby="intro-heading">
    <h2 id="intro-heading">Introduction</h2>
    <p>Forms are the most common interactive element on the web...</p>
  </section>
  <section>
    <h2>Labeling Inputs</h2>
    <p>Every input needs a <code>&lt;label&gt;</code>...</p>
    <figure>
      <figcaption>Example of a labeled input</figcaption>
      <pre><code>&lt;label for="email"&gt;Email address&lt;/label&gt;
&lt;input type="email" id="email" /&gt;</code></pre>
    </figure>
  </section>
  <footer>
    <p>Tags: <a href="/tags/accessibility">accessibility</a>, <a href="/tags/forms">forms</a></p>
  </footer>
</article>

Accessibility: Why Screen Readers Depend on Semantic HTML

Screen readers like NVDA and VoiceOver use the accessibility tree — not the DOM directly. The accessibility tree is built from elements that have a semantic role. A <div> with class 'button' has no role unless you add role="button". But a <button> element already has the 'button' role, plus keyboard interaction expectations (Enter/Space to activate, focus styles).

Semantic elements come with built-in ARIA roles, keyboard handling, and browser defaults. For example: - <nav> automatically gets role='navigation' and is listed in landmarks. - <main> gets role='main' and screen readers offer a 'skip to main content' shortcut. - <h1>-<h6> automatically get heading roles at appropriate levels. - <table> automatically has grid role with row/column semantics.

When you overwrite these with <div> plus ARIA, you often introduce bugs: missing ARIA properties, misaligned focus management, or inconsistent behaviour across browsers. Semantic HTML is more robust because browsers have tested the native elements for decades.

Use ARIA only when a native semantic element does not exist — for example, a progress bar (role="progressbar") or a tab interface (role="tab").

// Quick test to check if your page has semantic landmarks
(function checkLandmarks() {
  const landmarks = [
    'header', 'nav', 'main', 'aside', 'footer',
    '[role="banner"]', '[role="navigation"]', '[role="main"]',
    '[role="complementary"]', '[role="contentinfo"]'
  ];
  const present = landmarks.filter(sel => document.querySelector(sel)).length;
  if (present < 3) {
    console.warn('Your page has fewer than 3 semantic landmarks. This will confuse screen readers.');
  } else {
    console.log(`Good: ${present} semantic landmarks found.`);
  }
})();

SEO: How Search Engines Interpret Semantic Markup

Google, Bing, and other search engines parse HTML structure to understand content hierarchy and relevance. Semantic HTML directly influences rich snippets, featured snippets, and page ranking.

• <article> tells Google this is a self-contained piece of content — often used for blog posts in Google News and Discover.
• <nav> signals the primary navigation, helping Google understand site structure for sitelinks.
• <header> and <footer> are used for page-level metadata extraction.
• Proper heading hierarchy (<h1>-<h6>) is one of the strongest on-page SEO signals. Search engines use it to infer the main topic and subtopics. An <h1> is the page title equivalent.
• <time> with datetime helps extract publication dates for news search and freshness signals.
• <figure> and <figcaption> help associate images with descriptions, improving image search ranking.

A common mistake: using multiple <h1> elements or skipping heading levels. Google's algorithm devalues content that doesn't follow a logical outline.

Semantic HTML also improves Core Web Vitals indirectly — cleaner markup means smaller DOM size, faster parsing, and better performance scores.

<article itemscope itemtype="https://schema.org/Recipe">
  <h1 itemprop="name">Classic Margherita Pizza</h1>
  <time datetime="2026-04-10" itemprop="datePublished">April 10, 2026</time>
  <p itemprop="description">A simple, authentic Neapolitan pizza...</p>
  <section>
    <h2>Ingredients</h2>
    <ul>
      <li itemprop="recipeIngredient">500g pizza dough</li>
      <li itemprop="recipeIngredient">200g San Marzano tomatoes</li>
    </ul>
  </section>
  <section>
    <h2>Instructions</h2>
    <ol itemprop="recipeInstructions">
      <li>Preheat oven to 250°C...</li>
    </ol>
  </section>
  <figure itemprop="image">
    <img src="pizza.jpg" alt="A freshly baked Margherita pizza" />
    <figcaption>Final result</figcaption>
  </figure>
</article>

Common Semantic HTML Mistakes and How to Fix Them

Even experienced developers make these errors. Here are the most frequent ones:

1. Using <br> for line breaks inside a paragraph — should use separate <p> elements or CSS display block.
2. Using <b> and <i> instead of <strong> and <em> — they look the same but convey no emphasis meaning.
3. Using <div class='nav'> instead of <nav> — you lose the navigation landmark.
4. Multiple <main> elements — only one allowed per document.
5. Nesting <section> inside <aside> incorrectly — sections should be for thematic grouping, not general containers.
6. Omitting alt text on <img> — not exactly a semantic element issue, but related: every <img> must have an alt attribute conveying its function.
7. Using <blockquote> for indentation — <blockquote> is for quoted content, not visual styling. Use CSS padding or margin.
8. Using <div> for interactive elements — always prefer <button>, <a>, <input>, <select>.

<!-- BEFORE: Non-semantic mess -->
<div class="article">
  <div class="title">Tips for Java 25</div>
  <div class="meta">Posted on 15 March 2026</div>
  <div class="content">
    <div class="section">
      <span class="heading">Performance</span>
      <span class="text">New GC algorithms...<br>Test with ZGC</span>
    </div>
  </div>
</div>

<!-- AFTER: Semantic structure -->
<article>
  <h1>Tips for Java 25</h1>
  <p><time datetime="2026-03-15">Posted on 15 March 2026</time></p>
  <section>
    <h2>Performance</h2>
    <p>New GC algorithms...</p>
    <p>Test with ZGC</p>
  </section>
</article>

Why Your Document Outline Is Probably Broken

You've carefully nested your <article> inside <section> inside <main>. Looks clean. But run it through an outline checker and your entire hierarchy collapses into flat text. That's because screen readers and browsers build their navigation from heading levels - not from <section> or <article> tags. They respect <h1> through <h6> as the only signal for content importance.

A common mistake: using <section> as a generic wrapper and skipping heading levels because 'it looks right.' But when a blind user tabs through your page, they hear 'heading level 3' followed by 'heading level 1' - which tells them your content structure is broken. The fix is brutal simplicity: maintain a strict heading hierarchy. Start every document with one <h1>. Nest <h2> under it, then <h3> under that. Never use a heading just for styling; that's what CSS exists for.

I've seen production incidents where a last-minute design change added an <h2> between existing <h1> and <h3> elements - and nobody noticed until the accessibility audit flagged it. The fix took 30 seconds and prevented a lawsuit.

// io.thecodeforge
<!-- Good outline -->
<main>
  <h1>Product Documentation</h1>
  <section>
    <h2>Installation Guide</h2>
    <p>Steps below assume macOS Sequoia.</p>
    <article>
      <h3>Quick Start</h3>
      <p>Run the installer, accept defaults.</p>
    </article>
  </section>
</main>

<!-- Bad outline - flat hierarchy -->
<main>
  <section>
    <h2>Product Documentation</h2>
  </section>
  <article>
    <h2>Installation Guide</h2>
  </article>
</main>

The Figure Element Isn't Just for Images

Every team I've joined eventually has the debate: 'Should we wrap this chart in a <div> or a <figure>?' The answer is always <figure> - but not for the reason most think. The <figure> element is a semantic container for content that is referenced from the main flow but could be moved without breaking the narrative. That includes images, sure, but also code blocks, pull quotes, diagrams, and even tables.

Paired with <figcaption>, you tell the browser: 'This block is a self-contained unit with a label.' Screen readers announce both the content and its caption together. Search engines treat the caption as metadata for the enclosed content. The practical upshot: when a user copies your chart into a report, the caption follows automatically.

I once debugged a production issue where an interactive D3 chart was wrapped in a <div> with an aria-label. The label worked for screen readers, but the chart's SVG metadata was invisible to search engines. Moving it to <figure> with a <figcaption> solved both problems with zero code changes to the chart itself.

// io.thecodeforge
<article>
  <h2>2024 Revenue Breakdown</h2>
  <p>Subscription revenue grew 12% YoY, driven by enterprise tiers.</p>
  
  <figure>
    <figcaption>Figure 3: Quarterly Revenue by Segment (2024)</figcaption>
    <table>
      <thead>
        <tr><th>Q</th><th>Subscriptions</th><th>Services</th></tr>
      </thead>
      <tbody>
        <tr><td>Q1</td><td>$2.4M</td><td>$1.1M</td></tr>
        <tr><td>Q2</td><td>$2.7M</td><td>$1.3M</td></tr>
      </tbody>
    </table>
  </figure>
  
  <p>Enterprise subscriptions now account for 65% of recurring revenue.</p>
</article>

Details and Summary: The Collapsible You've Been Spamming

You've written that custom collapsible component three times this month. Each time: a button, a div with display:none, some JavaScript to toggle a class, and an ARIA attribute to make it work. Stop. HTML5 gives you <details> and <summary> - native, accessible, zero-JS collapsible sections.

<details> creates the wrapper. <summary> provides the visible label. When clicked, the <details> toggles an 'open' attribute that the browser uses to show or hide the content. Screen readers get the announcement for free. Search engines index the content regardless of whether it's collapsed - because the DOM always contains the full content.

I've seen a production outage caused by a custom accordion that failed to render on mobile Safari. The fix: replace 150 lines of custom JS with a <details> element. It worked everywhere, instantly. The only caveat: you cannot animate the open/close transition natively (yet). If your designer insists on a slide animation, use CSS grid with grid-template-rows: 0fr to 1fr - no JavaScript needed.

// io.thecodeforge
<details>
  <summary>Why semantic HTML matters for performance</summary>
  <div class="content">
    <p>Semantic elements reduce DOM complexity by eliminating wrapper divs. Browser rendering engines parse them faster because they convey structural intent directly.</p>
    <ul>
      <li>Less CSS specificity battles</li>
      <li>Smaller bundle sizes</li>
      <li>Faster paint times</li>
    </ul>
  </div>
</details>

<style>
  details[open] .content {
    animation: fadeIn 0.3s ease-in;
  }
  @keyframes fadeIn {
    from { opacity: 0; }
    to { opacity: 1; }
  }
</style>