Autocomplete and input types
The attributes that decide which keyboard appears and whether the browser can fill a field, including the health fields for which no autofill token exists.
When to use
Every text or numeric field, every time. These attributes cost one line each and they decide three things the reader notices immediately: which keyboard appears, whether the browser or password manager can fill the field, and whether the value survives being typed on a phone.
They are also a conformance requirement. WCAG 2.2 SC 1.3.5 (Identify Input Purpose) requires that fields collecting information about the user carry the corresponding autofill token, where one exists in the HTML specification's list of autofill field names.
When not to use
- The value is not about the reader. A search box, a note, a free-text
symptom description: no autofill token applies, and inventing one is worse
than omitting it.
autocomplete="off"is the honest answer. - The field is a one-time code. Use
autocomplete="one-time-code", not a numeric-only trick, and make sure paste works. WCAG 2.2 SC 3.3.8 (Accessible Authentication) exists partly because segmented code inputs commonly break it. - You want the wiring. Controlled inputs, masks and parsing are Handbook → Forms.
How it works
Four attributes, in the order they matter.
flowchart TD
A["A field"] --> B{"Is it about the reader?"}
B -->|"yes"| C{"Is there a spec autofill token?"}
C -->|"yes"| D["Set autocomplete to that token"]
C -->|"no"| E["autocomplete off, and do not invent a token"]
B -->|"no"| E
D --> F{"Is the answer numeric?"}
E --> F
F -->|"yes"| G["type text plus inputmode decimal or numeric"]
F -->|"no"| H["The semantic type: email, tel, url, date"]
G --> I["enterkeyhint, autocapitalize, spellcheck as appropriate"]
H --> Iautocomplete
Use the tokens from the HTML specification's autofill field names. That is the same list WCAG 2.2 SC 1.3.5 points at. The ones a consumer health product actually needs:
| Field | Token |
|---|---|
| Full name | name |
| First and last name separately | given-name, family-name |
| Date of birth, one field | bday |
| Date of birth, three fields | bday-day, bday-month, bday-year |
email | |
| Phone | tel |
| Address | street-address, address-level2, postal-code, country-name |
| Sex, as an administrative field | sex |
| One-time code | one-time-code |
| Password | current-password, new-password |
There is no autofill token for a health reading. No height, no weight,
no blood-pressure, no medication. This is correct and you should not
approximate it: setting autocomplete="on" on a weight field invites the
browser to offer an unrelated stored value, and setting a made-up token does
nothing at all. Use autocomplete="off" and rely on your own prefill from the
reader's previous entry. See Daily logging.
inputmode and type
For any number a reader types, prefer type="text" with inputmode="decimal"
over type="number". type="number" looks like the obvious answer and brings
several problems that are specifically bad for health values:
- The scroll wheel and arrow keys change the value when the field has focus, so a reader scrolling the page can silently alter a reading.
- Leading zeros and trailing decimal points are handled inconsistently.
- Locale decimal separators, such as a comma in much of Europe, are handled inconsistently, and the field may report an empty value for something the reader can see they typed.
- Spinner buttons are small targets that do not meet the 44pt floor and invite thirty taps to reach 138.
inputmode="decimal" gets the numeric keypad without any of that.
Use inputmode="numeric" for integers with no decimal part, type="tel" for
telephone numbers (never for other digits), and type="email" for email.
The rest
enterkeyhint="next"or"done"so the return key does what the reader expects at the end of a sequence.autocapitalize="none"andspellcheck="false"on codes, identifiers and units. A red squiggle under a medication name the reader spelled correctly is a small, repeated insult.autocorrect="off"on medication names, which autocorrect mangles reliably. See Medications.
Content
Do
A weight field: type="text" inputmode="decimal" autocomplete="off", with
the unit displayed beside the field rather than typed into it.
Don’t
type="number" with a spinner, no inputmode, and the unit expected inside
the value as "72 kg".
Do
Three date-of-birth fields with bday-day, bday-month, bday-year, each
with inputmode="numeric" and a visible label.
Don’t
A single type="date" picker with no keyboard entry path, which is
unusable for a birth year forty years in the past. See
Date of birth.
Accessibility
- WCAG 2.2 SC 1.3.5 is met by using the specification's tokens, not by approximating them. A wrong token is a failure; a missing token on a field that has no applicable purpose is not.
inputmodeis not a label. It changes the keyboard and nothing else; the field still needs a visible label and, where the format is not obvious, a hint.- Never disable paste. It breaks password managers, breaks one-time codes and disproportionately affects readers using assistive technology or switch access. It is also implicated in WCAG 2.2 SC 3.3.8.
- Do not auto-advance between segmented inputs. Moving focus when a segment fills is disorienting with a screen reader and makes correction difficult; see Question pages.
- Spinner controls, where they exist at all, meet the target-size floor in Density and touch targets, and typing is always available as an alternative.
autocomplete="off"does not defeat a password manager and should not be used to try. Use it only where no purpose applies.
Research
Updates to this page
Last read through against the system on 2026-09-20. Due for review every 12 months; expiry is reported by pnpm run check:freshness.
Required and optional
Mark one or the other but never both. In a health product, prefer marking optional, because it makes the cost of every required field visible.
Units and numeric entry
Accepting a number that has a unit attached. The unit never sits inside the field, the value is never ambiguous, and a surprising reading is never rejected.