A payroll product's employee-picker combobox silently takes the first suggestion when focus leaves, and wrong people get paid; what went wrong, and which autocomplete behaviour fits?
answer
- four forms of autocomplete
- what happens on leaving the field
- typed text versus chosen value
- two people with one name
- explicit choice for costly picks
basics
~20 sIt uses list autocomplete with automatic selection, so a partial name becomes the highlighted first match when focus leaves. For a costly pick from a fixed set, use manual selection: typing only filters, someone must choose explicitly, and unmatched text is flagged, not replaced.
solid answer
~50 sThe Authoring Practices describe four autocomplete forms for a **combobox**: none; list with **manual** selection, where the typed text stays the value unless the person picks a suggestion; list with **automatic** selection, where the first suggestion is highlighted and becomes the value when the combobox loses focus; and list with **inline** autocomplete, which adds the completion into the field. This picker uses automatic selection, so typing 'Ana' and tabbing away assigns whoever sorts first. That suits quick, low-stakes entry, not payroll. The spec should require manual selection with an explicit choice, options that disambiguate people, such as employee ID and department, a selected value that repeats that detail, and a clear error when the typed text matches nobody. Escape should close the popup without changing a previous choice. Review which values were set by leaving the field rather than by choosing, and correct them.
go deeper
Know that a combobox is a text input with a popup of suggestions, and that the value may be what was typed or what was chosen.
Explain the four autocomplete forms and exactly what each sets as the value when focus leaves the combobox.
Diagnose a silent wrong-value incident, choose manual selection for costly picks, and specify disambiguation, no-match and Escape behaviour across every picker on the component.
Make autocomplete behaviour an explicit, documented property of the system's combobox with a stated default for high-stakes data, instead of an accident of library defaults.
## What a combobox is A **combobox** is an input with an associated popup from which a value can be chosen. In an **editable** combobox people can type, and the typing filters or completes the suggestions; in a **select-only** combobox they can only pick. An employee picker in a payroll product is usually editable, with its value restricted to existing employees. ## The four autocomplete behaviours The WAI-ARIA Authoring Practices name four forms of autocomplete: | Form | What the popup shows | What becomes the value | |---|---|---| | **None** | The same suggestions whatever is typed, such as recent entries | Whatever is typed, or a suggestion if chosen | | **List, manual selection** | Suggestions matching the typed text | The typed text, unless a suggestion is explicitly chosen | | **List, automatic selection** | Matching suggestions, with the first highlighted as selected | The highlighted suggestion when the combobox loses focus, unless the person changes it | | **List with inline autocomplete** | As automatic selection, plus the completion shown inline after the cursor | The highlighted suggestion, as above | ## Why automatic selection went wrong here - **Leaving the field becomes a choice.** A payroll administrator types 'Ana', sees several matches, tabs away to check something, and 'Ana Alves' is now the payee, although they meant 'Anastasia Petrova'. - **The error is silent.** The field shows a complete, valid-looking name, so nothing prompts a second look. - **Duplicate and similar names.** Large workforces have several people with the same name; a picker that shows only names cannot tell them apart. - **Cost is asymmetric.** In a search field, a wrong autocomplete costs a second search. In payroll, it moves money to the wrong person. Automatic selection is not wrong in general: for quickly entering a known city or a tag, it saves keystrokes. It is wrong where a mistaken value is expensive and hard to notice. ## What the spec should require 1. **Manual selection.** Typing filters; the value is set only when a person chooses an option with Enter, a click or a tap. 2. **Restricted value.** Because the value must be an existing employee, text that matches nobody is not silently kept, replaced or cleared; the field shows an error such as 'No employee matches Anaa. Choose from the list.' 3. **Disambiguating options.** Each option shows name plus employee ID and department, so two people called Maria Lopez are distinguishable. 4. **A confirmed selected state.** After choosing, the field shows the chosen person with the same detail, so the result is checkable at a glance. 5. **Safe exploration.** The Authoring Practices note that a combobox can let people browse suggestions and press Escape to close the popup without changing their previous input; the spec should require that, so looking never changes the payee. 6. **Empty and slow states.** 'No matches' is shown as text in the popup; slow results show progress rather than an empty list that looks like no matches. ## Keyboard contract, briefly From the combobox, Down Arrow moves into the popup; within the popup, Up and Down move between options, Enter accepts the focused option and closes the popup, and Escape closes the popup and returns focus to the combobox. The typing field keeps the platform's normal text-editing keys; the component must not swallow them. ## Diagnosing and repairing the incident - Find records whose value was set by leaving the field rather than by an explicit choice, if the product can tell, and review them. - Run a quick usability session with administrators on real, messy data: duplicate names, partial names, people who changed their name. - Ship the fix across every picker built on the same component, not only the one in the payroll run. ## Across platforms Web and native mobile search-and-pick controls share the same decision: whether leaving the field or dismissing the keyboard commits a suggestion. The spec should name the behaviour, manual or automatic selection, rather than inherit whichever default one platform or library ships.
- When is list autocomplete with automatic selection the better choice?When entries are frequent, low-stakes and easy to spot if wrong, such as adding a known tag or a city. The highlighted first match saves keystrokes for expert users. Even then, the highlighted suggestion must be visible and announced, so people know what leaving the field will commit.
- How should the picker handle an employee who is not in the list yet, such as a new hire?Say so plainly in the popup, for example 'No employee matches. New hires appear after onboarding is complete.', and, if the product supports it, offer a separate action to start onboarding. It should never accept free text as a payee, because the value must map to one real employee record.
saying these in an interview costs you the question
- Auto-selecting the first match is always the most efficient choice for users.
- If a name looks complete in the field, it must be the person the user meant.
- Showing only the employee's name in options is enough to identify them.
- Pressing Escape in the popup should commit the highlighted suggestion.
- Clearing unmatched text on blur is a safe way to handle no match.