Components: Autocomplete: when using the keyboard to navigate the options, the currently focused item should be the 'selected' option

[StevenRasmussen]

Bug, feature request, or proposal:

Feature request

What is the expected behavior?

When using the keyboard to navigate through the options, as the focus changes from one option to another, the selected option should be the currently focused option, thus following the "selection follow focus" principle as stated in the Material docs here.

If the desire is to leave the current behavior then at least provide an option to turn this behavior on.

What is the current behavior?

Using the keyboard to navigate the options does not automatically update the 'selected' option.

What is the use-case or motivation for changing an existing behavior?

Many users expect to be able to select an option by simply navigating the options without being required to press a particular key to indicate their selection. By simply leaving the current control after having navigating to a particular option, they assume that they have selected the option as well. The main example I have for this is using the TAB key. I often navigate options using the arrow key and then press the TAB key after having 'selected' my option using the arrow keys. The current behavior is such that you are required to 'select' the option using the ENTER key, otherwise the value is not set when you TAB away from the control.

Google's own search engine follows this principle. As you type in your search, Google begins searching for the phrase and provides several autocomplete phrases for you. If you navigate the provided phrases, the search results update based on the currently focused phrase without having pressed ENTER or another key.

Is there anything else we should know?

See this pull request for the initial discussion.

[StevenRasmussen]

@jelbourn , @kara , I'd be willing to start working on a PR if it's decided that we can move forward on this. Just wanted to get the blessing of the powers that be before I invest the time. Thanks!

[jelbourn]

I believe we discussed this before and decided against it for a11y reasons; I can try to find that discussion.

[willshowell]

It looks like the only stated accessibility downsides of "selection follow focus" are for tab lists that may have latency in showing their panels. I don't think that's a real concern for autocomplete.

Is there some aria label that would allow a screen reader to explain that selection follow focus is enabled? If not, would it be confusing to be navigating the options and having each one announce a new selection?

[jelbourn]

Looking at this more, I think it's a reasonable option to add to the autocomplete. It's not exactly a selection-follows-focus case, since the autocomplete uses activedescendant rather than focus, but I think it should still work.

[thw0rted]

FWIW this is how the Google home page handles suggestions -- navigating the list with up/down arrows immediately populates the search bar with the selected suggestion.

[patryk-wlaz]

Ho do I even start navigating by using arrow down on keyboard? I cant find it in docs, example in material docs does NOT have this feature - meaning I have to use mouse to choose from autocomplete list. Weird

[thw0rted]

The docs examples sometimes have caching issues, where they're using incompatible versions of dependencies because they're not pinned. (See #7660)

If you reload the example, you should be able to navigate with the keyboard arrows. If it still doesn't work, maybe it's your environment? (Browser, extensions, etc)

[patryk-wlaz]

So if you follow the link that I posted above you can choose states in the autocomplete example using keyboard arrows? Weird.
I can not. I reloaded page and cleared cache. Got pretty standard env, win10 and chrome. Arrows just doesnt seem to work in the example nor in my code developed locally (although locally I am using deprecated material for now, planning to refactor - but still I dont know whats going on with the example).

[swhook52]

Any update on if we can expect to see this for mat-select options? I can't say I fully understand the accessibility issues but could we find a workaround for those? My keyboard users keep tabbing away thinking they've selected an option.

[macjohnny]

Here is a comparison between mat-select and a native select:
https://stackblitz.com/edit/angular-material2-issue-assosq?file=app/app.component.html

With the native select, you can open it, press Arrow-Down, then Tab and you will have the second option selected.
With the mat-select, it won't select the active option when just pressing Tab instead of Enter.

@jelbourn Maybe the native browser behavior should also be adapted in mat-select?

[thw0rted]

@macjohnny I agree with your assessment -- using the arrow keys to highlight, then Tabbing out, should select the last active item. But your example won't work anyway, because you didn't give your mat-option tags a value property, so you might want to update it.

[macjohnny]

@thw0rted thanks for pointing that out, I updated the example accordingly

[AdditionAddict]

This SO answer provides the desired behaviour
https://stackoverflow.com/questions/55156541/how-to-make-tab-key-as-enter-key-in-angular-material/55159386#55159386

[bmoe24x]

I am particular interested in using a little bit of a different functionality. I would like mat autocomplete to be navigated by the TAB while ENTER submits the request. This is reminiscent of the Chrome URL bar where if I type a term I can navigate down with TAB and select with ENTER. Is this possible with MatAutocomplete?

[haraldkofler]

This SO answer provides the desired behaviour
https://stackoverflow.com/questions/55156541/how-to-make-tab-key-as-enter-key-in-angular-material/55159386#55159386

This solution does not work, if there is already another (blur) function mapped to the input field. Seems like both blur functions get the same value at the time of blurring. In my case I have a (blur) function to manually verify and select a value if needed. Now, as the solution on SO also uses the onBlur event, these two functions are in conflict...
Does anyone have a suggestion on this topic?

[thw0rted]

Why not switch to a reactive FormControl for the input? Then you can write a custom Validator for it instead of hooking the blur function in the input element.