acqme.dev

Semantic HTML: The Invisible API for SEO and Accessibility

•5 min read

Introduction

Most developers treat HTML as a visual layout tool. If it looks right, it is right. We nest div inside div inside div until the UI matches the Figma file, slap a few click handlers on it, and call it a day.

This approach is fundamentally flawed.

HTML is not a visual language; it is a semantic one. It describes the meaning of your content, not its appearance. When you write standard "Div Soup," you are effectively shipping an application with no API documentation. You are forcing search engines, AI scrapers, and screen readers to guess what your content is.

In 2026, with the European Accessibility Act (EAA) deadline looming and AI search engines dominating traffic, semantic HTML is no longer a "nice-to-have" for purists. It is a critical business requirement.

The Invisible API: Understanding the Accessibility Tree

To understand why semantic HTML matters, you must look beyond the DOM. The browser doesn't just render pixels; it constructs a parallel structure called the Accessibility Tree.

This tree is what assistive technologies (like Screen Readers) actually consume. It strips away all visual information (colors, fonts, layout) and leaves only the semantic core:

  1. Role: What is this? (Button, Heading, Navigation)
  2. Name: What is it called? (Label, Alt Text)
  3. State: What is it doing? (Checked, Expanded, Disabled)

When you use a <button>, the browser automatically populates this tree:

  • Role: button
  • Name: (The text content)
  • State: focusable: true

When you use a <div onClick={...}>, the browser populates:

  • Role: generic
  • Name: (The text content)
  • State: focusable: false

You have effectively created a "ghost" element. It exists visually but is invisible to the API that matters most for compliance.

The Cost of "Div Soup"

I recently audited a React application where every interactive element was a div.

// The "Junior" approach
<div 
  className="btn-primary" 
  onClick={submitForm}
>
  Submit
</div>

