Hypothesis
A field can be named and still be machine-purpose-unknown, and this audit predicts exactly that split. We treat the accessible name and the autocomplete purpose token as two separately checkable channels: one tells an agent what to call the control, the other tells it what kind of information the control expects.
The first channel is the accessible name — the string attached to a control for identification. The second is machine-readable purpose, expressed as a valid token from the WHATWG HTML standard’s form control infrastructure and autofill token list. WCAG 2.2 SC 4.1.2 Name, Role, Value (Level A) governs the name; WCAG 2.2 SC 1.3.5 Identify Input Purpose (Level AA) governs purpose. If the channels were one channel, satisfying either would satisfy both. We predicted a large Present-name / Absent-purpose cell, and a small reverse cell.
Method
On 2026-09-24 the author fetched 27 public URLs across 24 distinct hosts over plain static HTTP and parsed only the server-sent HTML. Nothing was rendered, executed, clicked or probed with assistive technology; every figure below comes from delivered markup alone.
This is desk research on server-sent HTML — no rendering, no JavaScript, no pointer input and no assistive-technology testing were involved.
25 of 27 URLs returned HTTP 200. The two failures were www.w3.org paths returning 403 to datacenter IPs — Akamai-class bot blocking; the pages are live in browsers. The parse found 64 user-facing fields, defined as inputs excluding hidden, submit, button, image, reset, file, checkbox and radio, plus <select> and <textarea> elements. Seven of the 27 pages shipped zero server-rendered user-facing fields, so they contribute to the URL count but not the field denominators.
What Counts as an Accessible Name
A field counted as named if any of four mechanisms produced a programmatic name: aria-label or aria-labelledby (7 fields, 10.9%), a <label for="…"> association (27, 42.2%), a wrapping <label> (17, 26.6%), or the title attribute (2, 3.1%). Those sum to 53 of 64, or 82.8%. MDN’s aria-label reference documents the first mechanism. Placeholder-only fields were recorded as a separate failure class — 6 fields, 9.4% — because a placeholder is an example value, not a name: W3C failure technique F68 treats placeholder-as-only-label as a failure, and Nielsen Norman Group’s guidance on placeholders explains why hints vanish once typing begins. A further 5 fields (7.8%) had no name channel at all. Both failure classes breach WCAG 2.2 SC 4.1.2 Name, Role, Value (Level A) and, where the field takes user input, SC 3.3.2 Labels or Instructions (Level A) — but they breach them differently, and an agent should distinguish the two.
What Counts as a Purpose Token
A field counted as purpose-declared only when autocomplete held a valid user-purpose token naming a type of information about the user — username, email, current-password and the rest of the token list described in MDN’s autocomplete attribute reference. autocomplete="on" and "off" are excluded: they configure autofill behaviour rather than stating purpose. Search-role fields (type=search, or name matching q, s, query or keywords) were identified separately — 16 of 64 — and dropped from the non-search purpose denominator, because Understanding SC 1.3.5 Identify Input Purpose scopes the criterion to information about the user; search terms and generic fields fall outside it. Twelve of 64 fields carried any autocomplete token at all; 17 set off.
An agent that never renders the page is handed some combination of a serialized DOM, an accessibility tree, or computed styles. The serialized DOM is the only one of the three that carries the literal autocomplete token and the label-association markup (<label for>, wrapping <label>, aria-label, aria-labelledby). The accessibility tree exposes the computed accessible name and role but does not preserve which source mechanism produced the name and should not be assumed to expose the raw autocomplete token. Computed styles carry neither. Therefore an agent restricted to the accessibility tree can perceive the resulting name but loses the source-level purpose evidence, and an agent reading only computed styles can infer neither channel — static HTML inspection is the direct route to both, as catalogued in our note on agent-visible resolution.
Results
Across the 64 user-facing fields found, 82.8% carried a programmatic accessible name but only 18.8% carried any autocomplete token, and just 8 fields had both. Naming and purpose track independently: strong label discipline coexists with almost no machine-declared input purpose.
The Name Channel
53 of 64 fields (82.8%) carried a programmatic name, dominated by <label for> associations at 42.2% and wrapping labels at 26.6%; ARIA-based names accounted for 10.9% and title for 3.1%. Six fields (9.4%) were placeholder-only and five (7.8%) had no name channel. Host patterns were strikingly uneven: gov.uk labeled 5 of 5 fields via <label for>; webaim.org’s contrast checker named 12 of 12; openstreetmap.org shipped 8 fields with only 2 named, the other 6 resting on placeholder text alone (“Search”, “From”, “To”). Naming quality varies more by publisher than the aggregate suggests — the framing we used in the baseline measurement post.
The Purpose Channel
Only 12 of 64 fields (18.8%) carried any autocomplete token, while 17 fields declared autocomplete="off". Among the 48 non-search fields in scope, 37 (77.1%) lacked a user-purpose token. The contrast across hosts is the same kind of unevenness seen on the name side: nngroup.com named 6 of 6 fields and set 3 purpose tokens; designsystems.com shipped 5 duplicate email inputs, all correctly labeled, all autocomplete="off"; webaim.org’s contrast checker named every field and declared zero purposes. Purpose declaration is the rarer discipline — the “intent, not just values” argument in our token intent coverage post applies directly here.
Where the Channels Diverge
Two channels, four outcomes (n = 64 user-facing fields)
| Accessible name | Valid purpose token | Fields | What an agent can infer |
|---|---|---|---|
| Present | Present | 8 | Can identify the control and infer the information type it expects |
| Present | Absent | 45 | Can identify the control but not its machine purpose — the largest group |
| Absent | Present | 4 | Can infer the purpose but not the name (Hacker News login) |
| Absent | Absent | 7 | Neither channel; includes all 6 placeholder-only fields |
| Total | — | 64 | Name and purpose are independent channels, not interchangeable |
autocomplete="on" and "off" are not counted as valid user-purpose tokens, and search-role fields stay in the 64-field total but are excluded from the non-search purpose gate.
The two off-diagonal cells are the finding. All 6 placeholder-only fields carried zero purpose tokens, so a field that appears labelled to a human may be silent to a machine on both channels. Meanwhile 4 of the 5 completely unnamed fields carried a correct purpose token: the Hacker News login form sets autocomplete="username", "current-password" and "new-password" on unlabeled inputs. Purpose is stated where a name is not, and names frequently appear where purpose is not: the channels are independent.
Two Computable Rules
Two thresholds turn these observations into pass/fail checks an agent can run on any markup snapshot. named-control-gate requires at least 95% of user-facing fields to hold a programmatic name; purpose-token-gate requires at least 90% of in-scope non-search fields to declare a valid user-purpose token.
Rule 1 — named-control-gate
Formula: fields_with_programmatic_name / user_facing_fields × 100
Gate: ≥ 95. Flag every placeholder-only and every no-name field for review.
Baseline in this sample: 53/64 = 82.8%.
Rule 2 — purpose-token-gate
Formula: non_search_in_scope_fields_with_valid_user_purpose_token / non_search_in_scope_fields × 100
Gate: ≥ 90. Exclude search-role fields and fields outside WCAG 2.2 SC 1.3.5’s scope. autocomplete="on" and "off" do not count.
Baseline in this sample: 11/48 = 22.9%.
Both gates are computable from a single server-sent HTML snapshot, which is also why they are auditable without a browser. Rule 1 fails at 82.8%, a labelling shortfall. Rule 2 fails far more badly at 22.9%, and the search-role exclusion means the shortfall cannot be explained by query boxes: generic and user-information fields simply do not state their purpose.
FAQ
Three objections recur whenever static field audits are discussed: whether placeholders count as names, whether autocomplete="off" is a purpose signal, and whether a small convenience sample supports any general claim. Each has a direct answer grounded in the 64-field dataset and in the applicable WCAG criteria.
Doesn’t a placeholder name a field for an agent?
No. A placeholder is a hint that vanishes on input and is not a programmatic name under WCAG 2.2 SC 4.1.2; W3C technique F68 records placeholder-as-only-label as a failure. All 6 placeholder-only fields counted as unnamed here, and none of them carried a purpose token.
Isn’t autocomplete=“off” a machine-readable purpose signal?
No. It states that autofill should not run; it names no information type. Seventeen of the 64 fields set autocomplete="off" and none thereby gained a user-purpose token. The WHATWG autofill token list — username, email, current-password and similar — is what the purpose gate reads.
Is this a representative audit of web-wide form quality?
No. It is a 24-host convenience sample skewed toward design, engineering and accessibility publishers, parsed from static HTML only, with 2 of 27 URLs returning 403 to datacenter IPs. It supports a mechanism — the two channels are independent — not a prevalence claim about the wider web; see WebAIM Million for census-scale work.
The Bottom Line
The verdict is that naming and machine purpose must be measured separately, because this sample shows them failing separately. Label coverage is respectable at 82.8% yet still below the 95% gate, while purpose declaration collapses to 22.9% against a 90% gate — a gap no label fix will close.
Agents learn to design better when they measure an input’s accessible name and its machine-readable purpose as two separately checkable channels. This static audit of 64 form fields across 24 hosts found 82.8% had a programmatic name but only 18.8% carried a valid user-purpose autocomplete token — and just 8 fields had both. Registering named-control-gate at ≥95% and purpose-token-gate at ≥90% turns that observation into two computable checks, and it also names the repair: the largest single block of fields, 45 of 64, is already identifiable and merely silent about purpose.