Text Input
Free-form entry, where the label, the hint and the error placement do most of the work.
Definition
A text input collects typed data. Its usability is determined almost entirely by whether the user knows what to type, whether the field accepts what they type, and what happens when it does not.
Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.
On this plate
Reach for this when
- Collecting free-form data.
- Any form field without a fixed set of options.
Common mistakes
- Placeholder used as the label.
- Missing autocomplete attributes.
- Paste disabled.
- Field width unrelated to expected content.
Anatomy
- A visible label above the field, always. Placeholder-as-label fails as soon as the user types.
- Optional hint text below the label, describing format or purpose before the user types.
- The field itself, with a visible border meeting 3:1 non-text contrast.
- Error text below the field, associated with aria-describedby, with aria-invalid on the field.
- Character counters where a limit exists, announced politely rather than on every keystroke.
Details that matter more than they look
- Set autocomplete attributes correctly. WCAG 1.3.5 requires them for fields collecting user information, and they make browser autofill work.
- Use inputmode and type to bring up the right mobile keyboard.
- Size the field to suggest the expected input length. A postcode field the width of an address is misleading.
- Never disable paste. It breaks password managers and is a genuine accessibility barrier.
- Accept the formats people actually type, and normalise on the server.
Details that change the typing experience
| Attribute | Effect |
|---|---|
| type and inputmode | Which keyboard appears on mobile |
| autocomplete | Whether the browser or password manager can fill it |
| enterkeyhint | What the return key on a mobile keyboard says |
| spellcheck and autocapitalize | Whether names and codes get mangled |
| maxlength | Silent truncation, so it needs a visible counter |
| Field width | An implicit hint about the expected length |
In practice
- i.
The postcode field that autocapitalised
Small attributes, large irritationMobile keyboards capitalised and autocorrected a code field, so half the entries arrived malformed. Three attributes fixed what had been logged as a validation problem for months.
- ii.
A field the width of its content
Size as a signalA three-character field for a country code and a wide one for a street address tell the reader what is expected before they type. Uniform widths throw that information away.
Local chart
CMP·003 · Region III · Grid F2
This entry and the entries it is stated to connect with. Each line is labelled with what the connection means.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Applies when you are designing
Principles behind this
The reasoning this solution is an application of.
- Postel's LawLAW·012 · Law
- Borders and DividersFND·047 · UI foundation
Depends on
Get these right first, or this one will not hold.
- Labels and InstructionsA11Y·017 · Accessibility
Often used with
These usually appear in the same screen or the same decision.
- SelectCMP·004 · Component
- SliderCMP·008 · Component
- AuthenticationPAT·023 · Pattern
- Autocomplete and TypeaheadPAT·003 · Pattern
- Input ValidationPAT·007 · Pattern
Check your work
Review passes that test whether this was done properly.
- Form UX ChecklistCHK·001 · Checklist
Related concept
Connected closely enough to change how you apply this.
- Error MessagesWRT·002 · UX writing
- Form Labels and Help TextWRT·009 · UX writing
- Inclusive LanguageWRT·005 · UX writing
- InternationalizationWRT·006 · UX writing