Define behavior of tab key in <selectmenu> listbox

[dandclark]

When the <select> element is open, hitting Tab closes it and puts focus back on its button.

But @scottaohara pointed out in #540 that in the Chromium prototype of <selectmenu>, when the <selectmenu> element is open hitting Tab does not close it, and instead moves focus to the next focusable item in the listbox (usually an <option>).

@smhigley said here:

In the user studies I've done on comboboxes (3 so far, and another in the works) I've found a strong user expectation that a tab from within an open combobox will select the current option and leave the popup. I don't think it would be a good idea to break that expectation in the most common/baseline use case for a selectmenu.

So we should consider updating the <selectmenu> Tab key behavior so that it matches <select>.

When deciding this we should think about what happens with non-option focusable content in the listbox. Per #540 the platform will warn against the inclusion of this content, so it may be fine for it not to be default-keyboard-accessible; if the developer insists on inserting that content then they would be responsible for making it keyboard-accessible.

[flackr]

I personally like the idea of considering that while a selectmenu is active focus is within it and tab moves you between focusable items in the selectmenu - which might help us with #540.

If we consider the enter set of options in a <selectmenu> to be a single tab item we could automatically focus the first focusable item when you open the selectmenu (usually the group of options) and this would mean that pressing tab will move focus to the next tabbable item (usually outside the selectmenu, closing it implicitly with the current option selected). However, in the presence of other interactive content inside the selectmenu you could tab between that content.

[jnurthen]

@flackr that doesn't sound like a <selectmenu>. Perhaps we need a more complex component which could be called <selectdialog> which could do the kind of thing you are requesting. It could be used for calendar widgets, colour pickers etc. which don't neatly fit into a <selectmenu>

[smhigley]

I agree, I don't think we've really appreciated the full complexity of will need to be nailed down in order to allow freeform mixed interactive content in a <selectmenu>.

Just in the context of tabbing, @flackr your suggestion is interesting, but runs into problems with trying to figure out how selection should work in a single-tab-stop vs. multi-tab-stop scenario. Generally, someone would expect tabbing away to select -- so what happens to their selection if they try to tab away, and find there's a random button in the select menu, and then tab again to get out of it? In that case, they'd clearly expect the selection to be preserved, but I can also clearly imagine other scenarios with more non-option content where that would not be the case.

Then there's the case of something like this:

<selectmenu>
   <option>apple</option>
   <option>banana</option>
   <input type="text">
   <option>kiwi</option>
</selectmenu>

It would need to be turned into a set of children with two separate listboxes inserted by the browser, and I'm really not sure how selection, not to mention surfacing of the # items and arrowing, would work in that scenario:

<div role="dialog">
   <div role="listbox">
       <option>apple</option> // let's say the user tabs away from "apple" in an attempt to select it. Probably not selected?
       <option>banana</option>
   </div>
   <input type="text">
   <div role="listbox">
       <option>kiwi</option> // they then eventually tab away from "kiwi", because it's the last item in the popup. Is it selected?
   </div>
</div>

[css-meeting-bot]

The Open UI Community Group just discussed Define behavior of tab key in <selectmenu> listbox, and agreed to the following:

• RESOLVED: Tab key in selectmenu listbox closes the listbox and sets focus back on the button, regardless of tabbing direction. This happens even if there is interactive content in the listbox.

The full IRC log of that discussion

