An AI agent can complete a form or checkout when every field has a clear label, every button has a name, errors are written in text, and the steps come in a predictable order. Build it the way you would for a screen reader user, add standard autocomplete tokens, and make sure a person confirms before any payment goes through.
That is most of the answer. The rest of this post explains why agents behave this way, what trips them up, and what to add once the basics are in place.
How an agent sees a form
A browser agent does not look at your form the way a person does. It reads a structured view of the page: the DOM, the accessibility tree, or both. In that view, a field is a role (textbox, checkbox, combobox), a name (usually its label) and a state (required, invalid, checked). Colour, position and icons count for very little. If a field has no name, the agent has to guess from the text near it, and guesses fail.
This is why the fastest win for agent readiness is ordinary accessibility work. If a screen reader can announce "Email address, required, edit text", an agent can find and fill that field. Our post on how AI agents read web pages covers the accessibility tree in more detail.
Labels, names and roles
Every input needs a real <label> element tied to it with for and id, or wrapping it. Placeholder text is not a label: it disappears when the field has a value, and many tools do not treat it as the field's name.
- Inputs: one visible label each. Group related options in a
fieldsetwith alegend, such as "Shipping method". - Buttons: name them by their action. "Continue to payment" beats "Next". An icon-only button needs an accessible name.
- Custom controls: if you build your own dropdown or date picker, give it the right role and make it work with the keyboard. When in doubt, use the native element.
The HTML forms specification and the WAI-ARIA specification are the primary references for these rules.
Autocomplete tokens tell agents what a field is for
The HTML autocomplete attribute has a fixed vocabulary: name, email, tel, street-address, postal-code, country, cc-number and more. Browsers use it to fill saved details. Agents can use it the same way, because it states the purpose of a field in a form no label wording can blur.
Use the standard tokens on every personal and address field. Do not invent your own values, and do not turn autocomplete off on fields a customer is expected to fill.
Predictable steps and readable errors
Agents handle linear flows well and hidden state badly. A checkout that shows a new section only on hover, moves focus unexpectedly, or reorders fields after a choice is hard for an agent to follow and easy to get wrong.
- Load each step in a fixed order and keep the step names visible.
- Write every error as text next to the field, linked with
aria-describedby, and mark the fieldaria-invalid. A red border alone tells an agent nothing. - Keep the URL or a step indicator in sync with the current step, so an agent that reloads the page can tell where it is.
- Avoid time limits that expire silently. If a session times out, say so in text.
| Hard for agents | Easy for agents | |
|---|---|---|
| Labels | Placeholder text only | A visible label tied to the input |
| Buttons | An icon with no name | A button with a clear name |
| Errors | A red border only | An error message linked to the field |
| Steps | Fields that appear on hover | Steps that load in a fixed order |
| Bot checks | A puzzle with no other route | Risk checks with a fallback |
Bot checks without walls
Many checkouts put a visual puzzle in front of the pay button. That stops some abuse, and it also stops agents acting for a real customer. Treat an agent-assisted purchase as a sale, not an attack. Rely on risk signals, rate limits and payment fraud checks, and keep a route that does not depend only on solving an image puzzle. Where you must challenge a session, hand the challenge to the user rather than failing silently.
A person confirms before payment
Agents are designed to pause on irreversible steps. Help them. Show a review step with the item list, shipping, taxes and the total written as text, then require one clear confirm action. Do not charge on an earlier step "to save time".
This protects your customer and you. It gives the user a moment to check what the agent did, and it gives you a record that the purchase was confirmed. It is the same principle we build into our own agents: write actions wait for a person by default, as described on our agent engineering page.
Going further: WebMCP and declarative actions
A good form is the floor. The next step is to describe your key actions directly to agents. WebMCP is a draft web standard that lets a page register tools, such as "add to cart" or "start checkout", with a name, a description and an input schema. An agent in the browser can then call the tool instead of driving the form field by field.
WebMCP is still a draft, so treat it as an addition, not a replacement. The form must keep working for people and for agents that do not support it. Our post on WebMCP walks through the API, and our agent-ready ecommerce guide covers store platforms.
How to test your form
You do not need a special lab to test this. Three checks catch most problems:
- Keyboard only: complete the checkout without a mouse. If you get stuck, an agent will too.
- Accessibility tree: open your browser's developer tools and inspect the accessibility tree for each field. Every field and button should have a sensible name.
- Automated audits: run Lighthouse and an accessibility checker. Our post on the Lighthouse agentic browsing audit explains what it checks.
Platforms matter too. Hosted checkouts on Shopify, BigCommerce and similar platforms control much of the markup, so focus on what you can change: theme fields, custom forms and apps.
Next step
Run the free agent-readiness scan to see how your site does on the checks agents rely on, including WebMCP and structured data. If your checkout needs work, tell us about it and we will say what to fix first.