Accessibility Tree Is Not Well-Formed – How to Fix It

If Lighthouse shows “Accessibility tree is not well-formed” in the Agentic Browsing category, it means your page has accessibility problems that make it harder for AI agents to understand and use your interface.

In this guide, we’ll explain what this Lighthouse issue means, what usually causes it, how to find the exact problem on your website, and how to fix it so your accessibility tree is easier for AI agents to use.

What is an accessibility tree?

The accessibility tree is a browser-generated version of your page that exposes the meaningful parts of the interface to assistive technologies.

Instead of showing every div, style, animation, and layout wrapper, it focuses on information that helps someone understand and operate the page:

• Roles, such as button, link, checkbox, heading, dialog, or navigation
• Names, such as “Open menu,” “Search site,” or “Submit quote request”
• States, such as expanded, collapsed, checked, selected, disabled, or required
• Relationships, such as a form label connected to an input
• Hierarchy, such as a list containing list items or a menu containing menu items

AI agents use the accessibility tree to understand and navigate a website. Chrome’s Lighthouse documentation says agents rely on the accessibility tree as a primary data model for identifying interactive elements.

When the accessibility tree is well-formed, agents can understand and use the page more reliably. When it is not, they have to guess. That guesswork can lead to missed controls, misunderstood fields, wrong actions, and failed tasks.

What is the “Accessibility tree is not well-formed” issue?

The “Accessibility tree is not well-formed” issue in Lighthouse means the page has broken, missing, or conflicting accessibility information

It is usually caused by issues such as:

• Buttons, links, inputs, selects, tooltips, dialogs, and tree items missing accessible names
• Missing document title
• Invalid, misspelled, prohibited, or unsupported ARIA attributes
• Invalid ARIA roles
• ARIA roles missing required attributes
• ARIA roles missing required children or parents
• aria-hidden=”true” on the body
• aria-hidden=”true” elements containing focusable elements
• Duplicate IDs used in ARIA relationships
• Positive tabindex values
• Presentation-role conflicts
• SVG images missing accessible text
• Invalid autocomplete values

These map closely to the checks behind Lighthouse’s agent-accessibility-tree audit.

That can block screen reader users, keyboard users, and AI agents in similar ways. If a button has no name, nobody using the accessibility tree can reliably know what it does. If a custom menu has the wrong roles, the browser may expose a confusing structure. If a hidden element can still receive focus, users and agents can land on something that is not supposed to be available.

How to find what is breaking your page’s accessibility tree

Lighthouse can tell you that the accessibility tree is not well-formed, but it does not always make the root cause obvious.

As mentioned above, several issues can trigger this warning, from missing labels and unnamed buttons to invalid ARIA or hidden focusable elements. The next step is to identify which specific issue is causing the problem on your website.

The fastest way to narrow it down is to run an automated accessibility audit.

With WebYes Accessibility, you can scan a page or site to find the underlying accessibility issues that may be breaking the accessibility tree. WebYes also provides AI-powered code suggestions to help fix those issues, which is especially useful if you are not a developer.

How to fix the “Accessibility tree is not well-formed” issue

To fix the “Accessibility tree is not well-formed” issue, you need to fix the accessibility problem that is breaking the tree.

In the section above, we covered how to identify the specific issue on your website. Once you know what is causing the warning, the fix usually falls into one of these areas.

1. Give interactive elements clear names

Use this fix if your audit found unnamed buttons, empty links, icon-only controls, SVG images without accessible text, dialogs without names, or vague link text.

A visual user might understand an icon-only button because it looks like a magnifying glass, cart, hamburger menu, or close icon. But the accessibility tree needs a programmatic name.

Bad:

<button>
  <svg aria-hidden="true">...</svg>
</button>

Better:

<button type="button" aria-label="Open search">
  <svg aria-hidden="true">...</svg>
</button>

Better still, when the design allows it:

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

Check every:

• Icon-only button
• Empty link
• “Read more” link
• Product card link
• Form submit button
• Custom dropdown trigger
• Dialog close button
• Search button
• Carousel control

The accessible name should describe the action or destination. “Open cart” is better than “Cart icon.” “Read more about pricing” is better than “Read more.”

2. Connect form labels and errors

Use this fix if your audit found inputs without labels, placeholder-only fields, missing field descriptions, unclear required fields, or errors that are not connected to the relevant field.

Forms are especially sensitive because agents and assistive technologies need to know what each field asks for.

Bad:

<input type="email" placeholder="Email">

The placeholder may look like a label, but it is not a reliable replacement.

Better:

<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email">

For grouped controls, use fieldset and legend:

<fieldset>
  <legend>Preferred contact method</legend>

  <label>
    <input type="radio" name="contact" value="email">
    Email
  </label>

  <label>
    <input type="radio" name="contact" value="phone">
    Phone
  </label>