<gregwhitworth> Topic: Define behavior of tab key in <selectmenu> listbox
<gregwhitworth> github: https://github.com/openui/open-ui/issues/599
<gregwhitworth> dandclark: is something Sarah or Scott raised regarding tab key behavior
<gregwhitworth> dandclark: we don't do any special handling of tab, when you hit tab it moves to the next focusable options, or something else
<gregwhitworth> dandclark: the platform default solution now selects the currently focused option and closes the popup
<masonf> q+
<gregwhitworth> dandclark: this is what is expected by keyboard users
<gregwhitworth> dandclark: the suggestion was to close the listbox and put focus on the button
<gregwhitworth> dandclark: the one caveat is what do you do when the focus is not on something that is not an option
<gregwhitworth> dandclark: there may be future usecases where you could have interactive content within them so we don't want to necessarily prohibit them
<gregwhitworth> dandclark: we don't want to box ourselves in
<gregwhitworth> dandclark: I would recommend to do the simplest thing
<gregwhitworth> dandclark: regardless, when a user hits tab on the select menu it closes the popup and puts focus on the button
<gregwhitworth> dandclark: I think just following the select native tabbing behavior is the most straightforward path here
<gregwhitworth> ack masonf
<gregwhitworth> masonf: I'm not the expert but a few thoughts come to mind and I'm trying to not open the topic of interactive content within the listbox
<gregwhitworth> masonf: the omnibox in chrome currently behaves as the current select
<gregwhitworth> masonf: if we do plan in the future to move towards secondary content will we be boxing ourselves in?
<scotto> q+
<gregwhitworth> masonf: I'm leaning towards keeping it as is
<gregwhitworth> sara: the semantic structure is going to have to change anyways, so I think it's ok to have the keyboard behavior will change
<gregwhitworth> sara: I'm curious what the omni select is in Chrome, that's more common in menus than select in forms
<gregwhitworth> sara: select controls it's important, when using user studies tab was a common way for people to use. They use enter and space, but those are more common for multi-select and tab was the most common way to select
<gregwhitworth> sara: for the mainstream single select is not a good thing to do
<gregwhitworth> masonf: my omnibox is more of a combox
<gregwhitworth> sara: it's going to select the option and go back to the button
<gregwhitworth> ack scotto
<gregwhitworth> scotto: to add onto sara's items
<gregwhitworth> scotto: one of the issues that I see here is that we're adding in extra functionality more commonly associated with tree views or menus
<gregwhitworth> scotto: the common thing that we've heard, is that if we don't provide this functionality then devs will build them
<gregwhitworth> scotto: we need to make sure what we're doing and why
<gregwhitworth> scotto: if we're doing this to produce more styleable controls
<gregwhitworth> scotto:
<gregwhitworth> scotto: if we want to produce a menu then we should do that
<masonf> q+
<gregwhitworth> q+
<gregwhitworth> scotto: sara's proposal is nested interactives is the best possible way forward and things work as expected for people. I get we don't want to kick things out of the parser
<gregwhitworth> scotto: we don't want to change how listboxes work
<gregwhitworth> ack masonf
<gregwhitworth> masonf: I appreciate the viewpoints, I think you've convinced me
<gregwhitworth> masonf: I have one question, if this is the behavior and people are adding things; we'll need to tell people what to do instead
<gregwhitworth> masonf: what is the right thing to do?
<sarah_h> q+
<gregwhitworth> masonf: if people want to put other things inside of the options do they add an aria role
<gregwhitworth> sarah_h: there is a lot of precident to not change behavior based on aria
<gregwhitworth> sarah_h: that takes things away from the author to opt into menu behavior
<gregwhitworth> sarah_h: I think it'd have to be a non-aria attribute
<gregwhitworth> sarah_h: other people may have other options
<gregwhitworth> masonf: so the console warning will be "you're doing in-accessible but we're working"
<masonf> gregwhitworth: responding to scott - you're correct. There should be more elements, and that's been the plan.
<masonf> gregwhitworth: people will use <selectmenu> to get 90% of functionality. Then they'll add buttons. This is just the starting point, but not the ending point.
<masonf> gregwhitworth: We'll build a combobox element eventually, with better behaviors.
<masonf> gregwhitworth: We can only do one thing at a time, for the most part. Everywhere we see these corner cases being built, we introduce another element.
<masonf> gregwhitworth: I'm curious about the user studies: did you test major web properties, or just the default platform behaviors?
<scotto> q+
<gregwhitworth> ack gregwhitworth
<masonf> sarah_h: Yeah, I have an article about it. I tested a variety of implementations, including native and custom component implementations.
<masonf> sarah_h: I wasn't using Fluent, but similar to what similar libraries do. ARIA combobox, single and multi-select, etc.
<masonf> gregwhitworth: please drop in the link, I'm curious to see it.
<masonf> gregwhitworth: I'd love to learn more, but I'm a firm believer in not boxing us in. But I can adjust my position accordingly.
<sarah_h> ack me
<gregwhitworth> ack scotto
<gregwhitworth> scotto: I guess the only thing in your comment, and you agree with that this is the starting point
<gregwhitworth> scotto: you agree there are other elements that are needed, why not just add the functionality and do that there
<sarah_h> the study writeup is a 2-parter (I've done 2.5 studies since then, but they're more or less refinements of similar results found in the first):
<masonf> q+
<sarah_h> https://www.24a11y.com/2019/select-your-poison/, and https://www.24a11y.com/2019/select-your-poison-part-2/
<gregwhitworth> scotto: again, the demos that patrick had created. He had a split button, a listbox, a combo box
<gregwhitworth> scotto: those are all wildly different things
<gregwhitworth> q+
<gregwhitworth> scotto: why not pumping them all in
<gregwhitworth> masonf: I guess one of the reasons is, when you're building the demo pages you build things that are interesting to do this thing
<gregwhitworth> masonf: then people use this for a real product
<gregwhitworth> masonf: I'm interested to understand what they go do
<gregwhitworth> masonf: I'm concerned that we show a demo and then we move towards what is actually built
<gregwhitworth> scotto: I don't mean to say there is anything bad at all, it showed the versatility of those we should just do them
<gregwhitworth> masonf: do we know we need to do all of those?
<gregwhitworth> masonf: I guess that' sthe problem we have
<gregwhitworth> ack masonf
<gregwhitworth> ack gregwhitworth
<sarah_h> q+
<masonf> gregwhitworth: Is the combobox different from select? The only true difference model-wise is that your typing is more intuitive, you need filtering, but the ultimate model is the same.
<masonf> gregwhitworth: You're still selecting one option from a list.
<masonf> gregwhitworth: For behaviors, the reason I think we should go build all of them, and given the flexibility people are going to go build a combobox which isn't accessible.
<masonf> gregwhitworth: Right now, they're building all of them themselves. Probably they will still be 90% accessible.
<masonf> gregwhitworth: I'd bet one of the major a11y concerns - are users prevented from doing things? Or just not in the way they want?
<masonf> gregwhitworth: Hopefully the next new element, e.g. <combobox> will be quicker than this one.
<masonf> gregwhitworth: We'll use 90% of the work we've done on <selectmenu>, so it should be quicker. It still might take another 1-1.5 years.
<masonf> gregwhitworth: My only qualm is pragmatic - this takes time. For now, they can get what they need, while we build the next thing.
<gregwhitworth> ack sarah_h
<gregwhitworth> sarah_h: the combobox is interesting
<gregwhitworth> sarah_h: I created 2 of them to do usability studies
<gregwhitworth> sarah_h: we spent a lot of time on how they're different and share the controller code but have some particular differences and how it applies to the web platform
<gregwhitworth> sarah_h: with the select menu enter will go into the menu vs combobox it will not
<gregwhitworth> sarah_h: focus stays within the input itself
<gregwhitworth> sarah_h: since everything is handled through activedescendant vs focus
<gregwhitworth> q+
<gregwhitworth> sarah_h: to think about - how much do we want the combobox to share
<gregwhitworth> sarah_h: how much do we want to share child support patterns?
<sarah_h> ack me
<masonf> gregwhitworth: Something Scott said is resonating with me: how long do we think new things will take?
<masonf> E.g. combobox - how long?
<masonf> q+
<masonf> gregwhitworth: if we were able to say all browsers will ship these things quickly, within 6 months, I'd have a different stance on how strict to be with <Selectmenu>.
<scotto> q+
<masonf> gregwhitworth: It's serving a specific purpose. If we could knock them all out in a year, my position would be 180 different.
<gregwhitworth> ack gregwhitworth
<gregwhitworth> masonf: you asked how fast, it will not be six months
<gregwhitworth> ack masonf
<gregwhitworth> scotto: thank you for that
<gregwhitworth> scotto: I just want to clarify one thing
<gregwhitworth> scotto: the idea of having an input field that comes before the listbox
<gregwhitworth> scotto: that's not going to be a huge issue at all
<gregwhitworth> scotto: any interactive it needs to be exposed as a dialog, reset, etc. This is a very common pattern - in that situation tabbing to the listbox to get to the ok button is expected pattern for combobox
<gregwhitworth> scotto: the concept to be able to shove anything in between options and that's what breaks the list-box expectation
<sarah_h> +1 ro everything Scott said :D
<sarah_h> s/ro/to
<masonf> q+
<gregwhitworth> ack scotto
<gregwhitworth> ack masonf
<gregwhitworth> masonf: the first one we're closer to - should tab key go through options
<gregwhitworth> masonf: or go back out of the popup
<gregwhitworth> sarah_h: the tab key should technically change when it turns into a dialog
<gregwhitworth> masonf: we have been talking about a new element for that
<gregwhitworth> masonf: the resolution we had before and put forward a big warning that they shouldn't do
<gregwhitworth> masonf: it is yet another example that they shouldn't be doing what they're doing and magically changing behaviors
<gregwhitworth> masonf: possibly wait 1yr for the next element that they actually wanting
<gregwhitworth> scotto: don't change the expectation
<gregwhitworth> scotto: give them this kind of expectation
<gregwhitworth> scotto: they'll need to add in their own functionality to make it accessible
<gregwhitworth> scotto: that doesn't present selectmenu from evolving to make them happen and secondary actions if it can be specified
<dandclark> Proposed resolution: Tab key in selectmenu listbox closes the listbox and sets focus back on the button, regardless of tabbing direction. This happens even if there is non-option interactive content in the listbox.
<gregwhitworth> scotto: that would be reasonable to me
<gregwhitworth> dandclark: seems like we're converging
<scotto> +1
<sarah_h> +1
<gregwhitworth> masonf: it's true no matter where the interactive content is right? Whether inside or outside of the option correct?
<gregwhitworth> masonf: just remove non-option
<dandclark> Proposed resolution: Tab key in selectmenu listbox closes the listbox and sets focus back on the button, regardless of tabbing direction. This happens even if there is interactive content in the listbox.
<masonf> +1
<tantek> +1
<dandclark> RESOLVED: Tab key in selectmenu listbox closes the listbox and sets focus back on the button, regardless of tabbing direction. This happens even if there is interactive content in the listbox.

[dandclark]

Closing per today's resolution.