Combo box search results do not match user expectations

[jaclinec]

Summary

Users expect first letter navigation when they type into a combo box for selecting states or countries. In other words, if they type "T," they expect to see results of states starting with the letter T, like Tennessee, Texas, etc. The current way the combo box functions is to show all results containing the letter "t", so for example Connecticut may show up in results, confusing users.

Observations

4 out of 5 participants in usability testing were confused by the search results. They were tasked with selecting "Texas" from U.S. states combo box in a form prototype. Those 4 users typed "T" and were confused that they did not get results for only states starting with "T," and often would just scroll down the whole list to get to Texas. One users commented that that would be especially annoying if you were navigating a long list of 200+ countries.

Video clips 🔒

Affected user groups

• All users
• Screen reader users
• Screen magnification users

Research method

Usability testing with 5 visually impaired participants. See findings report for details.

Recommendations for next steps

Currently there are no clear solution recommendations. The team discussed whether the unexpected behaviors could be avoided by updating the combo box results to be sorted by relevance rather than alphabetically. Another possibility is adding screen reader instructions to enter a search term. Is it possible or recommended to implement first-letter navigation?

Next steps

Decide on a solution to mitigate the friction users experience with unexpected search results and test it again in a new round of usability testing.

[mejiaj]

Assigning to @mahoneycm to add additional information.

[jaclinec]

Adding the light landscape analysis (#338) for combo box to provide additional helpful info when thinking through a solution. Hoping to talk through some of this at a dev sync.

[mahoneycm]

W3C ARIA Keyboard Behaviors

Combobox with editable input

Our current combo box most closely matches the Editable Combobox With List Autocomplete Example found on the W3C patterns website.

Keyboard behaviors

This example illustrates the autocomplete behavior known as list autocomplete with manual selection. If the user types one or more characters in the edit box and the typed characters match the beginning of the name of one or more states or territories, a listbox popup appears containing the matching names. When the listbox appears, a suggested name is not automatically selected. Thus, after typing, if the user tabs or clicks out of the combobox without choosing a value from the listbox, the typed string becomes the value of the combobox. Note that this implementation enables users to input the name of a state or territory, but it does not prevent input of any other arbitrary value.

Notable differences

• Dropdown list only displays items starting with input.
  • When typing T, results are limited to Tennessee and Texas. Connecticut is excluded.
• Typing while dropdown list is focused
  • Recommendation from ARIA Authoring Group:
    • Moves visual focus to the textbox.
    • Types the character in the textbox.
    • Options in the listbox are filtered based on characters in the textbox.
  • Our behaviors
    • Currently, typing with the dropdown focused does not do anything
    • Dropdown selection and input are both unaffected
    • Further, hitting shift + tab to return to the input causes the input test to be selected. Typing will then replace any previously typed query.

Select-only combobox

I wanted to include the Select-Only Combobox Example because these behaviors are closer to the behaviors mentioned in this issue.

Keyboard interaction

• First opens the listbox if it is not already displayed and then moves visual focus to the first option that matches the typed character.
• If multiple keys are typed in quick succession, visual focus moves to the first option that matches the full string.
• If the same character is typed in succession, visual focus cycles among the options starting with that character.

These patterns match much closer to what the testers were expecting. The primary difference is without the editable input, we can focus on keyboard controls to iterate and search through the dropdown options.

[jaclinec]

After discussing at a CS/UX sync, we decided we'd like to move forward with implementing a solution similar to Elastic UI's combobox where first letter navigation is prioritized, but that it also returns results with characters contained in the search terms. See meeting notes and Mural board.

We're aiming to get this solution in a testable condition in time for Buffalo batch re-testing at the end of May.

[RBlanc1]

I would agree that ( when searching within combobox ) the ordering by 1. beginning of string first and 2. everything else - makes sense. Noone really searches the middle of a string. We use comboboxes and have pretty extensive lists that populate these and returning the matches in the middle of a string 'first' is just confusing. Would love to see this implemented.

[mejiaj]

Removing the discussion label because the April 4 comment shows that this was already discussed.

After discussing at a CS/UX sync, we decided we'd like to move forward with implementing a solution similar to Elastic UI's combobox where first letter navigation is prioritized, but that it also returns results with characters contained in the search terms. See meeting notes and Mural board.

We're aiming to get this solution in a testable condition in time for Buffalo batch re-testing at the end of May.

---

@brunerae @jaclinec should we still prioritize this before the next round of testing?

[jaclinec]

@mejiaj yes, I think we should still prioritize this work so we have a solution ready to test hopefully within the next few sprints.