The form is where agents give up

Reading your site is forgiving. An agent that misreads a price can check another source, compare, hedge. Filling in your form is not forgiving, because it is the one place the agent stops consuming and starts producing, committing real values on behalf of a real person from nothing but the labels you wrote. Most checkout and booking forms were never designed for that, and the fix turns out to be work many businesses already owe for entirely different reasons.

Reviewed September 25, 2026 · 11 min read

The operable gate is where agent readiness stops being about markup and starts being about whether a task can actually finish. Within that gate, one obstacle accounts for more abandoned tasks than the rest combined, and it is the form.

The reason is structural rather than cosmetic. Everywhere else on your site the agent is reading, and reading has recovery: a misread price can be checked against a feed, a confusing sentence can be reread, an ambiguous page can be compared against another. At the form, the agent has to write. This is the wall service businesses hit when an agent tries to book, and the same wall stands in front of every checkout. It has to decide that the box labelled Name wants a full name rather than a first name, that the second address block is for billing rather than a second shipping address, and that the field it just filled was accepted. Every one of those is an inference, and a wrong inference becomes an order with the wrong address on it.

Filling a form is the only thing an agent does blind#

Put it in the terms a merchant already understands. A human filling your checkout brings an enormous amount of context: they know their own name, they can see that two address blocks mean shipping and billing because of the headings and the layout, and when something turns red they read the sentence next to it. None of that is in your HTML. It is in the person.

An agent has only what is in the page. If the purpose of a field is expressed by visual proximity to a heading, it is not expressed at all. If the error is expressed by a red border, it is not expressed at all. This is not a new problem and it is not an AI problem, which is the useful part.

You may already owe this work, and you may already have paid for it#

Two accessibility requirements, written years before agentic commerce existed, describe almost exactly what an agent needs. Not approximately. Exactly.

Read those as an engineer rather than as a compliance officer. Programmatically determined means a machine can tell what the field is for without looking at it. Described in text means a machine can tell what went wrong without interpreting a colour. That is the entire agent brief, written by the W3C, for a completely different constituency.

The understanding document for 1.3.5 says the benefit is that browsers can auto-fill personal information for people with language, memory and executive function disabilities. An agent filling your checkout is doing the same operation, for a different reason, using the same signals.

The vocabulary you are probably not using#

The mechanism both constituencies rely on is the autocomplete attribute, and it is not a boolean. It carries a fixed vocabulary of tokens, and the tokens are specific enough to remove essentially all the guesswork from a standard checkout.

The names are worth dwelling on, because address-level1 and address-level2 look like jargon and are in fact the fix for a real problem. County, province, prefecture, state and region are the same slot in different countries, and a form that labels it State is unfillable in half the world. The token says which slot it is regardless of what your label calls it.

The tokens that matter most in a checkout are the ones nobody sets#

Here is the part that is specific to commerce and almost universally missed. The vocabulary includes prefixes: shipping and billing. The specification is direct about what they mean, that the field identified by the tokens after the prefix is part of the shipping, or the billing, address or contact information.

Now picture your checkout. Two address blocks, visually distinct, each with a heading a person reads in half a second. In the HTML, without prefixes, they are two identical sets of fields with identical tokens. There is no signal at all about which is which beyond position, and position is exactly the kind of inference you do not want an agent making about where your parcel goes.

<!-- Ambiguous: two identical address blocks -->
<input autocomplete="street-address">
<input autocomplete="postal-code">

<!-- Unambiguous, and it costs two words -->
<input autocomplete="shipping street-address">
<input autocomplete="shipping postal-code">

<input autocomplete="billing street-address">
<input autocomplete="billing postal-code">

There is also a section prefix for grouping fields that belong together, a token beginning with the eight characters section- followed by a name of your choosing, where every control sharing that token forms a named group. That is the tool for forms with repeated blocks that are not shipping and billing: two passengers, three attendees, a gift recipient alongside the buyer.

What your error state has to say out loud#

Half of form operability is filling it. The other half is recovering when the form says no, and this is where most implementations fail hardest, because visual design has spent twenty years making rejection quiet and tasteful.

A red border is not an error message. A shake animation is not an error message. A red asterisk that appeared next to a field is not an error message. Criterion 3.3.1 is a Level A requirement, the lowest bar there is, and it asks for two things: the item in error is identified, and the error is described to the user in text. An agent needs the same two things, for the same reason a screen reader does, which is that neither of them can see your border.

The practical shape is a text message saying which field and what is wrong with it, placed next to that field and programmatically associated with it, rather than a single line at the top saying that something went wrong. An agent handed "please check your details" has learned nothing and will either resubmit the identical values or stop.

Things that look helpful and are not#

• A placeholder used instead of a label. It disappears the moment anything is typed, it is not a reliable accessible name, and it leaves the field unlabelled for anything that is not looking at the pixels.
• A custom dropdown built from divs. It looks better than a select and it is invisible as a control unless someone did the accessibility work on it, which is usually the work that got cut.
• A date field that only accepts clicks on a calendar widget. Typed input is how a machine supplies a date, and how a lot of humans prefer to.
• autocomplete="off" applied broadly. It has a legitimate narrow use, and the specification is clear that it means the browser is not permitted to enter a value, which is occasionally what you want and usually not what you meant.
• A multi-step wizard holding all its state in the client. Anything that interrupts the sequence loses everything, and agents are unusually good at interrupting sequences.
• A required field that is not marked required in the markup, so its absence is discovered only at submission.

The twenty-minute audit#

1. Open your checkout or booking form and view source. For each input, ask whether a stranger reading only that element could say what it wants. If the answer depends on a heading three elements up the tree, that field is guessable rather than declared.
2. Add autocomplete tokens to every field that collects a standard fact about the buyer. This is a single attribute per input and it is the highest return change on the list.
3. Add shipping and billing prefixes anywhere you collect two addresses. If you collect two addresses and have never done this, this is the single most valuable ten minutes in the article.
4. Submit the form deliberately wrong and read what comes back as text only. Turn off your stylesheet if that is easier. If the page no longer tells you which field failed and why, neither does your error handling.
5. Replace placeholder-only labels with real ones. You will improve your conversion rate for humans at the same time, which is a rare two-for-one.
6. Run the flow with an actual assistant and watch where it stops. As in the previous piece, the handback point is the answer, and it is usually a field whose purpose you thought was obvious.

One honest limit. There is a point past which a form is not worth optimising, because the interaction is genuinely too complex to express as a page, and the right answer is to give an agent a described endpoint rather than a better set of boxes. That is what a merchant MCP server is for, and knowing when you have crossed that line is worth more than another round of attribute tuning.

For most businesses that line is a long way off, and the intervening work is an afternoon of attributes that also satisfies an accessibility obligation many of them already carry. It is the least glamorous item in this whole library and it is the one standing directly between a buyer who wanted to pay you and an order that never arrived.