Make search suggestions usable before adding them

Decide what the suggestion is supposed to solve

Autocomplete is useful when a customer is trying to name something the business recognizes, such as a destination, service location, or product category. It can reduce spelling uncertainty and reveal accepted terms. It can also add a moving popup, extra requests, and ambiguous selection rules to a simple search field. Start by observing the task: must the customer choose a controlled value, or may they search with their own words? If free text is allowed, do not silently replace it with the first suggestion. If only a controlled value is valid, say so in the visible instruction and provide a reliable way to browse the choices.

The W3C APG distinguishes editable comboboxes that accept arbitrary text from those restricted to allowed values. It also describes different autocomplete behaviors, including manual selection and automatic selection. These choices change what happens when the user leaves the field. A business owner should approve the behavior in words before implementation: for example, typing a place name and pressing Search uses the typed string unless the customer explicitly chooses a suggestion. That one sentence gives designers, developers, and testers a shared expected result.

Compare the proposed widget with a plain labeled search box. If the catalogue is small and a customer can search successfully without predictions, the simpler control may be easier to maintain and test. If suggestions add value, define the source of terms, how quickly they update, whether they are products or categories, and whether unavailable items appear. Avoid presenting a suggestion as a guaranteed stock or price promise; selecting a term should lead to a current result page where the customer can check the actual offer.

Give the input a clear name and stable meaning

A visible label should tell customers what they are searching: destinations, products, or help topics. Placeholder text disappears when typing and is a weak substitute for that label. The W3C example uses an HTML label associated with its input, and its WCAG guidance explains why controls need labels or instructions that people can perceive. Keep the accessible name aligned with the visible label so speech input and screen reader users encounter the same task. If the field accepts only a city from a list, state that constraint before submission rather than after an unexplained error.

When suggestions appear, the field and popup need a relationship that assistive technology can understand. The APG list autocomplete example uses a combobox input, a listbox popup, aria-expanded to reflect whether it is visible, aria-controls to identify the popup, and aria-activedescendant for the active option while DOM focus stays on the input. Those attributes are a pattern to implement and test, not decoration to paste onto any menu. If the team cannot maintain the state accurately while options update, a native control or simpler search may be safer than a broken custom widget.

Write acceptance criteria for the value, not just the popup. After a customer types, what string is submitted? After arrowing to an option but pressing Escape, is the typed string preserved? After choosing a suggestion, is the selected value visible and editable? If the customer clears the field, do stale suggestions disappear? These questions catch failures that a visual screenshot misses. They also prevent a backend from receiving an internal option ID that does not match the text the customer believed they selected.

Make selection predictable without a pointer

The APG combobox pattern places the input in the normal Tab sequence. It describes Down Arrow for moving into available suggestions, Escape for dismissing a popup, and Enter for accepting a selected suggestion in an editable combobox. The exact optional keys depend on the chosen behavior, so document the implementation rather than claiming every combobox must behave identically. At a minimum, a customer should be able to type, discover suggestions, navigate them, choose one, dismiss them, and submit a free-text search when that is allowed, all without a mouse.

Do not trap Tab inside every suggestion. The example keeps DOM focus on the text field while using an active descendant to communicate the highlighted option. This allows ordinary text editing keys to work and lets Tab continue to the next page control. Test what happens when focus leaves while the popup is open: a manual selection design should not silently commit a highlighted option that the customer did not choose. A visible highlight, selected value, and spoken announcement must tell the same story.

A useful manual test starts with a blank field. Press Tab until the field is focused, type a partial term, use Down Arrow through the available results, press Escape, and submit. Repeat, this time choosing an option with Enter. Then repeat with only touch input and with a screen reader. Record the text shown in the field, the spoken option, and the request ultimately sent. Do the same when no suggestions match, because the empty state should not leave a ghost option active or block a normal search.

Keep changing results understandable

Suggestions can update after each keystroke and a network response may arrive after the customer has already typed more characters. If an older response replaces newer suggestions, the highlighted option can suddenly refer to a different term. Tie results to the current input and discard stale responses. Do not let delayed data silently change a selected value. A loading indicator may help, but it should not take focus away from the input. Keep the number of suggestions manageable so a keyboard user can reach the rest of the page without laborious navigation.

The result list must have a meaningful empty and failure behavior. When there are no matches, explain that fact without treating the customer’s spelling as an error if free search remains valid. When the suggestion service is unavailable, keep the search field and submit action usable. If a controlled value is mandatory, provide an alternative list or a clear correction path. This separates an optional convenience feature from the customer’s ability to complete the underlying task. It also reduces pressure to show stale suggestions merely to avoid an empty popup.

For an illustrative travel enquiry, suppose a customer types a neighborhood name that is not in the destination list. If the site supports broad search, pressing Search should use that exact input and show results or a useful no-results path. If the form is actually for selecting a departure airport, the interface should state that only listed airports are valid and provide a browsable choice. These are different business rules. A polished popup cannot repair an unclear rule about what the customer is allowed to submit.

Treat the example as a starting point, then test people

The W3C example is explicitly illustrative and warns that browser and assistive technology combinations can differ, especially on mobile and touch devices. Copying its markup is therefore not a production acceptance result. Test the exact widget in the browsers and input methods your customers use. Include a keyboard-only session, a screen reader session, touch interaction, magnification, and both English and Traditional Chinese labels and suggestions. Check that long place names are visible without cutting off the distinguishing words.

Set a short release checklist that the business can observe: the field has a visible and accessible name; suggestions correspond to the present query; expansion and active option states are accurate; the keyboard can open, move, choose and dismiss; free text survives when permitted; and an unavailable suggestion service leaves a usable route. Pair each item with one concrete test, not a vague statement that the component is accessible. Keep screenshots and a short recording of the interaction if they help reproduce a failure, while avoiding customer data in fixtures.

The decision is complete when the owner can answer two questions. Does this suggestion list materially help a customer identify a valid term or route, and can that customer finish the search without guessing how the popup behaves? If either answer remains uncertain, compare it again with a plain search field and run the test journey. Record which interaction model was chosen so future changes to ranking, data source, or visual design do not quietly change what Enter, Escape, or leaving the field means.

Bilingual search needs a data decision as well as a translated label. A Hong Kong customer may type a place in Traditional Chinese, English, or a familiar shortened name; suggestions can refer to one destination while displaying several accepted names. Test whether each alias leads to the same intended result, whether two similar names remain distinguishable, and whether a screen reader announces enough context to choose correctly. Do not make customers memorize an English spelling that the visible Chinese interface never taught them. Maintain aliases when products or service areas change, and check the actual submitted identifier alongside the displayed name.

The suggestion service also needs a maintenance owner. When a place closes, a service area changes, or two terms become aliases, update the source list and check that old links still reach a useful result. Review analytics only when actual data exists: repeated searches for a term can be a clue to test, but they do not prove that autocomplete solves the problem. Ask a customer or staff tester to explain what they expected after typing, highlighting, and submitting. That observation is more useful than counting how many suggestions were displayed.