Add TAB key as a trigger for command autocomplete

[Clorith]

Currently when typing commands (shortcuts preceded by /) you can autocomplete these by hitting return.

It's common practice that autocomplete triggers with the TAB key, but right now that moves you on to the sidebar instead, losing editor focus entirely.

Could we consider the possibilities, and potential drawbacks, of allowing TAB keys to finalize commands. I'm wondering if it may have been skipped for a11y concerns for example?

[codebykat]

+1 for this, for compatibility with other UIs. I keep hitting tab and getting lost.

[aduth]

Related: #7051 (counter-claim of tab behavior be left to native handling)

[afercia]

The combobox pattern is well detailed in the ARIA Authoring Practices, see https://www.w3.org/TR/2019/NOTE-wai-aria-practices-1.1-20190207/#combobox

It's important to note that following specifications is not just about abstract conformance. Browsers and assistive technologies are designed based on the specifications. When they encounter patterns they're not able to recognize, it's very likely they will fail to enable users to use an interface.

That said, ARIA defines 4 different types of combo boxes (see the link above):
1 No autocomplete
2 List autocomplete with manual selection
3 List autocomplete with automatic selection
4 List with inline autocomplete

Gutenberg and WordPress use 2.

Only for 3 and 4 (quoting): "... the first suggestion is automatically highlighted as selected. 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."

That would also mean the autocompleters implementation should be changed to automatically populate the input field with the highlighted suggestion.

However, the Gutenberg "slash command" uses aliases so the first suggestion is not necessarily the right one. See in the screenshot below: what value should automatically populate the input field?

Typing "imag" displays the following suggestions in alphabetical order:

• Gallery
• Image
• Instagram
• Flickr
• Media & Text

In this case, the expected behavior would be:

• "Gallery" is the first suggestion and is automatically highlighted as selected
• "Gallery" becomes the value of the textbox when the combobox loses focus
• this would be completely unexpected because the typed value "imag" would be replaced by "Gallery"

And this is just one example: other values produce other edge cases.

Basically, in most of the cases users will have to:

• use the mouse to select the right suggestion: at that point they can just click
• use the arrow keys: only at that point, pressing Tab could trigger the command but that would go against the ARIA recommendation

More importantly: the autocompleters are used also in other components. For example in the tag suggestions:

In this case, Tab was initially used to add / create tags. Then it was intentionally removed because:

• selecting a suggestion and tabbing away was always adding the tag to the post: this may or may not be the expected behavior. For example, users might want to explore the suggestions and then just tab away to navigate elsewhere
• typing a new tag and submitting creates a new tag: in this case, typing or mistyping something in the input field and then tabbing away was always creating a new tag. Highly undesirable: after a few days/weeks/months of usage you will end up with dozens of mistyped tags saved in your taxonomy

I'd tend to think the various autocompleters in Gutenberg should work consistently: implementing different behaviors for the slash command and for the tags suggestions (or other autocompleters usages) wouldn't help in making the interaction simple end predictable.

Considering also the many, risky, details behind any change to the current implementation, I'd recommend to stick with the original accessibility feedback and just use the Tab key for its native behavior.

As accessibility team, we've discussed this issue during today's bug-scrub and agreed to close for now. Discussion can continue also on closed issues.