AI agents do not read your website the way you do. They do not see your layout, your hero image, or your brand color. They prefer reading the accessibility tree: a stripped-down structural model of the page, the same one that has powered screen readers for two decades.

Today, that matters more because the audience reading that way is now the majority.

For the week of May 30 to June 5, 2026, Cloudflare Radar measured 57.2% of HTTP requests to HTML content, the requests that represent web-page traffic, as automated bots, against 42.8% human. Cloudflare CEO Matthew Prince, who shared the data on June 3, had forecast that crossover for 2027. He got it wrong because it arrived over a year early.

Cloudflare Radar, Bot vs. Human distribution filtered to HTML content (web-page traffic), May 30 to June 5, 2026
Cloudflare Radar, Bot vs. Human distribution filtered to HTML content (web-page traffic), May 30 to June 5, 2026 (Image from Cloudflare Radar by author, June 2026)

Some of that automated traffic is scrapers you probably want gone. A large and rising share is AI agents reading pages for real people. And according to the accessibility data published this year, the structure those AI agents depend on is getting worse, for the first time in six years.

The Accessibility Tree Is A Structural Model The Browser Builds From Your DOM

The accessibility tree is a semantic version of your page that the browser computes from the DOM so non-visual software can understand it. The pipeline is short: HTML to DOM to accessibility tree to consumers (assistive technology, and now AI agents).

The W3C’s WAI-ARIA 1.2 defines it as a “tree of accessible objects that represents the structure of the user interface,” where each node “represents an element in the UI as exposed through the accessibility API.” The browser builds it from the DOM (the mapping is specified in Core-AAM 1.2) and exposes it through the operating system’s accessibility API, which, per the W3C, “can be used by any assistive technologies, such as screen readers.” MDN explains the pipeline this way: Browsers “create an accessibility tree based on the DOM tree.”

The accessibility tree discards most of the DOM. A page with several thousand nodes collapses to the meaningful, interactive set: headings, links, buttons, form fields, landmarks, images with their text alternatives. For software working inside a limited context window, it is that reduction that makes the tree usable at all.

Every node in the accessibility tree carries four properties:

Property What it captures Example
Role What kind of element it is Button, navigation region, list item
Name How it is referred to A link reading “Read more” is named “Read more.” An icon-only button with no label has no accessible name.
State Its current condition Checked, expanded, disabled, selected
Description Any extra context beyond the name A longer explanation, like a tooltip, that a screen reader can read aloud

The tree also records what can be done with a node: a link can be followed, a text input can be typed into. That…


Source link

Disclaimer

We strive to uphold the highest ethical standards in all of our reporting and coverage. We blogs.grocliq.com want to be transparent with our readers about any potential conflicts of interest that may arise in our work. It’s possible that some of the investors we feature may have connections to other businesses, including competitors or companies we write about. However, we want to assure our readers that this will not have any impact on the integrity or impartiality of our reporting. We are committed to delivering accurate, unbiased news and information to our audience, and we will continue to uphold our ethics and principles in all of our work. Thank you for your trust and support.

Website Upgradation is going on for any glitch kindly connect at [email protected]

 

 

Categorized in:

Blog,

Last Update: June 24, 2026