Clarify behavior on initial focus vs. re-focus for Listbox Multi-select

[shamiguel]

It would be beneficial to introduce language into the recommendation for multi-select Listboxes that: focus be applied as recommended initially or "on page load", and then on subsequent focus events, should reapply focus to the previously focused option.

Context:
While working on implementing a multi-select and scrollable listbox, my team noticed that the recommendations for applying focus to such a listbox could benefit from some clarification.

Applying the recommendation along with logic to scroll the first option/first selected option into view resulted in a few bugs in our implementation, particularly in regards to applying focus from click interactions.

However, applying the recommendation only to the initial focus event and then focusing on the previously focused option upon subsequent focus events resolved our issue. Additionally, the multi-select rearrange-able options example illustrates this exact implementation:

Please let me know if there are any other details or context that would be beneficial and thank you for your time!

[0ddfell0w]

Agree this is a helpful distinction to make. There's precedent for this with the Toolbar pattern

Keyboard Interaction
Tab and Shift + Tab: Move focus into and out of the toolbar. When focus moves into a toolbar:
If focus is moving into the toolbar for the first time, focus is set on the first control that is not disabled.
If the toolbar has previously contained focus, focus is optionally set on the control that last had focus. Otherwise, it is set on the first control that is not disabled.

There are other patterns for which this would apply, e.g. Tabs with manual activation

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Improving guidance for setting focus in multi-select listbox.

The full IRC log of that discussion

<jugglinmike> Topic: Improving guidance for setting focus in multi-select listbox
<jugglinmike> github: https://github.com//issues/2958
<jugglinmike> Matt_King: I'm having a little bit of difficulty following the text in the issue
<jugglinmike> Jem: This is about focus management
<jugglinmike> Jem: I'm reviewing the visual recording
<jugglinmike> Matt_King: I think it would be helpful if the reporter added explicit steps to reproduce, including each of their interactions with the keyboard
<jugglinmike> Jem: Yes. We can review this asynchronously and discuss it again next week
<jugglinmike> Zakim, end the meeting

[shamiguel]

Hi again and thank you for taking time to look over this issue and for your feedback. The steps to reproduce this:

1. Tab into the listbox for Example 2: Multi-Select Listbox (notice that the first option does not automatically receive visual indicator focus, if you press Space however, the first option is selected).
2. Press Down Key - visual focus is now on the first option.
3. Press Down Key again - 2nd option is now focused.
4. Press Tab to move focus away from the listbox.
5. Press Shift+Tab to move focus back to the listbox. The 2nd option is focused and has visual focus.

This functionality here differs slightly from the recommendation for focus management in a multi-select Listbox in that focus is initially applied to the first option, but is then applied to the previously focused option. This functionality made sense in our implementation and this is why we believe adding this note may be helpful for the original recommendation.

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Improving guidance for setting focus on multiselect listbox.

The full IRC log of that discussion

