An agent that wants to book a demo, request a quote or run a scan on your site has to get through a form. It does that the way a screen reader user does: it reads the markup, works out what each field wants from the label attached to it, fills the fields, and activates the submit control. Every step depends on something being present in the HTML, and each of the three things check C1 looks for is a step an agent cannot take without it.
C1 is worth 5 of the 25 actionability points and carries a Medium effort rating. The rubric's definition is one sentence: every input carries a label or aria-label, input types are correct (email, tel, number), and submit is a real button. This post goes through what the scanner does with each clause, what wrong and right markup look like, and what happens when a site has no forms at all.
What the scanner does
The check runs over every crawled page that returned a 200 with a body, and it reads the raw HTML, the first of the two fetches, before any JavaScript runs. A form that only exists after hydration is not a form as far as C1 is concerned, because most agents never receive it.
For each form element the scanner collects every input, select and textarea, skips inputs of type hidden, submit and button, and asks three questions of what remains.
Is it labelled? A control counts as labelled if the form contains a label whose for attribute matches the control's id, if the control carries an aria-label or aria-labelledby, or if the control sits inside a label element. The label[for] lookup is scoped to the form, so a label placed outside the form tag is not found. A placeholder is never a label.
Is the type right? The scanner reads the control's name and id for hints. A name containing email or e-mail is expected to be type="email"; one containing phone, tel or mobile is expected to be type="tel"; one containing quantity, qty, amount or number is expected to be type="number". A control whose name says one thing and whose type says another counts as a wrong type. Nothing else is inferred: a field called company can be any type it likes.
Is there a real submit? The form needs a button with type="submit", an input with type="submit", or a button with no type attribute at all, which the HTML specification treats as a submit button. A button type="button" with a click handler does not count, and neither does a styled div. This clause is evaluated across the whole crawl: one form on one page without a submit control fails it for the site.
The five points are then assembled as three parts. The fraction of controls that are labelled is multiplied by three, so a form with four fields and one unlabelled scores 2.25 on that part. One point is awarded if no control has a wrong type, and one if every form has a real submit control. The evidence block on the report shows forms, inputs, unlabelled, wrongTypes and realSubmit, so you can see which part cost you.
The wrong form
This is the shape of most contact forms we see. It looks fine in a browser.
<form>
<input name="name" placeholder="Your name">
<input name="email" placeholder="Work email">
<input name="phone" placeholder="Phone">
<div class="btn" onclick="submitForm()">Send</div>
</form>
Against C1 it scores zero. Three controls, none labelled, so the labelling part is 0 of 3. Two of them have names that promise email and tel and carry the default text type, so the type point is lost. The only thing to press is a div, so the submit point is lost. The div also registers under C2 and C3 as a clickable element that is not a button, so this one form costs points in three checks.
The right form
The same form, written so that a person, a screen reader and an agent all read it the same way.
<form action="/contact" 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>
<label for="phone">Phone</label>
<input id="phone" name="phone" type="tel" autocomplete="tel">
<button type="submit">Send</button>
</form>
Full marks, and nothing here is a trick. Each label is associated by for and id, each type matches the content, and the submit control is a button. The action and method attributes matter too: an agent that does not drive a browser reads them to construct the request itself, and a form with no action submits to the current URL, which is rarely what the JavaScript that used to handle it had in mind.
Why a placeholder is not a label
A placeholder is hint text drawn inside an empty field. It disappears the moment the field has a value, it is not announced as the field's name by assistive technology, and the scanner ignores it entirely. WCAG has treated this as settled for years: Success Criterion 1.3.1 (Info and Relationships) and 3.3.2 (Labels or Instructions) in WCAG 2.2 both expect a programmatic label, and 4.1.2 (Name, Role, Value) expects every control to expose a name. An agent reading your form is, in the relevant sense, assistive technology.
If the design has no room for a visible label, hide it visually rather than removing it. A label with a screen-reader-only class is still a label to the parser, and so is an aria-label on the input. Our own scan form does exactly this: the label reads "Your website address", it is present in the HTML, and it is not drawn.
Input types are metadata, not decoration
type="email", type="tel" and type="number" do three jobs at once. They tell a mobile browser which keyboard to show. They tell autofill which stored value belongs in the field. And they tell anything reading the markup what the field is for, without that reader having to guess from a placeholder. MDN's reference for the input element lists every type and the constraints each one applies.
Those constraints are the part to be careful with. A type that carries native validation will refuse to submit a value it considers malformed, and it does so silently, with a browser tooltip that an agent driving a headless browser never reads. type="url" is the one that catches people, because it rejects a bare domain, which is precisely what a placeholder like yourcompany.com invites. The scanner does not penalise type="url"; it simply expects email, tel and number where the name calls for them, and leaves the rest to you. Choose types for what they say about the field, and make sure what they reject is what you want rejected.
Why Enter-to-submit leaves an agent with nothing
A form with a single text field submits when a person presses Enter. That is implicit submission, and it is a browser behaviour, not a property of the form. Nothing in the markup says "this form can be submitted". A person never notices, because the person is the one pressing the key.
An agent driving a browser looks for something to activate. It finds the field, fills it, and then looks for a submit control, and when there is none it has a filled form and no next step. An agent that does not drive a browser is worse off still: a submit button's name and value are part of the request the form makes, so without the button the agent cannot even be sure it has reconstructed the request correctly.
We know this because it cost us a point. The search field in our own header had no submit button; the magnifying-glass icon was decoration and the form relied on Enter. It now carries a button type="submit", the icon is the button's content, and the comment in the component says why. It is a one-line fix, and it is a one-line fix on most sites, which is why it is worth a whole point on its own.
A site with no forms
If the crawl finds no form element on any page, C1 awards 3 of its 5 points and records formsFound: 0 in the evidence. The reasoning is in the check itself: no forms is not a failure, but it is also not evidence that forms would work. A site that has nothing to fill in has nothing to get wrong, and equally nothing to get right.
The practical consequence is that adding a form is a two-point decision. A contact form that passes all three clauses takes you from 3 to 5; one that fails them can take you to 0. Building it correctly is not harder than building it badly, it is just a matter of using the elements HTML already provides. The rubric rates the whole check Medium effort, and the three tiers of fixes explains what that rating means for a typical site, but for a single form the work is measured in minutes.
Check your own site
Run the free scan and look at C1 on the report: the evidence block tells you how many controls were found, how many had no label, how many carried the wrong type and whether every form had a submit control. The full definition sits under actionability on the methodology page, and our own report at /site/agentfriendlyrank.com shows what the check looks like when it passes.