Combobox: unintuitive behaviour on re-selection

[d-m-s]

Re-raising this issue, as it grew silent around the issue, if there is a related ticket please close it and mention the corresponding ticket!
Assignee: @bbogdanov
FYI: @mattmutt; @gnomeontherun

For the original ticket please see #6469

---

How to reproduce

See screencast for the steps to reproduce the behavior:
https://user-images.githubusercontent.com/311619/141486153-2c73a13e-02a7-44a9-9493-cd4f854f75ed.mp4

Describe the bug

Imagine the following quite common scenario:

1. User types in/selects a value from the suggestion-list of the autocomplete-combobox.
2. This value is valid and eg. saved until a change of the value is required.
3. User now clicks on the caret-down to open the suggestion-list, as he/she wants to select another value.

In the screencast example the user had previously selected "Alaska" and wants to change it to "Arizona", which is not easy possible.

Current behaviour

• when the user clicks on the caret-down to open the suggestion-list, as he/she wants to select another value, the suggestion-list only offers the current value.

• Some of our users where confused if there aren't no other valid options to select from, and

• other understood that they need to delete the current value and search for a new one but felt that this behavior is cumbersome and unintuitive.

Expected behavior

Therefore the behaviour should change as soon as a value has been selected = the combobox field is populated:

• then a click to open the suggestion-list should show all options, making the selection of another valid option via mouse easy.
• when the text of the input field is altered, the suggestion list reflects the search behaviour and adapts the search results in the suggestion-list as currently implemented.
• additionally a "x" at the end of the input field could help to easily clear the contents of the combobox. See common behaviour on search fields:

see also #5641

Versions

Clarity project: Clarity Angular/UI
Clarity version: v4.x; v5.x
Framework: Angular
Device:

• Type: any, tested with Notebook
• OS: any, tested with Windows
• Browser: likely any, tested with Chrome

[mathisscott]

This is something we can look at. I don't know the level of difficulty for changing that behavior on the combobox but the feedback on it being non-intuitive is valid.

CC: @Jinnie @bbogdanov

[mattmutt]

One approach is to consider adopting a dropdown like behavior on the Clarity combobox. That's what we ended up doing in our use case, because users were baffled by the showing of one item in the list each time they wanted to change the value. Trying to reprogram users expectations that this is how a combobox design work was ineffective.

So all Clarity comboboxes in the app now get the best of both worlds. Filtered typing to quickly find the item and a dropdown button to reveal the complete list, even if something was highlighted already. Had to invent a new custom iterator on the <clr-option> element for this change.

combobox-with-reselection.mov

[Jinnie]

This is the accessibility pattern that we've followed. Any change request should go through the accessibility channel. It's not a devs or design driven decision.

CC: @scroniser

[chlane]

@Jinnie I think what we are looking for is in the following statement from wai-aria-practices-1.1/#combobox

"The automatically selected suggestion becomes the value of the textbox when the combobox loses focus unless the user chooses a different suggestion or changes the character string in the textbox."

The part that says "chooses a different selection" appears to support the the desired UX described in this bug. The ARIA Working Group examples have a different UX, relying on changing/clearing the character strings in the textbox as the only way to start the process of choosing a new value. This seems to be the easiest way to do this accessibly and the UX fits the context of the examples IMO.

This Apex 4X Combobox uses a "clear all" button to enable the user to begin selecting another choice. IMO the "clear all" button lets all users know that value clearing needs to happen before making a new selection and provides an accessible affordance to do so.

[Jinnie]

@chlane Thanks for bringing in more detail, Chris. The Apex example is using a totally new approach of leaving the popover open after doing a selection and keeping the selection there. It's interesting and worth discussing with design, though it is not aligned with our current component structure. We may need to overall reevaluate some of the options we have for the Combobox, but this can not be done in the current state of the Clarity Angular project and release cycle.
Let's focus back on the current issue. If you think that this is the desired functionality, please add a VPAT JIRA to the clarity_combobox component section, so we can prioritize it against the other VPAT issues and try to add it to our current VPAT cycles. To gain higher priority and the chance to be handled as part of these cycles, we'll also need it to be linked as blocker to product teams VPAT issues.
And we'll still have to align with the design team.

Best regards,
Ivan

[scroniser]

@Jinnie - I believe @chlane is providing options to help service the original ask. The current implementation, while accessibility-informed, is not the only way to implement the combobox. If Clarity would like to explore alternate options which service the OP's ask, the a11y team recommends reviewing the examples provided.

As this doesn't speak to a current problem, I'm hesitant to put it into the VPAT Jira. I would classify this as a feature request rather than an accessibility issue.

[colinreedmiller]

Our current (exclusive) emphasis is addressing a11y bugs. This will be postpones until resources are available because it is a feature request / enhancement.

[d-m-s]

@Jinnie - I believe @chlane is providing options to help service the original ask. The current implementation, while accessibility-informed, is not the only way to implement the combobox. If Clarity would like to explore alternate options which service the OP's ask, the a11y team recommends reviewing the examples provided.

As this doesn't speak to a current problem, I'm hesitant to put it into the VPAT Jira. I would classify this as a feature request rather than an accessibility issue.

This is not an a11y bug - it can be classified as feature request, but to put it plain
- actually this is a ux-bug!

We do have multiple customer feedbacks on this one!

And it's clear why - since of course the combobox is used when there are plenty of select-options,
and with plenty of options the need and chance to reselect a value is very high,
and exactly this user-task is very complicated an unintuitive!