A11y & SEO: The ROI of Semantic HTML in 2026

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.

---

This is Part 2 of our Modern Triad series. Read Part 1: The Modern Web Triad.