Design autocomplete for selecting a value

Define what input means

Decide whether the field accepts free text or requires a catalogue entry. Explain this near the label. Typing a string is not automatically selection: a town identifier needs the chosen record, not merely its displayed name.

Disambiguate repeated names with a useful detail, such as department, without collecting unnecessary information. Define accent, hyphen and alternate-name handling from the catalogue. Do not silently select the first suggestion when several remain plausible.

Allow exploration before acceptance

The W3C combobox pattern describes input associated with suggestions and interactions to explore, accept or leave them. Communicate expansion and the active option. Standard text editing should remain available.

Keep a highlighted suggestion distinct from an accepted value. When the list closes, the person should understand what will be submitted. Test keyboard selection, editing after selection and leaving the field without accepting an option.

Handle network and catalogue changes

A slow response for older input must not replace suggestions for newer text. Waiting, no match and service failure are different states. Provide another way forward when autocomplete is a convenience rather than an essential dependency.

An entry withdrawn between selection and submission needs server validation and an actionable response. Preserve other fields while the person selects again. Where results are limited, ask for a more specific search rather than presenting a partial list as complete.

Example: towns with the same name

Educational example: two suggestions share a name but belong to different departments. Each shows both details; submission uses the chosen identifier. Testing selects the second entry, edits the text and checks that the old identifier is not accidentally retained. Another test interrupts the network and checks recovery.