How to Optimize the Accessibility Tree for AI Agents

A page can look perfectly usable and still describe its controls badly.

A blue rectangle looks like a button. A chevron looks like it opens an FAQ. A label beside an input appears to name the field. Those visual cues help a sighted person, but the browser cannot safely convert every styling choice into programmatic meaning.

The accessibility tree is where the browser exposes that meaning. A real button can appear with a button role and a useful name. A disclosure can report whether it is expanded. A form field can expose the label connected to it.

This matters to people using assistive technology first. It also matters to browser agents. Google's primary web.dev guidance for agent-friendly websites says modern agents can combine three representations: screenshots, raw HTML or the DOM, and the accessibility tree. The AX tree supplies structured interaction information while vision helps interpret layout and visual context.

What the Accessibility Tree Tells an Agent

The DOM records elements, attributes, text, and relationships. A screenshot records what the rendered page looks like. The AX tree is a browser-computed semantic summary.

A capable agent may identify a button in the AX tree, inspect its DOM relationship to a product card, and use a screenshot to confirm that a cookie banner is not covering it. That multi-modal model is why an AX audit should check agreement between structure, visible UI, and actual behavior.

It also separates this work from adjacent audits. A Common Crawl AI visibility audit checks public crawl presence. A JavaScript rendering audit for AI assistants checks what exists before and after rendering. An AX audit checks whether the browser exposes meaningful structure and actionable state. One pass does not prove the others.

Use Semantic HTML Before Adding ARIA

The first repair is usually ordinary HTML. A generic element dressed as a control forces every consumer to infer its purpose and forces developers to recreate browser behavior.

<!-- Bad: looks clickable, but has no native control semantics -->
<div class="cta" onclick="startCheckout()">Buy now</div>

<!-- Use a button for an in-page action -->
<button type="button" class="cta" onclick="startCheckout()">
  Buy now
</button>

<!-- Use a link for navigation -->
<a class="cta" href="/checkout/">Go to checkout</a>

A button performs an action in the current interface. A link navigates to a URL. Do not replace either with <span onclick>, or with <a href="#"> when no navigation occurs. A custom role="button" also needs focusability, Enter and Space handling, and visible focus behavior. Native <button> already supplies the base contract.

Forms deserve the same discipline. Use <form>, connect <label for> to an input ID, and prefer native <select> when its behavior fits the product. Placeholder text is not a durable label.

<form action="/search/" method="get">
  <label for="site-search">Search the site</label>
  <input id="site-search" name="q" type="search">

  <label for="topic">Topic</label>
  <select id="topic" name="topic">
    <option value="technical-seo">Technical SEO</option>
  </select>

  <button type="submit">Search</button>
</form>

MDN's semantics reference makes the principle clear: choose the element that communicates meaning, and let CSS handle presentation. ARIA remains useful for names, states, and relationships that native semantics do not fully express. It does not implement behavior.

Test Dynamic JavaScript States Before and After Interaction

FAQ accordions, tabs, filters, dialogs, and multi-step forms cannot be validated from the initial page state alone. Save a snapshot, operate the component, then save another.

Here is a compact accordion based on the W3C Authoring Practices accordion pattern:

<h3>
  <button
    type="button"
    id="shipping-trigger"
    aria-expanded="false"
    aria-controls="shipping-panel">
    Shipping details
  </button>
</h3>

<div id="shipping-panel"
     role="region"
     aria-labelledby="shipping-trigger"
     hidden>
  <p>Orders ship within two business days.</p>
</div>

<script>
  const trigger = document.querySelector('#shipping-trigger');
  const panel = document.querySelector('#shipping-panel');

  trigger.addEventListener('click', () => {
    const isOpen = trigger.getAttribute('aria-expanded') === 'true';
    trigger.setAttribute('aria-expanded', String(!isOpen));
    panel.hidden = isOpen;
  });
</script>

The test is not whether the attributes exist. The test is whether the interface tells one coherent story:

• The control has native button semantics and a useful name.
• aria-controls resolves to the real panel ID.
• aria-expanded changes from false to true.
• The panel's actual visibility changes with that state.
• Mouse, Enter, and Space activation work as expected.

Do not turn that into the claim that all collapsed content is invisible to all agents. Content can remain in the DOM, be excluded from the current AX state, be injected after a request, or become available after interaction. Test the exact implementation.

For product facts, eligibility requirements, pricing conditions, and an article's core answer, I would not make a successful optional interaction the only discovery path. Render essential decision content and use disclosures for added depth. That is a risk-control recommendation, not a universal rule against hidden panels.

Validate Hierarchy, Landmarks, and Fake Links

