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.
Top comments (2)
The “ambiguity reduction” framing is much more defensible than treating semantic HTML as a GEO lever. I’d keep your 20-minute structural test separate from the outcome score, though. In a scan we ran across 284 Korean DTC brands and 50 AI shopping questions per brand, 65.5% had zero appearances and the mean was only 0.648 out of 50. That sparsity means a page can become easier to parse without producing a measurable citation change. Would you add an extraction check to the test, then track mention/citation as a separate downstream layer rather than folding either into the structural audit?
ngl i still see so many sites using divs for everything... really makes you realize how much we rely on visual cues alone