Microsoft counted 306,000 AI agent sessions with a checkout. Chrome says agents read what screen readers read.

Our working title for this piece was "A quarter of AI agent visits include a checkout". It had everything a headline wants: a big number, a tidy fraction and Microsoft's name on the data.

Then we did the division.

On 29 October Microsoft's Clarity team published "What AI Agents Do on Websites: Insights From 5.2 Million Sessions". Its table counts 306,621 agent sessions with a checkout event, the top action, and puts that at 25.21% of agentic sessions against 14.65% of human ones (Microsoft Clarity, 2026). Divide the count by the percentage and you get about 1.22 million sessions, not 5.2 million, and every row in the table lands on the same figure. Luis Rijo at PPC Land had published the same sum a day earlier: against the full 5.2 million, checkout comes in at about 5.9% (PPC Land, 2026). Microsoft's post doesn't explain the gap.

So I won't tell you a quarter of agent visits end at your checkout. What holds up is the count, collected over four weeks. That's a lot of software, and some people, standing at a lot of tills.

In March I wrote about the AI visitors most sites can't see: Your Website Has AI Visitors and You're Ignoring Them. Those were mostly reading. These ones are getting as far as checkout. And Google's Chrome team says agents rely on the accessibility tree, the same structure a screen reader reads, so the unnamed button your accessibility audit flagged last year could cost you a sale as well as a customer.