</fieldset>

Also, make sure error messages are tied to the relevant field:

<label for="zip">ZIP code</label>
<input
  id="zip"
  name="zip"
  aria-invalid="true"
  aria-describedby="zip-error"
>
<p id="zip-error">Enter a valid 5-digit ZIP code.</p>

If a user or agent submits a form and something fails, the page should expose which field failed, why it failed, and what to do next.

3. Use native HTML before ARIA

Use this fix if your audit found clickable divs or spans, custom controls without keyboard support, or ARIA being used where native HTML would work better.

ARIA can improve accessibility when native HTML cannot express the pattern. But ARIA can also break the accessibility tree when it is used incorrectly.

Bad:

<div role="button" onclick="saveForm()">Save</div>

Better:

<button type="button">Save</button>

A native button already exposes the correct role and keyboard behavior. A div with role=”button” still needs keyboard support, focus handling, disabled states, and correct naming.

The safest rule is: use native HTML first.

Use:

• <button> for actions
• <a href="..."> for navigation
• <label> for form labels
• <select> for simple dropdowns
• <input type="checkbox"> for checkboxes
• <input type="radio"> for radio buttons
• <dialog> or a well-tested dialog component for modals
• <nav>, <main>, <header>, and <footer> for landmarks

Only add ARIA when the native element cannot express the required behavior.

4. Fix invalid ARIA roles and relationships

Use this fix if your audit found invalid roles, unsupported ARIA attributes, missing required ARIA attributes, broken aria-labelledby or aria-describedby references, duplicate IDs, or ARIA roles missing required parents or children.

Some ARIA roles require specific parents, children, states, or properties. If those relationships are broken, Lighthouse can flag the accessibility tree as not well-formed.

For example, a menuitem should not float randomly on the page:

<div role="menuitem">Products</div>

It needs an appropriate parent structure:

<div role="menu" aria-label="Product menu">
  <div role="menuitem" tabindex="0">Products</div>
</div>

But be careful: many site navigation menus do not need ARIA menu roles at all. A normal navigation list is often better:

<nav aria-label="Main navigation">
  <ul>
    <li><a href="/products/">Products</a></li>
    <li><a href="/pricing/">Pricing</a></li>
    <li><a href="/contact/">Contact</a></li>
  </ul>
</nav>

Common ARIA problems include:

• aria-labelledby pointing to an ID that does not exist
• aria-describedby pointing to duplicate IDs
• aria-expanded used on an element that does not control expandable content
• aria-controls pointing to the wrong element
• role=”dialog” without an accessible name
• role=”img” without a label
• role=”tab” without a tablist pattern
• role=”treeitem” without the right tree structure

When in doubt, remove unnecessary ARIA and return to semantic HTML.

5. Keep hidden content out of the focus order

Use this fix if your audit found focusable elements inside aria-hidden=”true” containers, closed menus that can still receive focus, inactive modals, hidden panels, or offscreen controls that keyboard users can still reach.

Another common cause is hiding content visually or from assistive technology while leaving focusable elements inside it.

Bad:

<div aria-hidden="true">
  <button>Close</button>
</div>

If an element is hidden from the accessibility tree, it should not contain focusable controls.

Better:

<div hidden>
  <button type="button">Close</button>
</div>

Or, if you are hiding an inactive panel, make sure focus cannot move into it until it is available.

This issue often appears in:

• Modals
• Mobile menus
• Accordions
• Tabs
• Carousels
• Off-canvas panels
• Cookie banners
• Chat widgets

If a panel is closed, its controls should not be reachable by keyboard or exposed as active controls. If a panel is open, it should have correct labels, focus behavior, and state.

6. Remove positive tabindex values

Use this fix if your audit found tabindex values greater than 0 or a focus order that does not match the page’s visual or DOM order.

Avoid positive tabindex values such as:

<button tabindex="3">Buy now</button>

Positive tabindex creates a custom tab order that can become disconnected from the visual and DOM order.

Use the natural DOM order instead:

<button>Buy now</button>

Also, check whether keyboard focus can enter hidden menus, closed accordions, inactive modals, or offscreen panels. If users cannot see or use something, keyboard focus should not land there.

Wrapping up

Lighthouse’s “Accessibility tree is not well-formed” issue means your page is exposing incomplete, missing, or contradictory accessibility information.

To fix it, address the specific issue breaking the accessibility tree. After applying the relevant fix, run the Agentic Browsing audit on Lighthouse again. If the accessibility tree is now clean and the underlying issue is resolved, the page should pass the check.

If you want to further optimize your website for AI agents, also look at your site’s CLS and structured data. Both can make your pages easier for agents to interpret and navigate reliably. For a broader checklist, read our guide on how to make your website AI-agent friendly.