A screen reader user lands on a product page, tabs to what looks like an "Add to cart" button, and hears nothing but "clickable." No name. No role. No state. They have no idea what the element does or whether pressing it will do anything at all.
Now picture an AI agent sent to complete the same task on the same page. It parses the DOM, looks for something it can identify as an actionable control, and finds the exact same unlabeled div. It has no more idea what that element does than the screen reader user did.
This is the part nobody planned for. Teams have spent years treating "accessibility for disabled users" and "making a site legible to software" as two separate conversations, sometimes assigned to two different roles entirely. It turns out they were never separate problems. They were the same problem with two different audiences standing on the other side of it.
The Stat: WCAG SC 4.1.2 Name, Role, Value (Level A) requires that every UI component expose a programmatically determinable name, role, and state - the same requirement that lets a screen reader announce a control correctly also lets any other piece of software, including an automated agent, determine what a control is and does. (Source: W3C WAI)
Two audiences, one underlying API
Here is the part that gets lost in the noise around "AI-friendly" websites: an AI browsing agent does not see your page the way a human does. It does not see the button's color, its shadow, or its nice hover animation. It works from the same layer a screen reader works from: the accessibility tree, built from the DOM, informed by ARIA roles, states, and properties.
That layer only contains what you programmatically exposed. If your "Add to cart" control is a <div onclick="..."> styled to look like a button, a sighted mouse user clicks it without issue. A screen reader user hears an unlabeled clickable element. An AI agent parsing the DOM for an actionable "add to cart" affordance finds the same nameless div and has to guess, scrape visible text nearby, or simply fail the task.
WCAG SC 1.3.1 Info and Relationships is the other half of this. It requires that information, structure, and relationships conveyed through presentation be programmatically determinable, not conveyed by visual layout alone - a requirement any non-visual consumer of a page, human or automated, depends on equally. A price that's only "clearly the bigger number in bold red" to a sighted eye, with no <table>, no labeled relationship, no semantic association to the product it belongs to, is exactly as ambiguous to an agent as it is to someone using a screen reader.
This is not a coincidence of timing. It is the same architecture doing the same job for two very different consumers.
What actually breaks, and for whom
We have reviewed enough production sites, across enough industries, to see the same handful of patterns show up over and over. These are not edge cases. They are the defaults teams reach for when speed matters more than markup.
- Div-as-button syndrome. A
<div>or<span>styled and click-handled to behave like a button, with norole="button", notabindex, no keyboard handler, and no accessible name. Screen readers announce nothing useful. Agents see an inert node with no semantics to act on. - Icon-only controls with no text alternative. A trash can icon that deletes an item, a hamburger icon that opens a menu, a magnifying glass that submits a search - all with no
aria-label, no visually hidden text, nothing but a<path>in an SVG. Neither a screen reader nor an agent can tell what pressing it does. - State that only changes visually. A toggle that flips color and position on click but never updates
aria-pressed,aria-expanded, oraria-checked. The visible state changes; the programmatic state never does. Anyone, or anything, not looking at pixels has no idea the toggle moved. - Layout-only structure. Tabular data laid out with
<div>grids and CSS instead of a real<table>, or a multi-step form with no<fieldset>/<legend>grouping related inputs. The relationships are visually obvious and programmatically invisible. - Custom widgets with no ARIA pattern at all. A dropdown, date picker, or autocomplete built entirely from styled divs and JavaScript, with none of the roles, states, or keyboard behavior that the equivalent native or ARIA-authored widget would carry.
Every one of these failures already had a name and a fix inside WCAG long before "agentic browsing" was a phrase anyone used. That's worth sitting with: we did not need a new standard for the AI-agent era. We needed teams to finally finish the standard we already had.
Why this changes the urgency, not the requirement
For years, the pitch for fixing SC 4.1.2 and 1.3.1 violations was framed almost entirely around legal and moral obligation: real people using assistive technology are locked out, and that's the reason to fix it. That reason was always sufficient on its own. But it also let some teams quietly deprioritize it as "a compliance line item" rather than core engineering quality.
Agentic browsing removes that framing option. As more commerce, support, and research tasks get delegated to AI agents acting on a user's behalf, a site's semantic markup becomes a functional dependency for a growing channel of traffic and conversions, not just a legal exposure. A broken accessibility tree now has two ways to cost you: a person who cannot complete checkout, and an agent that cannot either.
The fix is identical either way, which is the useful part. You are not maintaining two separate markup strategies for two separate audiences. You fix the accessibility tree once, correctly, and both audiences inherit the benefit.
A practical checklist for the overlap
- Every interactive element (button, link, toggle, custom widget) has a real, programmatically determinable role - native HTML elements where possible, correct ARIA roles where not
- Every interactive element has an accessible name (visible text,
aria-label, oraria-labelledby) that describes what it does, not just what it looks like - Every stateful control (toggles, expandable sections, tabs, checkboxes) updates its ARIA state (
aria-expanded,aria-pressed,aria-checked,aria-selected) whenever its visual state changes - Tabular data uses real
<table>markup with headers, not CSS grids that only look like tables - Related form fields are grouped with
<fieldset>and<legend>, not just visual proximity - Custom widgets (dropdowns, date pickers, comboboxes) follow an established ARIA authoring pattern, including keyboard support
- Icon-only controls carry a text alternative that survives a screen reader and a DOM parse equally
| Failure pattern | What a screen reader hears | What an AI agent parses |
|---|---|---|
| Div styled as button, no role/name | "clickable" | unnamed, unactionable node |
| Icon-only control, no label | nothing announced | no text to match intent to |
| Visual-only toggle state | state never announced | state cannot be confirmed |
| CSS-grid "table" | no row/column relationships | no structured data to extract |
We put this exact gap under a microscope recently and it's worth reading in full: read what our own AI-code testing found on this exact gap. The short version is that markup generated quickly, whether by a rushed developer or an AI coding assistant, tends to fail SC 4.1.2 and 1.3.1 in precisely these ways, which means the problem compounds rather than resolves as more code gets written faster.
The soft part
None of this requires a rebuild. It requires a real audit of the semantic layer your site is actually built on, not the layer it appears to have when you're looking at it with your own eyes on your own screen.
If you want to know exactly where your markup breaks for a screen reader user and, increasingly, for the agents now browsing on people's behalf, get an audit that checks your semantic structure directly. It's a good next step before either audience runs into the wall your team can't see from the design file. If you'd rather talk it through first, the team is reachable directly at experts@wcag.world.