What 1.3.5 requires
The purpose of each input field collecting information about the user can be programmatically determined when:
- The input field serves a purpose identified in the Input Purposes for user interface components section; and
- The content is implemented using technologies with support for identifying the expected meaning for form input data.
Typing the same name, address and phone number into every form is hard for people with memory, language or motor disabilities. When a field says in code that it wants the user’s telephone number, the browser can offer to fill it in, and assistive technology can show a familiar symbol next to it. Understanding 1.3.5 gives the example of a birthday cake in front of a field with autocomplete="bday".
It covers only fields that collect information about the user, and only the 53 purposes WCAG lists, from name and email to cc-number and bday. A gift recipient’s address or a discount code is out of scope. The type attribute is not enough: type="email" says the value is an email address, not whose. A field that takes either of two kinds of data, such as “email or username”, may have one token or none.
In HTML, a token in autocomplete is the sufficient technique (H98), and a wrong token is WCAG failure F107. Turning autofill off does not lift the requirement: the Understanding document points to ways of switching it off for a whole form while each field keeps its token.
Common failures
Under each example: what axe-core and Rampa reported on the markup before the fix, in a run with Gemma 4 12B on 9 October 2026.
A checkout field with no token
The label says what the field wants, but nothing in the code says it is the buyer’s own phone number, so the browser cannot offer to fill it in. axe-core’s rule reads autocomplete only where the attribute exists.
Before, fails 1.3.5
<label for="phone">Phone</label>
<input id="phone" type="tel" name="phone">After, passes
<label for="phone">Phone</label>
<input id="phone" type="tel" name="phone"
autocomplete="tel">- axe-core
Passes: without the attribute,
autocomplete-validhas nothing to check.- Rampa
✗ #phone The field "Phone" asks for the user's telephone number but does not identify that purpose: autocomplete="tel" is missing. Evidence: "Phone" Patch: - <input id="phone" type="tel" name="phone"> + <input id="phone" type="tel" name="phone" autocomplete="tel"> confidence high · 1/1 runs · evidence verified · id 4c2e69b817f5
A token copied from the field above
The last-name field was copied from the first-name field and kept its token, so the browser fills in the first name twice. A valid token that names the wrong data is WCAG failure F107, and no rule can see it: given-name is a valid token on a text field.
Before, fails 1.3.5
<label for="last-name">Last name</label>
<input id="last-name" name="last-name"
autocomplete="given-name">After, passes
<label for="last-name">Last name</label>
<input id="last-name" name="last-name"
autocomplete="family-name">- axe-core
Passes:
given-nameis a valid token for a text field.- Rampa
✗ #last-name The field "Last name" asks for the user's last name, but autocomplete="given-name" says it holds their first name. Evidence: "Last name" Patch: - <input id="last-name" name="last-name" autocomplete="given-name"> + <input id="last-name" name="last-name" autocomplete="family-name"> confidence high · 1/1 runs · evidence verified · id 622726c51027
A date of birth without a token
A coffee club asks for a date of birth to send a gift. With autocomplete="bday", the browser can fill it in, and assistive technology can mark the field with a symbol people already know.
Before, fails 1.3.5
<label for="birthday">Date of birth</label>
<input id="birthday" type="date" name="birthday">After, passes
<label for="birthday">Date of birth</label>
<input id="birthday" type="date" name="birthday"
autocomplete="bday">- axe-core
Passes: there is no
autocompleteto check.- Rampa
✗ #birthday The field "Date of birth" asks for the user's date of birth but does not identify that purpose: autocomplete="bday" is missing. Evidence: "Date of birth" Patch: - <input id="birthday" type="date" name="birthday"> + <input id="birthday" type="date" name="birthday" autocomplete="bday"> confidence high · 1/1 runs · evidence verified · id 44b3a6c66532
What axe-core checks
axe-core 4.14.0 maps one rule to 1.3.5. autocomplete-valid fails an autocomplete value that is not a valid token, or a token the field’s type does not take; ACT rule 73f2c2 tests the same thing. Rampa reports its failures as they are, and a field that autocomplete-valid failed never goes to the model.
| Rule | What it checks | Mapped to | In a Rampa run |
|---|---|---|---|
autocomplete-valid, rule page at Deque University | autocomplete attribute must be used correctly | 1.3.5 | runs |
It applies only to fields that have the attribute, and it does not read the label. A field without autocomplete passes, and so does a valid token that names other data, such as given-name on a last-name field. Whose data a field collects is not something a rule can tell.
Each rule links to its page at Deque University, which makes axe-core.
What Rampa judges, and how
What goes to the model
Every visible field that takes text or a choice and that autocomplete-valid did not fail: text, email, tel, url, password, number, date and month inputs, select and textarea. Search boxes, buttons, checkboxes, radio buttons, and hidden, disabled or read-only fields are left out, and so is a field with neither a name nor a placeholder, which is for axe-core’s label rule.
What the model sees
- The label, or the placeholder when there is none.
- The input type, its
nameandid, and the first options of aselect. - What the current
autocompletesays: missing, a value that names no purpose such asoff, or the data its token names. - The visible heading above the field, and the fieldset legend or group it sits in.
- The labels of the other fields in the same form and its buttons: a “Name” next to “Card number” is the name on the card.
- Every token with its meaning, written into the prompt, because local models do not read the JSON schema.
What it must answer
First, what the field asks for, in a few words; then whose information it is (the user’s, someone else’s or nobody’s), the token for that purpose or none, a verdict, the label copied as evidence, and a confidence.
What drops a claim
- The evidence is not the label or the placeholder.
- A fail is about data that is not the user’s, or names no purpose.
- The purpose is not on the WCAG list, such as
one-time-code, or is a transaction amount or currency, which the Understanding document notes are rarely about the user. - The token is one that axe-core’s own table does not allow on that field, so the patch could break the engine rule.
- The current token already names that purpose or a close one, such as
telandtel-national,emailandusername, ornew-passwordandcurrent-password. - The field is a language or country selector with no other field around it: it switches the page, it does not collect data.
The patch
Adds autocomplete with the token, or replaces the current value, keeping a section-* prefix and billing or shipping.
For every criterion
- Page content reaches the model marked as data, and the prompt tells it to ignore any instruction inside.
- Answers are cached by a hash of the prompt, the image, the model and its settings, so the same input never calls a model twice.
--runs 3asks three times and keeps the majority; when runs disagree, confidence drops. Findings below--min-confidence(medium by default) are hidden, and--verboselists them.- Claims dropped by verification are counted in every report, never shown as findings.
How Rampa was measured on it
| Set | Tests | Cases | axe-core, precision / recall | Rampa, precision / recall / F1 |
|---|---|---|---|---|
| 1.3.5, autocomplete is valid (ACT 73f2c2) | syntax | 30 | 1.00 / 1.00 | 0.83 / 1.00 / 0.91 |
Corrupted pairs: Rampa told 8 of 9 apart (autocomplete removed) and 6 of 7 apart (autocomplete swapped for other data), axe-core 0. A pair is a passing test page and a copy broken on purpose; a checker that gives both the same verdict is not judging.
Run on 9 October 2026: axe-core 4.14.0, Gemma 4 12B on a local GPU, reasoning off, one run, ACT test cases a9a1483e. Small samples and one run: read the numbers as a working pipeline, not as a result.
Read with these caveats
- ACT rule 73f2c2 measures the engine: whether a token is valid. With the judgment on, precision drops to 0.83, because two of its inapplicable cases, a “Username” field with
autocomplete="", are 1.3.5 failures that Rampa reports. - No ACT rule judges a missing or wrong token, so the judgment is measured on pairs made from 73f2c2’s passing pages, with the token removed or swapped for a valid token for unrelated data. The one miss in each kind is “Partner’s email address”, someone else’s data, where passing is right.
- The prompt and the context were revised after reading the errors of earlier runs on these cases, without copying test pages into the prompt. Read the numbers as a working pipeline, not as a result.
Limitations
- In the run recorded for this page, Gemma rightly passed a gift recipient’s email, in English and in Portuguese. In Portuguese it also passed “Telefone”, answering that the phone was someone else’s: a miss.
- Whether data is about the user is the model’s call, and a gift recipient, a partner or a child can be misread either way.
- A field that combines two purposes, such as “email or username”, passes without a token, as the Understanding document allows.
- It reads the HTML
autocompleteattribute only, on web pages. Other ways to expose a purpose, such as the WAI-Adapt symbols module, are not read. - On real pages it found newsletter and sign-in fields without tokens on mozilla.org, kabum.com.br, saucedemo.com and wordpress.org, and passed GitHub’s sign-in. A false-positive study on real pages is on the roadmap.
Questions about 1.3.5
Does autocomplete="off" fail WCAG 1.3.5?
On a field for the user’s own data, yes: off names no purpose, and the Understanding document says the purpose still has to be programmatically determinable when authors stop browsers from autofilling. It points to ways of switching autofill off for a whole form while each field keeps its token. Rampa reports off on such a field as not identifying its purpose.
Does 1.3.5 apply to every form field?
No. Only to fields that collect information about the user, for one of the 53 purposes WCAG lists. A search box, a quantity, a discount code or a gift recipient’s address needs no token. The Understanding document notes that a few listed purposes, such as transaction-amount, are rarely about the user.
Is type="email" enough?
No. The Understanding document explains that type="email" says the value is an email address, not whether it is the user’s or someone else’s. autocomplete="email" says it is the user’s.
Does axe-core check 1.3.5?
In part. autocomplete-valid checks that an autocomplete value is a valid token that fits the field. It does not check fields without the attribute, or whether the token names the data the label asks for.
Check your pages
Rampa is not on npm yet. Clone it and run it from source with Node.js 22.12 or newer and Chrome or Edge. --criteria 1.3.5 judges only this criterion; leave it out to run the eight that run by default.
With Ollama running, Rampa picks a local model by itself; node dist/cli.mjs doctor says what is missing.
git clone https://github.com/guilhermebsantiago/rampa-cli.git
cd rampa-cli
pnpm install && pnpm build
node dist/cli.mjs check https://example.com --criteria 1.3.5Checked against rampa-cli (commit 0459809) and the W3C sources on 9 October 2026.