Designing for AI agents: building a UI the non-human user can read

The non-human user is the AI agent that visits your product to act for a person: compare options, fill a form, book a slot, or buy. Designing for it means building an interface a machine can read and operate, not only one a person can see on a screen.

This used to be an edge case. It is now traffic. For the week of 30 May to 5 June 2026, Cloudflare measured that 57.2% of requests to HTML content came from automated clients, ahead of human browsers. Adobe reported that AI-referred traffic to US retail sites grew 393% year over year in Q1 2026, and that this traffic converted 42% better than other sources in March, rising to 54% better by May. Gartner expects 40% of enterprise applications to embed task-specific agents by the end of 2026. The reader you never designed for is already on the page.

What is the non-human user?

Three kinds of agent show up. Assistant agents (ChatGPT, Claude, Perplexity) browse and summarize. Computer-use agents drive a real browser and click through tasks. Commerce agents go one step further and complete a purchase. They share one trait. None of them see your design. Each reads a representation of it, and acts on what that representation tells them is there.

So the question stops being "does this look right" and becomes "can a program tell what this is, and use it". A page can score well on a design review and still be unreadable to an agent, because the two readers consume different layers of the same page.

How does an AI agent actually read a web page?

Most agents read the accessibility tree. It is the semantic model the browser builds from the DOM: a list of elements with roles (button, link, heading), names (the accessible label), and states (expanded, checked, disabled). Screen readers have used this tree for twenty years. Agents reuse it because it is smaller and more reliable than parsing pixels. OpenAI has said its Atlas browser reads ARIA tags to interpret page structure. The practical consequence is blunt: a page that works for a blind user tends to work for an agent, and a page that fails one fails the other.

The cost of a broken tree is measurable. In the A11y-CUA study presented at CHI 2026, researchers at UC Berkeley and the University of Michigan ran Claude Sonnet 4.5 across 60 everyday desktop and web tasks under three conditions. Under standard access it finished about 78% of tasks. With keyboard-only navigation, which mirrors how an accessibility-tree agent moves, success dropped to 42% and tasks took roughly twice as long. With a magnified viewport it fell to 28%. Nearly half the failures came down to one thing: the structural information the agent needed was not in the markup.

Why the visual layer hides the problem

The trap is that a styled page looks done. A button made from a div with an onClick handler looks identical to a real button. A person sees a button and clicks. An agent reads a generic container with no role and no name, and skips it. The same gap shows up everywhere a team reaches for visual styling instead of semantics:

• Icon-only controls with no text label. The agent sees a clickable thing with no idea what it does.
• Custom dropdowns and toggles built from div and span. No role, no state, no keyboard path.
• Content drawn in canvas or WebGL, or text baked into images. Invisible to the tree.
• State shown only by color. "Selected" with a blue border and nothing in the markup says selected.

Each of these is fine for a sighted human and a wall for everyone else, the screen-reader user and the agent alike.

How do you design for the non-human user?

The work overlaps heavily with accessibility done properly. Eight moves cover most of it.

1. Use real semantic elements. button, a, nav, main, label, table, real headings. Native elements come with the right role and keyboard behavior for free.
2. Name every control. Visible text where you can, aria-label where you cannot. An icon button without a name is anonymous to an agent.
3. Keep the tree honest on custom components. If you must build a widget from generic elements, give it the role, the state, and a focus order that matches what the eye sees.
4. Make state machine-readable. aria-expanded, aria-checked, aria-disabled. Color alone tells the agent nothing.
5. Expose structured data. Schema.org JSON-LD for products, offers, prices, and FAQs lets an agent read facts without scraping the layout. See our guide to the schema markup types every blog needs.
6. Let agents in. Do not block their crawlers at the edge by default. We covered the fix in unblocking AI crawlers without breaking security.
7. Keep critical content server-rendered. An agent may not run your client-side JavaScript. If the price, the form, or the main copy only appears after hydration, the agent reads an empty shell.
8. For commerce, speak a protocol. A structured checkout beats fragile form-filling. See what an MCP server is and why it matters for the agent-interface side of this.

The commerce layer is standardizing fast

If your product sells something, the way an agent buys is moving from guesswork to standards. Stripe and OpenAI shipped the Agentic Commerce Protocol to power Instant Checkout in ChatGPT. Google donated its Agent Payments Protocol (AP2) to the FIDO Alliance in April 2026. Shopify and Google announced a Universal Commerce Protocol at NRF in January, and Visa shipped a protocol-agnostic on-ramp that accepts several of these at once. The shared idea is a structured, consented checkout the agent calls, instead of an agent fumbling through a form built for a mouse. Supporting one of these is how an agent completes a sale on your terms rather than abandoning it.

Trust still gates the last step. Surveys in 2026 put consumer comfort with AI comparing prices around 65%, but comfort letting AI place the order near 14%. Most agents still hand the final click back to the person. That is fine. The job is to make the read, the compare, and the handoff clean, so the human says yes with everything already in the cart.

Where the human UI and the agent UI diverge

Most of this is shared with accessibility, but not all. Agents want stable structure, predictable selectors, and a machine path to the same outcome a human reaches by eye. They have no use for your scroll choreography, your hover states, or your modal timing. The honest answer is one core, not two sites: build an accessible, semantic, server-rendered foundation, then layer the visual experience on top of it. Building a separate hidden version for bots invites cloaking penalties and drifts out of sync with the real page within weeks. One source of truth, read by both audiences.

The non-human user is the screen-reader user you were already supposed to design for, now with a budget and a checkout. Teams that ship semantic, structured, server-rendered interfaces get two readers for the price of one. Teams that ship pixel-only interfaces get skipped by both.

Sources

• The Accessibility Tree Is How AI Agents Read Your Site (Search Engine Journal)
• AI traffic to US retailers rose 393% in Q1 (TechCrunch, on Adobe data)
• AI traffic grows but retail sites lag in machine readability (Adobe)
• How AI agents make accessibility business-critical, with the A11y-CUA results (SitePoint)
• Stripe and OpenAI: Instant Checkout and the Agentic Commerce Protocol
• Buy it in ChatGPT: Instant Checkout and the Agentic Commerce Protocol (OpenAI)
• Agentic commerce statistics 2026 (commercetools)