[select] mult-select variation doesn't allow for keyboard access

[scottaohara]

The 'mult-select' variation of the explainer demos does not presently allow for keyboard focus. Navigating using tab key, it is skipped over.

If one were to open it with the mouse, arrow keys can be used to navigate through the listbox popup's options. However if Space is used, no selection occurs. If Enter key is used the listbox dismisses with no selection taking place.

When a selection is made by a mouse, a list is populated within the 'combobox' where the list item has a 'x' icon. However the combobox remains inaccessible to keyboard and the selected option too is not reachable, nor is communicated as an interactive element which would indicate that it can be removed.

Testing with screen readers, JAWS and NVDA skip over the component completely when navigating with scan mode. Narrator can find the combobox, but always announces it in an expanded state, even with the popup isn't visible. Unlike other screen readers, which skip over the combobox, Narrator can invoke the popup with the Space key. but it cannot select an option, nor can it remove a selected option if one were chosen via mouse click.

Some of what might be needed to correct this example would need to touch on #458, and have clear guidance on what can be slotted for the element that invokes the popup. E.g., a combobox > list pattern like this might need some revisions... and if someone were to replace the standard 'button', then it would have to be with a control that is keyboard focusable.

[dandclark]

Some of what might be needed to correct this example would need to touch on https://github.com/openui/open-ui/issues/458, and have clear guidance on what can be slotted for the element that invokes the popup. E.g., a combobox > list pattern like this might need some revisions... and if someone were to replace the standard 'button', then it would have to be with a control that is keyboard focusable.

Another possibility might be to automatically make the element with behavior="button" focusable by default. That is, for cases like this:

    <selectmenu class="multiselect">
      <div slot="button" behavior="button">
        <ul class="selected-values"></ul>
      </div>
      <option value="Broccolini">Broccolini</option>
     <option>...</option>
    </selectmenu>

We could do either of the following:

1. Treat the <div> as if it had tabindex="0"
2. Actually set tabindex="0" on the <div>.

We already give the div an implicit role="combobox", so this would be a similar idea.

[scottaohara]

That may well work. Another thing that we'd need to figure out too is exactly where the listing of selected items goes. placing it in the combobox will mean that nvda/jaws will drop the list semantics and communicate the separate list items as just a single string of text. if a dismiss button is added to each item choses, and given an accessible name such as "remove" to indicate it's purpose, then the value of the combobox would return as "item 1 remove item 2 remove item 3 remove etc.".

however, if the list was populated as a sibling to the combobox control, and that consistently remained as a button (maybe displaying the number of items or 'multiple items selected'), then that could help mitigate the issue.

There are a few different ways that could be done. but we can discuss that when we get more into the 'button' slotting.

[scottaohara]

would it be possible to do something like:

button part break into 3 slots > [ freeform slotted content ] [ role=combobox ] [ freeform slotted content defaults to down arrow ]

[css-meeting-bot]

The Open UI Community Group just discussed Accessibility issue in custom select.

The full IRC log of that discussion

