Short answer: An AI buying agent completes your form the way a screen reader reads it — from the DOM. Bind every input to a real <label>, add the HTML Standard’s autocomplete tokens, mark required fields with the required attribute rather than an asterisk alone, make the form submit without JavaScript, and return success and error states as text. Then filter spam server-side, after submission, not with a challenge at the gate.
B2B sites have started receiving form submissions no human typed. A buyer asks an assistant to shortlist vendors and book demos; the assistant drives a browser, reads your demo-request form and tries to fill it. Sometimes it succeeds. More often it stalls on a step it cannot interpret and gives up — a failure you never see, because nothing reaches your inbox.
Our guides to funnel readiness for agentic buyers and writing for agentic parsing cover the wider picture. This post is the engineering layer underneath both: the markup and server-side decisions that make one form completable by an agent without turning it into a spam funnel.
Why forms defeat agents (and what that says about your form)
The uncomfortable finding first. WebAIM’s annual accessibility analysis of the top one million home pages, published in February 2026, reports that 95.9% of home pages had detected WCAG 2 failures — up from 94.8% the previous year — and that “Missing form input labels” appeared on 51% of home pages. Home pages carried 6.9 form inputs on average, and WebAIM states plainly: “One third (33.1%) of those form inputs were not properly labeled.”
That is the takeaway worth stating before any tactic: agent-completability and accessibility are very nearly the same problem. Both a screen reader and a browsing agent build their understanding of your form from the accessibility tree, not from your visual design. A field whose only identity is grey placeholder text that vanishes on focus is a guessing game for both — and forms that fail agents were failing disabled users long before any agent showed up.
The design rules that make a form agent-completable
1. Real labels, bound to real inputs
Every control gets a <label for="..."> pointing at the input’s id, or wraps it. Placeholders are not labels; text merely sitting near a field is not a label. This is the floor, and it is W3C’s WCAG 2.2 Success Criterion 3.3.2 Labels or Instructions (Level A): “Labels or instructions are provided when content requires user input” (WCAG 2.2, W3C Recommendation, 12 December 2024).
2. Standard autocomplete tokens on every personal field
This is the highest-leverage single change, and the one most B2B forms skip. The WHATWG HTML Standard defines a fixed vocabulary of autofill field names in its autofill section — a living standard, so the list grows, but the tokens you need are long-settled — among them name, given-name, family-name, email, tel, tel-country-code, organization, organization-title, country and url. The token states what a field wants regardless of what the visible label says.
W3C treats this as an accessibility technique, not a browser convenience. Technique H98, “Using HTML autocomplete attributes”, is a sufficient technique for SC 1.3.5 Identify Input Purpose (Level AA), and W3C describes its objective as “to programmatically link a pre-defined and published taxonomic term to the input, so that the inputs can also be machine-interpreted”. WCAG 2.2’s own list of input purposes is, in W3C’s words, “based on the control purposes defined in the HTML specification’s Autofill section” — the same vocabulary, twice endorsed.
Honest caveat: SC 1.3.5 and the autocomplete attribute only cover fields collecting information about the user. There is no standard token for “monthly outbound call volume”. For those, use a clear label, a sensible name attribute and, where the answer is a fixed set, a real <select> or radio group.
3. A path that works with JavaScript switched off
Build the form so a plain <form method="post" action="..."> submission produces a valid lead, then layer JavaScript on top for polish. If the form only submits via a fetch call wired to a click handler, or the submit button is a <div> with an onclick, you have made the lead conditional on your script executing exactly as designed in an environment you do not control. Progressive enhancement turns out to be an agent-readiness strategy.
4. Honest required-field marking
Put the required attribute on genuinely required inputs and reflect it in visible text — an asterisk with a legend, not an asterisk alone. Two anti-patterns break agents specifically: hidden required fields (display:none until some other choice reveals them, but still blocking submission) and fields required only by server-side rules with no client-side signal. In both cases the agent submits what it can see, gets a rejection it cannot map to a field, and has nothing to correct.
5. One phone field, not a dial-code widget
Country-code choosers that pre-fill a dial code break agents in a predictable way: the agent types a full international number into a field already containing “+1”, producing a malformed value — or it cannot operate the custom chooser at all. Prefer a single <input type="tel" autocomplete="tel"> that accepts E.164 and normalises server-side. If you must split it, use tel-country-code and tel-national on native controls.
6. Machine-readable success and error states
An agent needs to know, in text, whether it succeeded; a toast that fades after three seconds tells it nothing. Four rules: return a distinct success URL carrying a plain-text confirmation and a reference number in the page body; attach validation errors to fields with aria-describedby and set aria-invalid="true"; put an error summary in a role="alert" container at the top of the form; and state the expected format in the error text (“Enter a phone number including country code, for example +61 2 5550 0000”), not just “Invalid”.
7. Do not lose what was already entered
WCAG 2.2 added SC 3.3.7 Redundant Entry (Level A): “Information previously entered by or provided to the user that is required to be entered again in the same process is either: auto-populated, or available for the user to select.” Multi-step wizards that clear on back-navigation or on a validation failure violate this — and they burn an agent’s task budget until it abandons. Preserve state server-side, keyed to a session, and repopulate on redisplay.
Which form patterns actually work for agents?
| Form pattern | Agent-completable? | Accessibility | Spam exposure | Recommended use |
|---|---|---|---|---|
| Single-page semantic form (native controls, labels, autocomplete tokens, non-JS submit) | Yes — the reliable case | Strong by construction; meets SC 3.3.2 and 1.3.5 with H98 | High if unguarded — must be paired with server-side filtering | Default for every top-of-funnel form: demo, contact, partnership application |
| JavaScript multi-step wizard (steps built and submitted by script) | Partially — stalls on lost state and disabled next buttons | Risks SC 3.3.7 if state is lost on back-navigation | Lower, incidentally — friction deters crude scripts | Only past the qualification point, and only with a plain-form fallback link |
Chip / button-group chooser (styled <div>s, no radio semantics) |
Rarely — no accessible name, no value, no role to operate | Poor unless built on native radios or full ARIA radiogroup | Low | Fine visually, but build it on <input type="radio"> underneath |
| CAPTCHA-gated form | Unreliable — may stall the whole task, and behaviour is undocumented | W3C documents significant harms (see below) | Reduced, not eliminated — solver services are cheap | Reserve for endpoints with demonstrated abuse; never on a first-touch demo form |
| Conversational widget as the only path (third-party chat script) | No — the script may never execute for the agent | Varies wildly by vendor; often keyboard-hostile | Low | Additive channel only; always mirror it with a real form |
The honest tension: agent-completable is also bot-completable
Everything above lowers the cost of submitting your form for a legitimate agent — and by exactly the same amount for a spam script. Pretending otherwise would be dishonest. The answer is not to re-add friction at the gate; it is to move filtering somewhere it does not punish the buyer.
Validate impossible combinations server-side. Real enquiries are internally consistent; generated ones are not. Check that the stated country agrees with the phone country code; that a claimed company domain resolves and has MX records; that free-text fields contain no link markup. None is conclusive alone, and none should hard-block — score them, and route low scorers to a review queue rather than deleting them.
Be careful with honeypots. This next point is a design inference rather than a measured result, so treat it as advice: the classic hidden decoy field looks like a trap for agents too, because a DOM-reading agent may encounter a field no sighted human does, fill it helpfully, and classify itself as a bot. We have not seen published measurements of how often that happens. As a precaution, if you use one, hide it with aria-hidden="true" and tabindex="-1", label it “leave this field blank”, and treat a filled honeypot as one signal among several rather than an instant rejection.
Verify after submission, not before. The strongest filter is a confirmation step that needs a real person in the loop: a one-time link emailed to the address supplied, or a scheduled call-back. An agent acting for a genuine buyer passes that on, because its principal owns the inbox; a spam script usually cannot. This is compatible with WCAG 2.2 SC 3.3.8 Accessible Authentication (Minimum), which targets “cognitive function tests” such as puzzle-solving and transcription — an emailed link is not one. Note honestly that SC 3.3.8 governs authentication processes specifically, so it does not by itself outlaw a CAPTCHA on a marketing form; the case against that CAPTCHA is 3.3.2, 1.3.5 and conversion arithmetic, not 3.3.8.
On CAPTCHA specifically, W3C published “Inaccessibility of CAPTCHA: Alternatives to Visual Turing Tests on the Web” as a Group Draft Note dated 16 December 2021. The Note records an observation it credits to software developers at Cloudflare: “a CAPTCHA not only separates computers from humans, but also often prevents people with disabilities from performing the requested procedure.” It is a Note, not a Recommendation, and it predates the agent wave — but a second class of legitimate visitor now fails the same test.
Where agent identity stands. The long-term fix is for agents to prove who they are. The IETF chartered a Web Bot Auth working group in October 2025 to standardise that; the drafts circulating in it build on HTTP Message Signatures, so an automated client signs its requests and a server verifies the operator. As at 26 August 2026 the group is active but has adopted no working-group draft and published no RFC — the documents remain individual submissions. We cover the mechanism in detail in Web Bot Auth: cryptographically signed AI agents. Treat it as a direction of travel, not a control you can rely on this quarter.
Where this touches what we build
Zian AI builds autonomous AI sales agents across phone, SMS, email and WhatsApp, and the form is only ever the handover point. What makes agent-completable forms matter commercially is the minutes after submission: an enquiry arriving at 02:00 from a buyer’s agent decays exactly like a human one, except nobody is awake and the agent has already moved to the next vendor on its list — the same argument we make about speed to lead and inbound agent callers. But if the form is the bottleneck, none of that matters. Fix the form first; it is cheaper than any platform. Zian is in waitlist and partnership beta — no self-serve signup, no published pricing.
FAQ
Does making my form agent-completable mean I will get more spam?
Slightly, yes, and you should plan for it rather than deny it. The trade is a small increase in junk submissions against not losing enquiries from buyers whose agent could not finish your form. Manage it with server-side consistency scoring, rate limiting, and a post-submission confirmation step — all of which run after submission, where they cost a legitimate buyer nothing.
Are accessibility standards and agent-completability really the same thing?
They overlap heavily but are not identical. WCAG 2.2, published by W3C as a Recommendation on 12 December 2024, gets you almost all the way: SC 3.3.2 (labels), SC 1.3.5 (identify input purpose, satisfied by the autocomplete tokens in Technique H98) and SC 3.3.7 (redundant entry) map directly onto what an agent needs. What WCAG does not require is a no-JavaScript submission path or a stable machine-readable success state, and those two are genuinely agent-specific. Treat WCAG as most of the work, not all of it.
Which autocomplete tokens should a B2B demo form use?
For a typical demo or partnership form: name (or given-name and family-name), email, tel, organization, organization-title, url and country. All are drawn from the list of autofill field names in the WHATWG HTML Standard’s autofill section. Do not invent tokens — a non-standard value is ignored, and you are back to guessing.
Should I block AI agents from submitting forms altogether?
Only if you are certain your buyers never delegate. The submission is not the agent’s — it is the buyer’s, made through software they instructed. Blocking it is functionally the same as blocking the buyer, with the added disadvantage that you never learn it happened. A more defensible position is to accept agent submissions, mark them internally where you can detect them, and hold them to the same verification step as everything else.
How do I test whether my own form is agent-completable?
Three cheap tests, in ascending order of realism. First, disable JavaScript and try to submit — if you cannot, no agent will reliably manage it either. Second, run an automated accessibility checker and fix every missing-label and missing-name error; given that WebAIM found 33.1% of form inputs across the top million home pages were not properly labelled, expect to find some. Third, give a browsing agent the actual task — “book me a demo with this vendor” — and watch where it stops. The third test finds what the first two miss.
Apply for partnership
If your forms are already agent-ready, the next question is what happens to the lead in the following sixty seconds. Zian AI is onboarding partners in waitlist beta. Apply For Partnership.