Does making my site accessible make it work better with AI agents?

For the parts a machine can check, mostly yes. A link, button, or form field with no accessible name gives a screen reader nothing to announce and gives an agent nothing to go on. Fixing those names helps both. Accessibility is still about people first: the agent benefit is a side effect of doing the work for screen reader and keyboard users, not a reason to skip them.

Should I add ARIA attributes so AI agents understand my site?

Not as a first step. Native HTML elements like button, a, label, and nav already put the right role and name in the accessibility tree. The W3C's first rule of ARIA is to use a native element when one exists. ARIA added only for bots, or added wrongly, can make the page worse for screen reader users and confuse agents too.

How AI Agents Read Your Website, and Why Accessibility Is the Same Work

Q: How do AI agents read a website?

Many AI agents read a page through its accessibility tree, the structured list of headings, links, buttons, and form fields that browsers build for screen readers. Google's Lighthouse documentation says agents rely on the accessibility tree as their primary data model, and Microsoft's Playwright MCP server, a common way to connect an AI model to a browser, works from accessibility snapshots instead of screenshots. Some agents also look at screenshots, but the tree is cheaper and more precise, so it is usually the first thing they use.

Q: What is the Lighthouse Agentic Browsing check?

It is a category in Google's Lighthouse tool that runs checks on how well a page works for machine interaction. One group of checks confirms every interactive element has a programmatic name. Others check that the accessibility tree is well formed, that interactive content is not hidden from it, and that the layout does not shift while an agent is acting.

By Site Brace Research · Published October 31, 2026

AI agents that browse and fill in forms for people often read your page through its accessibility tree, the same structure a screen reader uses. Google's Lighthouse documentation says agents "rely on the accessibility tree as their primary data model." So a button with no name is a blank to a screen reader and to an agent. In our scan of 299 large US home pages, 85 (28%) had at least one link, button, or form field with no accessible name. The fixes are the ones accessibility already asks for: real HTML elements and a name on every control.

We are an accessibility audit service, so read this with that in mind. We are not telling you to fix your site for robots. People who use screen readers, voice control, and keyboards come first, and the law points at them. The point of this page is narrower: the same broken markup that locks them out also trips up software that tries to use your site on someone's behalf.

What an agent actually sees

When a browser loads a page, it builds two things from your HTML. One is the visual page. The other is the accessibility tree: a stripped-down outline listing each heading, link, button, and form field, with its role ("button"), its name ("Add to cart"), and its state ("checked", "expanded").

Screen readers read that tree aloud. Agents read it too, and the reason is boring and practical: the tree is far smaller than the full HTML and says what each thing is for, so an agent can find "the Search field" or "the Checkout button" without guessing from pixels. Two current examples:

Google Lighthouse now has an Agentic Browsing category. Its documentation calls the accessibility tree the "machine-eye view" of a page and includes a group of checks that confirm every interactive element has a programmatic name.
Microsoft's Playwright MCP server, a common way to give an AI model control of a browser, says it "uses Playwright's accessibility tree, not pixel-based input."

Some agents also take screenshots and use vision models. That works as a fallback, but it is slower and less reliable. If the tree says what a control is, the agent does not have to guess.

The same failures block both

Here is what a screen reader announces, and what an agent gets, for three common defects:

Defect	Screen reader hears	Agent gets
Icon button with no label	"button"	a button with no name, so no idea what it does
Linked logo or icon link with no text	"link"	a link with no name or destination clue
Search box with only placeholder text	"edit text"	a text field with no label, so no idea what to type

Each of these fails WCAG 2.1 at Level A, the most basic level. A link or button with no name fails Success Criterion 4.1.2 (links also fail 2.4.4), and an unlabeled form field fails 1.3.1 and 4.1.2.

How common is it?

We went back to the 299 home pages in our State of Web Accessibility 2026 study and counted the sites with at least one interactive control that has no accessible name: a link, a button, or a form field.

85 of 299 sites (28%) had at least one, with 415 unnamed controls across them.
Links were the most common case, on 70 sites. Buttons followed on 20, and form fields on 17.
By industry: nonprofits 23 of 43 (53%), law firms 20 of 46 (43%), hospitals 9 of 37 (24%), ecommerce 8 of 33 (24%), higher education 10 of 47 (21%), banks 7 of 38 (18%), and government 6 of 45 (13%).

This counts the home page only, and only what an automated scan can confirm. A full site usually has more, especially in checkout flows, filters, and account pages, which are exactly where an agent would be trying to get something done.

What to fix

Use real elements. A <button> for actions, an <a href> for navigation, a <label> for each form field. A <div> with a click handler shows up in the tree as nothing useful.
Name every icon control. Add aria-label="Search" or aria-label="Close" to icon-only buttons and links, and mark the icon itself aria-hidden="true". See buttons without discernible text and links without discernible text.
Label form fields. A placeholder is not a label. Connect a <label for> to each input. See form fields without labels.
Do not add ARIA for its own sake. The W3C's first rule of ARIA is to use a native element when one exists. Wrong ARIA is worse than none, for people and for agents.
Keep the layout still. Content that jumps around after load moves buttons out from under a keyboard user, and out from under an agent that already found them.

Skip any overlay widget that promises to make your site readable to AI. Overlays guess at labels at runtime, and the Federal Trade Commission fined the overlay vendor accessiBe one million dollars in 2025 over its claims. The fix belongs in your markup. We explain why overlays fall short.

What we can and cannot tell you

A scan reliably finds controls with no name, because that is a fact about the markup. It cannot tell you how any particular AI product will behave on your site. Agents change fast, and some products in this space have already come and gone. The accessibility tree and the WCAG criteria behind it have been stable for years. A label you add today for a screen reader user will still be there for whatever agent shows up next year.

Common questions

How do AI agents read a website? Many read the accessibility tree, the same outline a screen reader uses, and fall back to screenshots when they have to.

Does accessibility help AI agents? For names, roles, and structure, yes. The people benefit comes first.

Should I add ARIA for agents? Use native HTML first. Add ARIA only to fill a real gap.

What is the Lighthouse Agentic Browsing check? A Google Lighthouse category that tests how well a page works for machine interaction, including whether every control has a name.

Check your own site

Run a free check on your home page to see every unnamed link, button, and form field, with the markup to fix, in about a minute. For the whole site, a full audit covers up to 25 pages, and monitoring catches new unnamed controls as they ship. The data behind this page is in the State of Web Accessibility 2026.