Forms an agent can actually fill

An agent fills a form by reading it. There is no other channel. Everything you know from context — that this box wants a business email, that the dropdown must be set before the date picker means anything — is either in the markup or it is lost.

The four attributes that do the work

autocomplete is the one that gets skipped, and it is the one that carries the most information per byte. The HTML standard defines a fixed token list — email, tel, given-name, family-name, organization, street-address, postal-code, country-name, cc-number and so on. A token turns some text field into the user's work email, with no inference required.

Before and after

<form action="/submit" method="post">
  <div class="field">
    <input name="f1" placeholder="Name">
  </div>
  <div class="field">
    <input name="f2" placeholder="Email">
  </div>
  <div class="field">
    <select name="f3">
      <option>Choose...</option>
      <option>Option A</option>
      <option>Option B</option>
    </select>
  </div>
  <div class="btn" onclick="submitForm()">Send</div>
</form>

<form action="/api/quote" method="post">
  <label for="name">Your name</label>
  <input id="name" name="name" type="text"
         autocomplete="name" required>

  <label for="email">Work email</label>
  <input id="email" name="email" type="email"
         autocomplete="email" required
         aria-describedby="email-hint">
  <p id="email-hint">We reply within one business day.</p>

  <label for="service">What do you need?</label>
  <select id="service" name="service" required>
    <option value="">Please choose</option>
    <option value="audit">Agent readiness audit</option>
    <option value="implementation">WebMCP implementation</option>
  </select>

  <button type="submit">Request a quote</button>
</form>

Note the last line of each. <div class="btn" onclick> has no role and no accessible name — an agent addressing controls the way assistive technology does cannot find it at all. <button type="submit">Request a quote</button> is both reachable and self-explanatory.

Errors an agent can act on

When a submission fails, an agent needs to know which field and why. A red border communicates nothing to anything that does not see colour. Put the state in the markup:

<label for="email">Work email</label>
<input id="email" name="email" type="email"
       autocomplete="email" required
       aria-invalid="true"
       aria-describedby="email-error">
<p id="email-error" role="alert">
  Enter a company address — free mailbox providers are not accepted here.
</p>

That message is the difference between an agent correcting the input and an agent abandoning the task. Write the text as an instruction, not an apology.

The CAPTCHA question

A CAPTCHA on your conversion path is a statement that automated visitors are unwelcome. That was reasonable when automation meant scrapers. It is expensive when it means your customer's assistant trying to buy something, and it is worth being explicit about the trade rather than inheriting it from a default.

• Rate limit per session and per IP — cheap, invisible to legitimate use.
• Honeypot fields catch naive bots and cost a real user nothing.
• Score server-side on behaviour and content rather than challenging up front.
• If a challenge is genuinely unavoidable, keep it off the first step and off the read paths.

How we grade it

The forms check is worth 7 points, the heaviest single check outside content rendering. It measures the share of fields carrying a label, a name, a type and a valid autocomplete token, and averages the four. Above 85 per cent is a pass; below half is a fail. If a page serves no form with input fields, the check is excluded rather than failed.