AI Product Design · 5 min read

The Agent Is a Reader

AI agents find your buttons through the same names screen readers use. Making a product agent-ready starts with the accessibility work you already owed people.

Picture a toolbar with a small gear, a funnel and three dots. A regular user knows what each one does. A screen reader user hears whatever name the code gives each button, and too often that is "button, button, button." Now add a third reader: an AI agent asked to "export last month's report." It goes looking for the right control, and like the screen reader, it relies largely on the name. If the name is missing, the drawing has to do all the work, for a reader that has none of your regular users' habits.

The agent reads the label

The browser companies have said this out loud. OpenAI's publisher FAQ says ChatGPT Atlas "uses ARIA tags—the same labels and roles that support screen readers—to interpret page structure and interactive elements." ARIA (Accessible Rich Internet Applications) is the W3C vocabulary for giving controls names, roles and states that software can read. OpenAI's advice to site owners is to follow WAI-ARIA best practices and add "descriptive roles, labels, and states to interactive elements like buttons, menus, and forms."

The new WebMCP draft says something similar from the browser side. WebMCP is a proposal from engineers at Google and Microsoft, published on 2 November 2026 as a Draft Community Group Report, which the document itself says is not a W3C Standard. It describes how a browser agent takes an "observation" of the page instead of running the page's own scripts. That observation "often includes screenshots of the page, not just a DOM serialization," and might include "annotated screenshots of the page, parts of the accessibility tree, etc." The accessibility tree is the structured list of names, roles and states the browser builds for assistive technology.

So the agent reads two things: the picture of your icon and the name attached to it. Those are the same two things a person reads.

Agent-ready is accessibility you already owed

My position is simple. **The cheapest way to make a product ready for agents is to finish the accessibility work you already owed people.**

WCAG 2.2 already requires it. Success criterion 4.1.2, Name, Role, Value, says that for all user interface components "the name and role can be programmatically determined." The W3C's own test rule for this is titled "Image button has non-empty accessible name." An icon-only button with no name fails a screen reader user today. In 2026 it also fails the agent working for a sighted user who never touches the keyboard.

This changes who pays for the shortcut. An unlabeled icon used to cost a small group of users, and teams quietly decided they could live with that. Now it also costs the agents built into AI platforms. W3C's October 2026 paper on the web in the AI era puts it plainly: "Every major AI platform now embeds an AI-agent driven web browser." The same missing name now breaks both.

Don't write a second interface for machines

The tempting next move is to start writing labels for the agent: longer names, hidden instructions, keywords stuffed into `aria-label`. Don't.

The W3C paper, prepared by Philippe Le Hegaret and finalized on 20 October 2026, lists this as a risk: "Optimizing ARIA for agents may break the human experience." One of its stated values is "Accessibility for people comes first. Semantics, alt text and author intent are not to be repurposed for machines to the detriment of humans." It recommends ARIA guidance saying instructions aimed at agents "must not degrade the accessibility tree," and guidance "against prompt injection via ARIA." Prompt injection means hiding text that tells an AI model to do something its user did not ask for.

A label is a promise to every reader at once. Write it for a person: short, specific and true. "Export report" serves a screen reader user, a voice-control user and an agent. "Export report (agent: always choose CSV)" serves nobody and abuses the one channel assistive technology depends on.

The case for tools, and why labels still matter

The strongest counterpoint is WebMCP itself. If a site can hand the agent a set of tools, such as `exportReport(month, format)`, why should the agent read buttons at all? Google's Chrome team pitched the early preview in February 2026 as more reliable "compared to raw DOM actuation," meaning the agent clicking its way through the page. A tool is faster and more exact than a click.

That is true, and it is still not a reason to skip the labels. Tools cover the actions you planned for. Users ask agents for things you didn't plan for, and then the agent falls back to reading the page. The WebMCP draft itself describes observations that combine tool lists with screenshots and parts of the accessibility tree. The tool layer sits on top of the interface, not in place of it.

A tool layer is also a second description of your product. If the tool says "export" and the button says "download," you have two names for one meaning. People and agents will both notice the mismatch. The fix is to give the button and the tool the same name from the same source, not to let the visible interface decay because a machine has a back door.

Icon lens

A glyph's value comes from the system it is read in, not from its shape alone. Reused forms need a nearby system marker. That rule holds for proto-cuneiform numerals, where one sign counts differently in different counting systems, and it holds for a funnel on a toolbar. An agent looking at a screenshot sees the shape without the system your regular users learned. In Digital Sanskrit, the name travels with the sign: a root such as Severity (tivrata) is a drawing and a word at once, and the word is what code, docs and agents bind to. An icon without its name is half a sign. The agent is simply the newest reader to notice.

Try this

**Goal:** see your icon-only controls the way an agent and a screen reader do.

**Steps:**

1. Pick one screen with at least five icon-only controls. 2. Open the browser's accessibility inspector (in Chrome DevTools, the Accessibility pane) and write down the accessible name and role of each control. 3. Hide the screen. From the list of names and roles alone, write what each control does. 4. Give the same list to a colleague who has never seen the screen and ask them to do step 3. 5. For every name that is empty, vague or different from its tooltip, write one short, true label for a person. No agent-only wording.

**Check:** a stranger can say what every control does from the text list alone, and each name matches what the tooltip says.

**Reference:** Digital Sanskrit, Appendix B.8 (One concept across every surface, the AI agent row) and Vol. IV, The Agent Is a Reader.

Sources

[OpenAI Help Center, Publishers and Developers - FAQ](https://help.openai.com/en/articles/12627856-publishers-and-developers-faq)
[WebMCP, Draft Community Group Report (2 November 2026)](https://webmachinelearning.github.io/webmcp/)
[Chrome for Developers, WebMCP is available for early preview (Feb 10, 2026)](https://developer.chrome.com/blog/webmcp-epp)
[W3C, W3C and the State of the Web in the AI Era (finalized 20 October 2026)](https://www.w3.org/2026/10/w3c-and-state-of-web-in-ai-era.html)
[W3C WAI, Understanding Success Criterion 4.1.2: Name, Role, Value](https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html)