Semantic HTML Is a Shared Language for Accessibility, SEO, and AI

Bertrand Morel — Tue, 18 Aug 2026 19:55:28 +0000

A page can look perfectly clear and still be structurally ambiguous.

Visual design gives sighted users powerful clues: size, color, spacing, position, icons, and motion. Those clues weaken or disappear when the same page is read through an accessibility tree, parsed by a crawler, checked by an audit tool, or extracted by an AI system.

That is where semantic HTML matters. It does not guarantee a ranking, an AI citation, or accessibility compliance. It does something more fundamental: it reduces how much every reader has to guess.

An accessible page is first a page that is more reliable to interpret. That is a clarity advantage, not an automatic visibility promise.

One page, four different readers

The same interface exposes different signals depending on who—or what—is reading it.

Reader	Signals it uses	Common source of ambiguity
Sighted user	Visual hierarchy, labels, spacing, position, feedback	A polished interface with vague actions or discreet errors
Screen reader	Accessibility tree, roles, names, landmarks, heading and focus order	Unnamed buttons, fake headings, vague links, unmanaged focus
Search crawler	Rendered HTML, links, headings, main content, canonical rules, structured data	Late content, orphan pages, confused hierarchy, weak anchor text
AI or extraction system	Extractable text, sections, entities, context, sources, evidence	Generic blocks, implicit relationships, disconnected proof

The overlap is not “optimization for machines.” It is explicit communication.

The tempting claim—and the useful mechanism

Semantic HTML is often wrapped in promises that go too far:

No: accessibility guarantees better Google rankings.
Yes: accessibility can make a page more robust to parse, audit, and understand.
No: ARIA and semantic HTML are a GEO strategy.
Yes: a clear document structure supports content, entities, links, and evidence that other systems can use.
No: valid markup proves that a journey is accessible.
Yes: valid markup creates a stronger foundation for human testing.

The practical mechanism is ambiguity reduction. A heading should not have to be inferred from a large font. A button should not have to be inferred from an icon. A data table should not have to be reconstructed from visual alignment.

A card that looks fine but says very little

Consider a service card with a heading, an icon, an email field, and a submit action.

<div class="card" onclick="location.href='/audit'">
  <div class="big">Accessibility audit</div>
  <img src="/icon-check.svg">
  <input placeholder="Your email">
  <button><svg><!-- ... --></svg></button>
</div>

A sighted user may reconstruct the intent from the layout. Other readers receive a weaker model:

the visual heading is not a heading;
the card behaves like a link but has no link semantics;
the image has no defined role;
the field has no persistent label;
the button has no accessible name;
click behavior is not equivalent to a clear form submission.

Now make the relationships explicit:

<article aria-labelledby="accessibility-audit-title">
  <h3 id="accessibility-audit-title">Accessibility audit</h3>

  <img src="/icon-check.svg" alt="" aria-hidden="true">

  <p>
    Identify keyboard, form, and HTML structure blockers.
  </p>

  <form action="/audit/request" method="post">
    <label for="audit-email">Work email</label>
    <input
      id="audit-email"
      name="email"
      type="email"
      autocomplete="email"
      required
      aria-describedby="audit-email-help"
    >
    <p id="audit-email-help">
      We will use this address only to answer your request.
    </p>
    <button type="submit">Request the audit</button>
  </form>

  <a href="/audit/accessibility">
    Read the accessibility audit method
  </a>
</article>

The second version does not merely “add accessibility attributes.” It describes the content, action, destination, and input relationship in native HTML.

Notice what it does not do: it does not add ARIA to elements that already have the right semantics. Native HTML carries most of the model.

Nine signals that reduce structural ambiguity

This is not a complete WCAG audit. It is a compact structural layer that can reveal weak pages quickly.

1. A coherent title, H1, and heading outline

The browser title, H1, and H2s should describe the same subject. Do not use heading elements to obtain a visual size, and do not use styled div elements as headings.

2. One identifiable main region

Use a single main for the page's primary content. Add native landmarks such as nav, header, footer, and aside where their roles are real and useful.

3. Links that retain meaning outside their paragraph

“Read the WCAG audit method” carries a destination. Five links named “learn more” force every reader to rebuild context.

4. Buttons named after their actual action

Use labels such as “Open filters,” “Close dialog,” or “Submit the audit request.” An icon may support the label; it should not be the only source of meaning.

5. Image alternatives based on purpose

An informative image needs an alternative that communicates what it adds. A decorative image should use an empty alternative and stay out of the accessibility tree.

6. Form fields connected to labels, help, and errors

A placeholder is not a label. Connect persistent labels and relevant help text, and ensure that error messages identify both the problem and the correction.

7. Tables reserved for actual data

When a table expresses a comparison or a dataset, use headers and captions that let cells be understood without relying on position alone. Do not use tables for page layout.

8. A declared document language

The lang attribute affects pronunciation, assistive technologies, lexical interpretation, and text-processing tools. Mark genuine changes of language inside the page as well.

9. A DOM order that remains logical without CSS

If the page loses its meaning when read in DOM order, the design is hiding a structural weakness. Visual reordering should not create a different story from source order.

The 20-minute structural readability test

Choose one important page—a service page, signup path, contact form, or documentation entry—and check the following:

Time	Check	Evidence to collect
3 min	Read only the title and heading outline	The subject and major sections remain understandable
3 min	Inspect landmarks and DOM order	One `main`; navigation and secondary regions are distinct
3 min	List links and buttons without surrounding text	Every destination and action remains understandable
4 min	Use the page with a keyboard	Focus is visible, logical, and never trapped or lost
4 min	Inspect the accessibility tree	Headings, controls, names, roles, and states match the interface
3 min	Compare visible content with JSON-LD	Entities and claims do not contradict what the page shows

This test is deliberately short. Its purpose is to find pages that need deeper investigation, not to issue a compliance claim.

What automation still cannot prove

Lighthouse, axe, WAVE, HTML validators, and custom scripts are excellent at repeatable checks. They can report a missing label or an unnamed button. They cannot reliably decide whether:

the chosen label makes sense to the intended user;
the error message helps someone complete the form;
the heading structure reflects the real information hierarchy;
keyboard order matches the task;
an image alternative communicates the right information;
structured data accurately represents the visible claim.

A strong review therefore combines at least four layers:

automated rules;
DOM and accessibility-tree inspection;
keyboard and assistive-technology testing;
a real end-to-end journey.

Automation gives coverage. Human testing gives meaning.

Where SEO and AI actually fit

Clear HTML is not a shortcut to visibility. Search and AI visibility depend on many other factors: usefulness, sources, evidence, entities, internal links, reputation, indexability, and the systems that choose which documents to retrieve or cite.

Semantic structure prepares a lower layer. Before asking whether a page deserves to be ranked, extracted, or cited, make sure its content and actions can be read without reconstructing them from appearance.

The useful question is not:

“Will semantic HTML make an AI cite this page?”

It is:

“How much meaning disappears when the page is read without its visual design?”

That question produces better interfaces for people first—and more reliable documents for every other reader.

AI-assistance disclosure: this DEV edition was adapted from my original Edikka article with AI assistance for structure and English editing. The technical positions, examples, verification, and publication decision remain my responsibility.

DEV Community: Bertrand Morel