<hdv> Topic: Accessibility issue in custom select
<hdv> github: https://github.com/openui/open-ui/issues/476
<hdv> dandclark: we would like to allow authors to build custom elements out of divs, but it seems unfortate to require them to add tabindex
<hdv> dandclark: I see two ways to add that… one is to add an implicit tabindex of 0 to the button that triggers, where the browser sets is as if the author had
<hdv> dandclark: the other is to make it explicit, but could be a problem if the author would want to override that
<hdv> dandclark: so I would propose the first, to give an implicit tabindex of 0
<tantek> wondering if this group has ever taken up the sequential navigation proposals from CSS (a more well-designed replacmenet for TABINDEX), or we are assuming there will be no changes to that part of the platform
<dandclark> q?
<scotto> q+
<hdv> JonathanNeal: I was thinking if there were other elements that did this… button, I guess?
<hdv> scotto: my question to that would be… adding tabindex=0… would that always be exposed as a role combobox?
<hdv> scotto: we have the multiselect example where the list of items is shoved in the combobox
<JonathanNeal> tantek: is this the proposal you mentioned? https://www.w3.org/TR/css-nav-1/
<sarah_higley> q+
<JonathanNeal> scotto: wondering, should we allow for people to add or remove the button parts, but maybe allow sibling content to the button parts?
<hdv> sarah_higley: I am currently working on a combobox component… the issues where I've run into with that degree of flexibility… it causes a lot of problems
<hdv> sarah_higley: for instance… we're looking at letting people slot in strings, or random other contents, essentially anything but a string messes up so much, like what if you put a focusable item in there
<hdv> sarah_higley: or if you put in a label it gets the enttire combobox
<hdv> s/gets the enttire/labels the entire
<hdv> sarah_higley: I do see use cases like presentational things, colors etc
<hdv> sarah_higley: so this would be both a problem for interactive content and structured content
<hdv> scotto: most screenreaders turn it into one long string, it would just be one long unbroken sentence
<hdv> sarah_higley: so my question is, what are the guards for types of content that can go in there?
<JonathanNeal> q?
<hdv> ack scotto
<hdv> ack sarah_higley
<hdv> dandclark: there is definitely a question of… it's important to be able to allow authors to have control over the button, like changing the down arrow icon, or remove it entirely, or the way the text is presented
<JonathanNeal> q+
<hdv> dandclark: there are some other presentational things that I feel like there should be some flexibility
<hdv> dandclark: but can understand for interactive and structured content it is a problem, so we should look at the boundaries of what we allwo
<hdv> s/allwo/allow
<hdv> ack JonathanNeal
<hdv> JonathanNeal: I see two sets of question here… (1) what is the content that should be allowable, what will be forced upon the question, (2) the question about forcing tabindex (?)
<hdv> JonathanNeal: so I wanted to raise the question tantek had asked
<hdv> JonathanNeal: about the sequential navigation proposal from CSS
<hdv> JonathanNeal: would that apply here?
<hdv> tantek: it is not part of the current proposal, but it was a prior proposal, which predates a lot of incubation practices… we never quite got it off the ground, resolving enough issues. I'll see if I can find a reference
<hdv> tantek: CSS explored two directions for non-mouse navigation / non pointer navigation
<bkardell_> (maybe 3 if you count discussion around some grid and flex reordering and whether those could/should afffect)
<hdv> tantek: one is spatial navigation and the other is sequential navigation (what people think of as tab/shift tab)
<hdv> tantek: they were explored originally in the same proposal, but are two distinct bits of functionality
<bkardell_> should note that there is a whole metabug around issues and it isn't even complete in whatwg
<sarah_higley> q+
<hdv> tantek: there are a number of problems with tabindex and these proposals were seeking to solve those
<hdv> tantek: I would be fine with having this group pick that up and run with it , as one of the people involved with the original proposal, speaking for myself
<JonathanNeal> q?
<hdv> JonathanNeal: so CSS influencing more behaviour has been a subject with much interest from a lot of folks, maybe it has reached a time to explore more
<hdv> sarah_higley: I thought the issue with tabindex was that if someone used a div, it would not show up in focus order?
<hdv> dandclark: that's what I was raising… tabindex was just the platform term I thought of
<hdv> sarah_higley: is there a reason not to have that slot be the combobox element itself rather than its children?
<hdv> dandclark: there is stuff about the combobox button itself and how it is shaped
<tantek> More on where CSS sequential navigation details: https://github.com/w3c/csswg-drafts/issues/3377
<hdv> JonathanNeal: given we're at time, thank you very much!
<sarah_higley> ack me
<JonathanNeal> q?
<tantek> s/where CSS/CSS
<hdv> RRSAgent, make minutes please
<RRSAgent> I have made the request to generate https://www.w3.org/2022/03/17-openui-minutes.html hdv
<bkardell_> proposed resolution: JonathanNeal did a good job chairing
<hdv> +1
<hdv> tantek: I'll dig up the links, if there is interest from folks here to look at gaps with tabindex I would personally support this group looking at this
<miriam> +1 excellent chairing, thanks for stepping in on that JonathanNeal
<tantek> yes, great job chairing!
<hdv> chair: JonathanNeal
<hdv> RRSAgent, make minutes please
<RRSAgent> I have made the request to generate https://www.w3.org/2022/03/17-openui-minutes.html hdv
<hdv> meeting: Open UI 17 March
<hdv> RRSAgent, make minutes please
<RRSAgent> I have made the request to generate https://www.w3.org/2022/03/17-openui-minutes.html hdv

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[josepharhar]

I'd like to address any changes to the single-select selectmenu, since this issue seems to be mostly focused on multi-select selectmenu which we will be tackling later.

We could easily make the button part always keyboard focusable. @scottaohara does this sound like a good idea for single-select? Are there any other changes for single-select that you think we should do?

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[josepharhar]

We could easily make the button part always keyboard focusable.

This has effectively been done now that the button part is a <button type=selectlist>

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.