<dmontalvo> Topic: Improving guidance for setting focus on multiselect listbox
<Matt_King> github: https://github.com//issues/2958
<dmontalvo> Matt: This is back on the agenda. We discussed it previously. The original poster has added some steps for reproduction
<dmontalvo> Matt: Maybe we should go through these.
<dmontalvo> [[Jemma shares screen]]
<dmontalvo> Matt: Second one. Available upgrades is the name of the first list box. He says that we should select the first option.
<dmontalvo> Jemma: They say pressing space, the fourth option is selected. But my space key does not select anything at all
<dmontalvo> Matt: I had to press down arrow to select it
<Jem> steps to reproduce
<Jem> Tab into the listbox for Example 2: Multi-Select Listbox (notice that the first option does not automatically receive visual indicator focus, if you press Space however, the first option is selected).
<Jem> Press Down Key - visual focus is now on the first option.
<Jem> Press Down Key again - 2nd option is now focused.
<Jem> Press Tab to move focus away from the listbox.
<Jem> Press Shift+Tab to move focus back to the listbox. The 2nd option is focused and has visual focus.
<dmontalvo> Matt: I think there might be a bug here. When I shift tab it stilo returns to the previously selected list item. It's going back to the item that had focus, it's not going back to the first selected item
<dmontalvo> Jemma: But if you select three items, then tab away, and shift tab back, it gets back to the first selected option
<dmontalvo> Matt: It is consistent that it always goes to the last focused one, and that's not what the documentation says about it.
<dmontalvo> Matt: Seems shift tab is just returning to the last focused item
<dmontalvo> ... It is not working that way
<dmontalvo> ... Is that the way we want it to work?
<dmontalvo> Matt: The regression test is not testing this behavior apparently
<dmontalvo> ... Do we want the documented or the existing behavior?
<dmontalvo> Jemma: Documentation makes sense to me
<dmontalvo> Jon: It seems current interaction makes sense to me
<dmontalvo> Matt: This is different from the select element. It reads all selected values
<dmontalvo> Jon: That's up to the screen reader
<dmontalvo> Matt: No
<dmontalvo> Cory: That seems like a screen reader back
<dmontalvo> Matt: I'm talking native select element, when you tab into it, I think screen readers read the value
<dmontalvo> ... I think that's different than the multi-select list box
<dmontalvo> Jon: The value is not an attribute of the list box
<dmontalvo> Matt: Never mind. Screen readers must be doing it some other way
<dmontalvo> Jon: I'll have to look at how it's exposed
<dmontalvo> Matt: This pattern has been around for a long time.
<dmontalvo> Jon: Not sure about Iaccessible2 mappings
<dmontalvo> @@: We don't use to implement it like this example. The tab key woudln't function this way. We don't use the multi-select list box pattern, ours is slightly different
<dmontalvo> Cory: Ours is also different, they become buttons
<dmontalvo> Matt: Yes, in other patterns selectable items are not presented like they are in here
<dmontalvo> Matt: I think we should treat this as a bug, Should we do what is in the pattern or what the documentation says?
<dmontalvo> Jon: Users tabbing away and tabbing back may not understand why the focus changes. That is a dangerous thing, for a keyboard-only user that would be a disconnect. Also if whatever was selected is no longer in view, when they tab back that'll scroll back up again, which is problematic for long lists
<curtbellew> +1
<dmontalvo> ... Also it might be disorienting to screen reader users who would predict where they would be and then when they tab back that wouldn't match
<dmontalvo> Matt: Normaly when you tab to the single select list box the selected value is focusable
<dmontalvo> .. If selection follows focus then it makes sense that it gets to the selected item, if not maybe it does not make sense
<dmontalvo> Jon: I think the screen reader needs to compute some multi-select value, maybe it's doing it already, I am not sure
<dmontalvo> Matt: If selection follows focus and it's a single select there should be no question. Arrow through the list box, choose one, tab out, tab back and you'll hear the selected item
<dmontalvo> ... It's in a multi-=-select where selection does not follow focus where the problems appear
<dmontalvo> Cory: I would expect it to announce the selected items
<dmontalvo> Jemma: Same
<dmontalvo> Cory: If it's five or six, that's great. If it is more, not so much
<dmontalvo> Jon: At least the number of selected items
<dmontalvo> Daniel: How screen readers present the information may have the most impact on the user experience
<dmontalvo> Matt: We don't dictate what screen readers do. What do you expect the list box to do?
<dmontalvo> Cory: I would expect my focus to go to the first selected item
<dmontalvo> Jon: I think that is a disconnect for a keyboard-only user, and also for a screen reader user if that focused item is far away
<dmontalvo> Matt: In this example there is nothing retained
<dmontalvo> Daniel: Makes sesne to me to get back to the last selected element
<dmontalvo> Matt: And when you go there for the first time, maybe something else has made a selection. What should we be doing then?
<dmontalvo> Jon: I don't think that should behave differently
<dmontalvo> ... It's difficult to make assumptions of what people would be doing in multi-select box
<dmontalvo> Curtis: I always expect if I leave something and go back to it, that I land where I was before.
<dmontalvo> ... Sometimes for a keyboard user you may not know what is selected
<dmontalvo> Matt: The concept of the multi-select here is probably not the same as an HTML select, as it doesn't allow you to readily see what is selected.
<dmontalvo> Jon: Selection follows focus is the same thing. We maybe should take it out of the equation
<dmontalvo> Matt: Seems we need to change the guidance. IF you wanted to reveal what is selected you should not be doing it with this widget, as you'd have to scroll through all to see which ones are selected.
<dmontalvo> Matt: This now becomes an issue to potentially change the pattern. I think the way to handle this is to label this issue as related to guidance and the pattern, and editorial
<dmontalvo> rrsagent, draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2024/04/16-aria-apg-minutes.html dmontalvo