A page built from anonymous containers gives the browser less structure to work with. Start with one primary <main>, major <nav> groups, a coherent <article> where appropriate, one descriptive H1, and logical H2/H3 nesting.

<nav aria-label="Primary">
  <a href="/services/">Services</a>
  <a href="/insights/">Insights</a>
</nav>

<main>
  <article>
    <h1>Accessibility Tree Audit</h1>
    <section aria-labelledby="audit-process">
      <h2 id="audit-process">Audit process</h2>
      <h3>Inspect interactive controls</h3>
    </section>
  </article>
</main>

Give repeated navigation landmarks distinct names such as "Primary" and "Footer." Check source order when CSS grid or flexbox moves content visually. Find fake links implemented through JavaScript click handlers, and confirm every audited navigation action has a crawlable href.

These repairs do not turn weak content into a ranking winner. They remove structural contradictions that can block keyboard users and task-driven agents.

A Practical Accessibility-Tree Workflow

1. Inspect Chrome DevTools

Open DevTools, choose Elements, select a control, and open the Accessibility pane. Record its computed role, accessible name, state, ARIA relationships, ignored status, and corresponding DOM node. The official Chrome DevTools accessibility reference documents the full workflow.

Toggle Show accessibility tree to replace the DOM view with the full-page AX tree. Check landmark order, heading hierarchy, form labels, links, and buttons. Use the Source Order Viewer when visual order may differ from DOM order.

2. Capture an AXray baseline

AXray provides an independent extraction view with filtered and fuller tree outputs. It can also compare JavaScript-on and JavaScript-off results. Do not submit private, authenticated, or sensitive URLs to a third-party extractor.

John McAlpin's accessibility-tree article was useful practitioner inspiration for this audit model. I am crediting the idea, not importing its benchmark figures or its stronger ranking conclusion. The official sources do not support that conclusion.

3. Save interaction snapshots

Capture the initial state and every task-critical state after interaction. For an accordion, the before/after evidence should show a stable name, a changed expanded state, a valid relationship, and a panel that appears when expected. For a dialog or form step, add focus and keyboard sequence to the evidence.

4. Run experimental Lighthouse Agentic Browsing

Chrome's Accessibility for agents checks and Agentic Browsing scoring documentation provide a regression layer for labels, roles, relationships, and content hidden from the AX tree.

Do not relabel 7/9 as a score of 78. Keep the raw report and compare the same template after a release. I use the same separation in my article on llms.txt and Lighthouse Agentic Browsing: a browser-agent diagnostic can be useful without becoming a Google Search requirement.

5. Finish with a QA diff

Compare the original and fixed snapshots. Tie each repair to an acceptance condition: the control has the intended role, its name is distinct, its state updates, keyboard activation works, and the real task completes. A tree-only pass is incomplete.

Compare Competitor Templates, Not Their Copy

Competitor analysis can expose implementation gaps, but it cannot isolate why a page ranks or earns an AI citation.

Compare three to five pages serving the same intent and task. A product detail page belongs beside product detail pages, not a competitor homepage. Control for template type, page intent, logged-in state, location, and device width. Then record:

• landmark order and heading hierarchy;
• real links versus JavaScript navigation;
• control roles and accessible names;
• form labels and selected states;
• hidden-content behavior before and after interaction;
• JavaScript-on versus JavaScript-off differences;
• steps required to complete the same task.

Classify every result. "Our checkout trigger is an unnamed generic element" is a verified defect. "Three competitors use native buttons for variants" is an observation. "Native controls may reduce failed agent interactions" is a hypothesis.

Do not copy a competitor's structure simply because it ranks. Content, links, authority, brand demand, product data, and many other variables remain uncontrolled. Citation and ranking patterns are correlation, not causation.

This distinction matters most in commerce. Product feeds and schema can describe an offer, but browser agents still need reliable controls when moving from discovery to action. My analysis of Google AI agents and ecommerce covers that task-completion layer.

The 30-Minute AX Audit

Prioritize blocked actions first: fake buttons, fake links, unnamed fields, consent controls that cannot be operated, and broken focus. Fix contradictory state next. Then repair missing landmarks and heading structure. Treat experimental audit gaps as a monitored backlog.

This evidence-first approach also fits a repeatable technical SEO auditor workflow: collect rendered proof, classify the defect, and give the developer a testable acceptance condition.

FAQ

About the Author

Francisco Leon de Vivero is VP of Growth at Growing Search, with more than 15 years of SEO experience across ecommerce, international search, adult search, and enterprise sites. He spent more than seven years as SEO Lead at Shopify and more than four years working on SEO for Pornhub.

LinkedIn · YouTube · Get in touch