Semantic buttons and the accessibility tree

When an AI agent visits your site, it doesn’t see your design. It reads the accessibility tree — the same structured representation a screen reader uses. Every element shows up with a role and a name, or it shows up as nothing useful. That’s where most sites lose agents on the very first screen.

The div-as-button problem

A button styled from a <div> works for a person. They see something that looks clickable, and they click it. To an agent reading the accessibility tree, that div has the role generic. No role that says “button,” no accessible name, nothing that says it does anything. The agent skips it.

Swap the same control for a real <button> with text inside, and the agent reads button "Book now". Now it knows what the element is and what it does. The same goes for links: a <span> with a click handler is invisible, while an <a href> with clear text is a navigable link.

Why it matters now

UC Berkeley measured agent task success on real pages. On poorly structured pages it fell from 78% to 42% — about half the tasks failed because the agent couldn’t tell what to act on. For years that was an accessibility statistic businesses ignored, because the affected users were a small slice of traffic. Agents make it everyone’s problem, and the cost shows up as lost bookings. These are the same seven rules Google published for agent-friendly sites, and every one is ordinary accessibility.

The fix

• Use <button> for actions and <a href> for navigation. Not divs, not spans.
• Give every control real text, or an aria-label if it’s icon-only.
• Don’t strip focus outlines.
• If you use a page builder, check what it actually outputs — many render styled divs by default.

Scan your site to see how your buttons and links read to an agent, or start with the full guide.