Some context. Clarity is Microsoft's own free analytics tool and the post launches its Agent Activity Dashboard, so Microsoft isn't exactly neutral. It only sees sites running Clarity (230,511 projects here, which isn't the whole web), and it picked out agents through "detected agentic browser providers" from OpenAI, Google and Anthropic without saying how, or whether a person browsing in an AI browser counts.

Microsoft's own caveats are fair. An agent session "may also include a human handoff", so some of those checkouts were probably a person grabbing the wheel back. And a checkout event isn't a sale: in Microsoft's human table, checkout shows up in 14.65% of sessions and "Order success" in 1.79%. Agent sessions also grew 88% in three weeks, apparently. The post doesn't give the dates.

Microsoft Clarity

@msftClarity

🆕 𝐍𝐞𝐰 𝐒𝐭𝐮𝐝𝐲: AI agents are changing how websites are used. 🤖

We analyzed 5.2M sessions involving AI agents, including:

📊 306K+ with checkout events
📝 241K+ with form submissions

Discover why tracking agentic activity matters. 👇

clarity.microsoft.com/blog/agentic-a…

7

29 Oct 2026

Closer to home. In June, at Google Marketing Live in Sydney, Google made Australia the first Asia-Pacific market for its agentic checkout: single-item purchases inside Search, AI Mode and the Gemini app. Google named Adore Beauty, Bunnings, Kogan Group, Petbarn and The Iconic among the retailers it would launch with. "Agentic commerce isn't coming, it's here," said Mel Silva, Google's managing director for Australia and New Zealand, which is exactly what you'd expect Google to say (Marketing-Interactive, 2026). Google's Pay help page now lists the US and Australia as the only places it works (Google Pay Help, 2026).

Retailers on Google's Universal Commerce Protocol get a direct line from Google's agent to their systems, and the checkout happens on Google's own pages, so nothing has to go hunting for a Pay button (Google Merchant Center Help, 2026). We covered the protocol in January: Google's Universal Commerce Protocol: The API That Lets AI Agents Buy Things For You. That's the deal Bunnings signed on for in June. If you're not on the protocol, a general browser agent comes through your actual pages instead.

What an agent sees on your checkout

Underneath every page, the browser builds a plain version with the design stripped out. Each element gets a role (button, link, text box), a name ("Pay now", "Email address") and a state (ticked, expanded, disabled). That's the accessibility tree, and it's what a screen reader reads aloud to a blind customer.

Google's developer guidance for its own agent-readiness toolkit, published in June, is blunt about who else reads it: "Agents rely on the accessibility tree, derived from DOM for assistive technology (AT), as their primary data model" (Chrome for Developers, 2026). Microsoft's Playwright MCP, a developer tool for letting AI drive a browser, says it "Uses Playwright's accessibility tree, not pixel-based input" (Microsoft, 2026).

Now the other half, which I'd rather say than have you find: not every agent works like that. Microsoft's Copilot in Edge "takes screenshots of the pages it visits" (Microsoft Support, 2026). Google's Gemini computer-use model works from screenshots too (Google AI for Developers, 2026), and OpenAI's computer-use guide tells developers to "Give the model a current screenshot when the UI state is unknown" (OpenAI, 2026). That's Microsoft and Google each giving two answers, which is genuinely confusing. It doesn't change the fix.

Picture an add-to-cart button that's just a plus icon, with no text and no name. A screen reader announces "button", and an agent reading the tree gets the same nothing. A screenshot agent has to guess what the plus does (add one? add to a wishlist? open a size chart?), and that's not a guess I'd want software making with someone's shopping. Label it "Add to cart", on screen and in the code, and the blind customer and both kinds of agent know what it does.

Nobody has published how often agents fail on a checkout, or at which step. Payment may well be the step a person takes back. The steps before it, the size and colour pickers, the quantity buttons, the address and booking fields, are where a nameless control can stop things.

Google's Sarah Drasner said as much in October: "Assistive tech struggles with the same interfaces agents do."

Sarah Drasner

@sarah_edo

A less discussed and potentially game-changing aspect of WebMCP: helpful a11y.

Assistive tech struggles with the same interfaces agents do. Dense menus, unlabeled buttons, etc.

When a site has clear tools, we can expose exactly the functionality we need.

193

12 Oct 2026

It's the overlap we've been banging on about for a while, and it now has a traffic number attached, though not a failure number. WebAIM's 2026 scan of the top million home pages found empty buttons, the plus-icon problem exactly, on 30.6% of them, missing form labels on 51% and detected WCAG failures on 95.9% (WebAIM, 2026). And that's home pages. I'd be surprised if checkouts were in better shape.

An overlay won't paper over it for your customers either. Alison Walden and Matt Vitale looked at seven US state government sites that used overlays in 2025, and the overlays didn't fix the barriers. One "blind" profile started reading pages aloud over the user's own screen reader (Walden and Vitale, 2026). More here: The $1M Overlay Mistake: Why AI Widgets Are Getting Businesses Sued.

In Australia, you owed these fixes to disabled customers before any agent turned up. The Disability Discrimination Act covers goods and services sold online, and the Australian Human Rights Commission's Guidelines on equal access to digital goods and services (April 2025) spell out what that means (AHRC, 2025). Being readable by agents is a side effect of doing that properly.

The best argument against this piece: it's Microsoft's data, from sites that chose Microsoft's tool, launching Microsoft's dashboard, and pixel-reading agents might win anyway, so why chase a moving target? Some of that's right, which is why every number here carries Microsoft's name. But every check below is something a blind customer needed last year, before anyone counted agent sessions. If agents change how they read pages again, none of the work is wasted.

Before Black Friday

Black Friday is 27 November. Microsoft's list points at checkout, forms and bookings. If Shopify, Stripe or PayPal hosts your payment page, that part isn't yours to fix, but the product pages, variant pickers, custom fields and booking forms usually are. Before the code freeze, check each one:

1. Every button and link has a visible name that says what it does, and the same name in the code. Ten buttons called "Edit" don't count.
2. Every form field has a real label. Placeholder text that vanishes when you start typing isn't one.
3. Errors are written out in words, not just turned red.
4. Nothing works only on hover or only by dragging.
5. Someone tabs through it with a keyboard and a screen reader. At minimum, open the accessibility tree in Chrome DevTools and look for anything without a name. Lighthouse's agentic browsing audit checks names too (Chrome for Developers, 2026).

A software designer who posts as Pizza Yap posted a similar list for a desktop agent tool, and the conclusion applies to websites too: "So the agent-friendly version of your UI is the accessible one."

Pizza Yap 🍕

@pzayap

agent-desktop doesn't match pixels. It reads the OS accessibility tree, the same thing a screen reader uses, and only interactive elements get a ref the agent can act on.

So the agent-friendly version of your UI is the accessible one. so we gotta make sure our web have all the

4

31 Oct 2026

Whether to let agents past your bot protection is a separate decision, and not one to rush before your biggest sales weekend. This is about not failing the ones you let in, and the people who were always there.

Microsoft counted 306,621 agent sessions with a checkout event in four weeks. I don't know how many ended in a sale, and Microsoft's post doesn't say. Every one of them recorded a checkout event, and a checkout is made of buttons and form fields. Make sure they have names.

---