To make this accessible, you need to add:

  1. tabIndex="0" (to make it focusable).
  2. role="button" (to tell screen readers it's a button).
  3. onKeyDown handler (to support Enter/Space keys).
  4. Focus styles (since standard divs don't show focus rings).

By the time you simulate a native button, you've written 20 lines of code to do what <button> does in one word.

The Landmark Map: Structuring for Navigation

Screen reader users rarely read a page from top to bottom. They "fly" over the page using Landmarks. These are major semantic regions that define the layout.

If you use <div> for your layout, the user sees a flat, featureless plain. If you use Landmarks, they see a map.

The Core Landmarks

  • <header>: The global site header (Logo, Navigation).
  • <nav>: Major navigation blocks.
  • <main>: The unique content of the specific page. (Crucial: There should be only one).
  • <aside>: Content tangentially related to the main content (Sidebars).
  • <footer>: Copyright, legal links.
  • <search>: The new standard for search forms.
<body>
  <header>
    <nav aria-label="Main">...</nav>
  </header>
  
  <div class="layout-wrapper">
    <main id="content">
      <h1>Page Title</h1>
      <!-- Unique content goes here -->
    </main>
    
    <aside>
      <nav aria-label="Related Articles">...</nav>
    </aside>
  </div>
  
  <footer>...</footer>
</body>

Senior Take: Notice the aria-label on the <nav> elements? If you have multiple navigation blocks (Header vs Sidebar), you must label them so the user knows which "Navigation" landmark they are jumping to.

The New Semantic Standard (2025+)

HTML is evolving. The spec isn't static, and new elements are introduced to replace common div + aria patterns.

The <search> Element

For years, we wrapped search forms in <form role="search">. As of late 2023, the <search> element is the standard.

<!-- DO: The Modern Standard -->
<header>
  <search>
    <form action="/search">
      <label for="site-search" class="sr-only">Search</label>
      <input type="search" id="site-search" name="q" />
      <button type="submit">Go</button>
    </form>
  </search>
</header>

This landmark element allows users to navigate directly to the search functionality using assistive technology, without the need for redundant ARIA roles.

The inert Attribute

Managing focus traps for modals used to be a nightmare of event listeners. The inert attribute simplifies this entirely. When you mark an element as inert, it is completely removed from the accessibility tree and cannot be focused.

// Managing Modal Focus
const mainContent = document.getElementById('main');
const modal = document.getElementById('dialog');

function openModal() {
  // The rest of the page is dead to the user
  mainContent.inert = true; 
  modal.showModal();
}

function closeModal() {
  mainContent.inert = false;
  modal.close();
}

SEO in the Age of AI

We used to optimize for keywords. Now, we optimize for context.

AI Search Engines (like Gemini and ChatGPT) don't just "crawl" text; they try to understand the structure of your data. If your blog post is a nested mess of divs, the AI struggles to distinguish the main content from the sidebar ads.

<article> vs <section>

This is the most common mistake I see in code reviews.

  • <section>: A thematic grouping of content. It usually has a heading. Think of it as a chapter in a book.
  • <article>: A self-contained composition that makes sense on its own. A blog post, a comment, a product card.
<main>
  <!-- The Blog Post is an Article -->
  <article>
    <h1>Semantic HTML Deep Dive</h1>
    <p>...</p>
    
    <!-- Comments are self-contained, so they are also Articles -->
    <section id="comments">
        <article class="comment">...</article>
        <article class="comment">...</article>
    </section>
  </article>
  
  <!-- The Sidebar is an Aside -->
  <aside>
    <h2>Related Posts</h2>
    <nav>...</nav>
  </aside>
</main>

By correctly nesting <article> tags, you tell the AI exactly which parts of the page are the "content" and which are just wrapper noise. This is "Schema markup for free."

Advanced Alt Text Strategy

"Add alt text" is junior advice. Senior engineers know that alt text is a decision tree, not a boolean requirement.

  1. Informative Images: Does the image add new information? (e.g., a chart, a screenshot of UI).
    • Action: Detailed description. alt="Bar chart showing 20% growth in Q4"
  2. Functional Images: Is the image inside a button/link? (e.g., a magnifying glass icon in a search button).
    • Action: Describe the action, not the image. alt="Search" (or better, use aria-label on the button and hide the icon).
  3. Decorative Images: Is it stock photography or background fluff?
    • Action: NULL alt text. alt="". This tells the screen reader to skip it entirely. If you omit the attribute, the reader might read the filename ("IMG_5920.jpg"), which is a terrible experience.

Trade-offs: When Semantics Break

Is strict semantic HTML always the answer? Not always.

1. The "Button vs. Link" Dilemma

Designers often want links that look like buttons and buttons that look like links.

  • Rule: If it goes to a new URL, it's an <a>. If it changes state on the current page, it's a <button>.
  • Trade-off: Sometimes frameworks (like Next.js Link) make this blurry. If you simply must style a link to look like a button, ensure the underlying semantics match the interaction model.
// The "Link that looks like a button" pattern
// Accessible because it's still an anchor tag
<a href="/login" className="bg-blue-500 text-white px-4 py-2 rounded">
  Login
</a>

// The "Button that looks like a link" pattern
// Accessible because it's still a button
<button onClick={logout} className="text-blue-500 underline bg-transparent border-none">
  Logout
</button>

2. Layout Elements

Sometimes you just need a box. Flexbox wrappers, Grid containers, visual decorations—these should be <div> or <span>. Don't force semantics where none exist. Using <section> for a CSS wrapper just to "be semantic" actually hurts accessibility because it creates noise in the document outline, making the "Landmap Map" cluttered and confusing.

Conclusion: Compliance is Coming

The European Accessibility Act (EAA) comes into full effect in June 2025. It mandates WCAG 2.1 AA compliance for e-commerce, banking, and essential services.

You have two choices:

  1. Spend thousands of dollars on accessibility overlays and remediation audits later.
  2. Write semantic HTML now.

Semantic HTML is the most cost-effective way to future-proof your application. It improves your SEO ranking, prepares your content for AI ingestion, and ensures you aren't legally liable for excluding users.

What to do next: Open your components/ui folder. Look at your primitive components. Are they built on divs or native elements? Refactor your Card component to use <article> and your Modal to use <dialog> today.

This is Part 2 of our Modern Triad series. Read Part 1: Back to Basics and stay tuned for Part 3: Advanced CSS Architectures.