Use address entry when a service must capture a deliverable or contact address as structured, reviewable parts; use text input for one short freeform value, autocomplete for resolving a known suggestion, and dependent fields for a local country-to-region or type-to-detail relationship.
Use address entry when a service must capture a deliverable or contact address as structured, reviewable parts; use text input for one short freeform value, autocomplete for resolving a known suggestion, and dependent fields for a local country-to-region or type-to-detail relationship.
Practice the judgment: Imagine this situation: Changing the country leaves a stale state field and postcode rule active, causing valid international addresses to fail validation. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.
Review the underlying principle →| Dimension | Address entry | Text input | Autocomplete | Dependent fields |
|---|---|---|---|---|
| UI or UX | UI + UX - Structured postal or contact address capture flow | UI + UX - Single-line freeform data-entry control | UI + UX - Input widget with suggestion behavior | UI + UX - Controlling and dependent form fields |
| UI guidance | Render address capture as a labelled fieldset or page section with address line, locality, region when needed, postal code, country, and an address lookup only when its coverage is clear. | Render a persistent label, appropriately sized single-line input, optional hint, visible focus state, and nearby error text that is programmatically associated with the field. | Expose clear visual states for expanded, focused, highlighted, and selected options. | Place the controlling field before the dependent field, label both clearly, and explain the dependency in helper text such as Choose a category first to see valid subcategories. |
| UX guidance | Use address entry when the service needs a complete address for delivery, billing, correspondence, identity, eligibility, routing, tax, or account records and downstream systems need reliable address parts. | Let users edit normally, validate after interaction or attempted submit, preserve their typed value after errors, and explain exactly how to fix invalid or missing text. | Preserve typed input and make selection reversible before submission. | Help the person reach a clear task outcome. |
| Good UI | A benefits claim asks for postcode lookup, lists matching addresses, includes Enter address manually, and then shows editable address line 1, address line 2, town or city, postcode, and country. | A reference-name field has a visible label, hint, medium width, focus ring, and error message beneath the hint when submitted empty. | Persistent label above the input, readable text size, clear popup alignment, and visible highlighted option. | An incident form asks Category first, then Subcategory shows only options for that category and says why it was cleared after Category changed. |
| Bad UI | A selected address is stored as a provider label rather than structured parts. | The only instruction is placeholder text that disappears when the user starts typing. | Placeholder-only label that disappears after typing. | A stale dependent value is submitted with a new controlling value. |
| Good UX | A user enters SW1A1AA, sees several addresses, selects Flat 2, adds an organization name, and reviews the stored line, town, postcode, and country parts before continuing. | A user leaves the required field blank, sees an error only after submit, returns to the same field, and their later typed value clears the error. | Typing filters suggestions while preserving the exact typed value. | A user chooses Hardware, selects Laptop, switches Category to Network, sees Laptop cleared, and chooses VPN from the new valid list before submitting. |
| Bad UX | A checkout removes Apartment 4B after validation and the parcel is delivered to the wrong household. | Validation fires on the first focus event and blocks typing before the user has had a chance to answer. | Automatically forcing the first suggestion into the field. | A stale dependent value is submitted with a new controlling value. |
| Best fit | The product needs a complete postal, delivery, billing, service, or official contact address. | The answer is short and user-authored. | The list is long but values are known. | A downstream field's valid values or requirement depend on a previous answer. |
| Avoid when | The product only needs one short location label, room name, or delivery note. | The answer is a paragraph, comment, address block, or explanation requiring multiple lines. | The task is open-ended query exploration. | The choices are independent and users need to compare them together. |
| Required state | Initial state with country or domestic coverage explained and lookup or manual entry available. | Empty untouched state with persistent label and optional hint. | Empty input state. | Controlling answer selected, with dependent options filtered to the valid subset. |
| Accessibility burden | Group related address fields with a clear heading or legend that states which address is being requested. | Associate every text input with a visible label or equivalent accessible name that matches the visible question. | Expose combobox expanded state, active descendant, and option labels. | Keep controlling and dependent fields in logical DOM order and use labels, hints, and descriptions that name the relationship. |
| Common misuse | Forcing every address through a domestic postcode or ZIP lookup. | Using placeholder text as the only label or instruction. | Using autocomplete where users expect broad search results. | Leaving a stale dependent value selected after the controlling field changes. |