Feature Request - TAB acts as Selecting

[skcbenjamin]

A while back FlightSearch requested a feature update for the aurocombobox where tabbing would 1) select a city based on a selection criteria and 2) move on to the next field. Here is the previous issue discussion: AlaskaAirlines/auro-combobox#77

In legacy we have seen that hitting TAB either selects the first item in the list if it does not match an exact item. Like typing "SE" then TAB will select "Seattle (All Airports)" the first item in the list. However, typing "SEA" then TAB will select "SEA - Seattle, WA - Seattle/Tacoma" which is an exact match to when they hit TAB

Auro has said their not implementing this change, however FlightSearch stakeholders still would like this implemented. If this is still the case. we would like to explore innersourcing

[blackfalcon]

The auro-combobox, to manage as many use cases as possible we model the behavior, interaction, and accessibility standards off of standard HTML. E.g. in this case the select element https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_select

From this you can see that tabbing into the combobox allows a user to then use the arrow keys to move up and down the list, then using the enter key to select the option. The tab key then moves the user to the next control.

I also found this UX Exchange Stack Overflow conversation that brings up an interesting point
https://ux.stackexchange.com/questions/68630/whats-the-right-behavior-for-the-tab-key-on-a-combobox

The argument to be had there is that accessibility is the top concern. But, there is also an argument to be had that with the tab key, there is nothing wrong with the highlighted option being added to the field's value. I can agree with that. As long as that tab action also takes the user to the next interaction.

I feel like a lot of the previous confusion over this feature was about business logic that will determine what selection is highlighted based on text input and the automatic attribution of the selected option to the input's value. The current functionality simply reduces the long list of options to make selection easier for the user.

To do this would require auro-combobox to know its surroundings or have a deep understanding of the data presented, which we feel is inappropriate from our perspective.

I see two paths forward.

With the current combobox, as a user moves through the options a screenreader will announce that an option is selected. Once the enter key is pressed the selection is again announced. With the tab action updating the value AND moving the user to the next interaction, that last announcement will be lost. That is something to be considered. One could argue that a power user would see the value being added and move on. The non-power or assisted user may instinctively press the enter key, get the announcement, and then tab to the next interaction. All viable user cases.

As for awareness of pre-selected content from the options, I would want to offer a solution where you can extend and customize the functionality of the auro-combobox in your own app. As stated, you are best to own this particular business logic and it's not something we should dictate how to be used as the use case is pretty limited.

But again, even with customization, ensuring an accessible experience is a must.

[janabimustafa]

@blackfalcon, it appears that the issue you mentioned is specific to MacOS. On both Windows and Linux systems, pressing the tab key does select the highlighted item in a select element. I've tested this myself at W3Schools' HTML Select Tag example. If it helps, I can record a video demonstrating this behavior. It's important to note that the majority of users on our microsite are Windows users.

Considering this, I believe it's essential for us to ensure that our site's functionality aligns with the standard behaviors expected by users on their respective operating systems.

[jesussilverioea]

@blackfalcon in addition to Mustafa's comment, based on the W3 accessibility standard for the combobox, tab is also used to select an option from the combobox menu.

https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-autocomplete-list/

[blackfalcon]

Hey @janabimustafa that is interesting. I also noticed that Firefox has a similar interaction, Chrome and Safari do not. But you are saying that Chrome does this on Windows?

Here is this too that I just discovered. https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-select-only/

This was updated in December 2023 and contains some interesting changes of opinions in the past few years.

Navigating the list of options does not set the value of the input. This gives screen reader users, who need to navigate among the options to perceive them, the ability to explore options without losing the current value of the input. The value is set when users press Space, Enter, or Tab, or when focus moves out of the combobox. The current value is retained if the listbox is closed with Escape or if the user collapses the list by clicking the input.

Currently, the auro-combobox demo page is broken, but the above statement does clearly challenge some previously held opinions around the use of a select or combobox element. The Space, Enter, or Escape options are supported, while the Tab currently is not and I am interested more in the use case of simply removing focus selects an option as well.

Given this new data, a case can be made to outright support this feature as well as dig into this example and see what other improvements we can make with this element.

With the tab action updating the value AND moving the user to the next interaction, that last announcement will be lost.

Even with this new information, this statement is still true. This is also demonstratable in the W3C example as well. But if it's good with the W3C, it's good for me.

@Patrick-Daly-AA I'd like to get a dev meeting scheduled so that we can create the stories needed to make these updates in an upcoming sprint.

[blackfalcon]

@jesussilverioea yup... we are all on the same page here. I haven't looked at these new W3C resources, but this is good stuff. Thanks for the additional input.

[blackfalcon]

@jason-capsule42 and @jordanjones243 what are your ideas for supporting this update? Let's get in this discussion ideas for how to update the element.

[jason-capsule42]

Let me take a look at the underlying code. I know we have seperate concepts for what is "selected" in a menu vs what is "active". I think we can likely just mark what is "active" as "selected" when hitting the tab key. I'll followup on this investigation today.

[blackfalcon]

UPDATE: this update will be addressed along with other similar deliverables in Q2 of 2024.