Select-Only Combobox Example: Question about Tab setting selected value

[marcoscv-work]

The problem:

URL of the example: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-select-only/

The tabbing action to make the selection does not provide any feedback about the new selection

Description:

• We open the select combobox
• The current selection is 1 of a list of 10 items
• By using arrows we read the different elements in the list, we get to the final item, 10. We decide none of them are a better selection than the current selection (1) so we decide to press tab key to skip the component Real result: The item 10 has been selected

Conclusion: No feedback is provided to say that you have actually made a selection of item 10

Solution Proposal:

1º Provide feedback after selection by tabbing 2º Do not use tab key for selections and follow native behaviour

[JAWS-test]

... follow native behaviour

native behaviour is at least on Windows in Chrome, Firefox and Edge, that TAB closes the list but keeps focus on the item. The value change already occurs when navigating through the list with the arrow keys and is not undone with TAB or ESC. The only difference here is that with the native select the focus remains by pressing TAB and with the ARIA pattern the focus is moved further.

[marcoscv-work]

I will try to draw a table of behaviors, since surely the behavior changes in different OS and browsers. But I think that using TAB in some cases for skipping components and another ones for confirming selections can be confusing, anyway is a good case for user testing.

What do you think?

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Select-Only Combobox Example Tabbing as selection.

The full IRC log of that discussion

<jugglinmike> subtopic: Select-Only Combobox Example Tabbing as selection
<jugglinmike> github: https://github.com/w3c/aria-practices/issues/2703
<jugglinmike> Matt_King: The feedback that we got is that tabbing doesn't provide any information about new selections
<jugglinmike> Matt_King: This has always been the behavior I expect from selects. When you hear "selected" on the one you want, and you tab out of it.
<jugglinmike> Matt_King: It seems equivalent to the native behavior to me
<jugglinmike> jongund: Do we need to document that, then?
<jugglinmike> Matt_King: The reporter says that tabbing to select is not native behavior. That's right; selection follows focus, so you've already done the selection just by pressing the arrow key
<jugglinmike> Matt_King: I don't quite understand what JAWS-test is saying. Tab moves focus out; that's always an expected behavior. I wouldn't ever expect that tab would not move focus
<jugglinmike> Matt_King: The input itself is not a separately focusable element
<jugglinmike> jongund: On my system, you have to press Enter and then Tab to exit a select drop-down. Kind of like a dialog
<jugglinmike> Matt_King: I don't know if I've encountered that behavior before. I wonder if that's recent
<jugglinmike> jongund: Then again, in Firefox, when you hit tab, it moves focus and changes selection
<jugglinmike> jongund: It looks like Safari models what Chrome does, at least in the latest version of macOS
<jugglinmike> Matt_King: I'll be honest; I prefer what the APG does
<jugglinmike> CurtBellew: Same here. It's also what we do at Oracle
<jugglinmike> Matt_King: I'm trying to think of any other time where tabbing doesn't move you to the next thing. Nothing comes to mind...
<jugglinmike> CurtBellew: I can't think of anything, either
<jugglinmike> jongund: How about a dialog box with only one element inside?
<jugglinmike> Matt_King: Yeah, I suppose so. That feels like an abberation, though; I don't know if it's necessarily a good behavior to model elsewhere
<jugglinmike> Matt_King: The bottom line here is: should we make any change to what we're doing?
<jugglinmike> Matt_King: One suggested change is to issue some kind of notification. The other suggestion is to change the tab behavior.
<jugglinmike> Matt_King: I think we agree that we want to leave the tab behavior the way it is
<jugglinmike> CurtBellew: Yup
<jugglinmike> jongund: Yup
<jugglinmike> Matt_King: Okay. What about adding a notification that would occur when tab is pressed?
<jugglinmike> Matt_King: Is there anyone who would argue in favor of that?
<jugglinmike> [silence]
<jugglinmike> Matt_King: To me, it feels like a little bit of an anti-pattern for screen readers to, upon receiving a tab key press, tell users about the thing they just left
<jugglinmike> Matt_King: Is that something anyone here has experienced elsewhere?
<jugglinmike> Matt_King: You folks who implement design systems: is that something you've built before?
<jugglinmike> [no participants voiced experience]

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Select-Only Combobox Example Tabbing as selection.

The full IRC log of that discussion

<jugglinmike> Subtopic: Select-Only Combobox Example Tabbing as selection
<jugglinmike> github: https://github.com/w3c/aria-practices/issues/2703
<jugglinmike> Matt_King: We discussed this last week, but we only had a few people in attendence
<jugglinmike> Matt_King: Also, the reporter has not responded to the notes from our discussion
<jugglinmike> Matt_King: I'll review it for the folks present today to see if anyone here has a different perspective
<jugglinmike> [Matt_King recaps the issue]
<jugglinmike> Matt_King: Essentially, does anyone see a problem with the way the APG's selection box currently behaves?
<jugglinmike> jamesn: I would be annoyed if it didn't behave the way it does today
<jamesn> https://microsoftedge.github.io/Demos/selectmenu/
<jugglinmike> Matt_King: I'm going to let the person who raised this have an opportunity to respond before closing this as "won't fix." I'll give it some labels so that it doesn't come up in future triage meetings.

[marcoscv-work]

We were keep testing and just can confirm and insist on the fact that by tabbing we are "confirming" an action when we were just reading the options, there is no clue to know my action to "Skip component by tabbing" is actually confirming a selection.

Confirming a selection should be done only by space/enter. If we decide to use tab key to confirm a selection we should announce the new selection since it is not the normal way to confirm things.

Personally I think that base this behaviour that browser is doing it in thas way" is not a really good point or reference to assume this patter is correct.

You decide guys, it is just a suggestion. We detected problems with this type of selection since users are not assuming the selection was modified because they used tab key to skip the component

[mcking65]

@marcoscv-work

If you have a representative sample of users from your user base and they have expectations that differ from the conventions presented in the APG, it would certainly be reasonable to accommodate those expectations.

Here are a few points of clarification regarding the APG Task Force understanding of conventional behavior for single-select widgets.

by tabbing we are "confirming" an action when we were just reading the options,

Pressing arrow key is not just "reading" in a single-select widget. It is also setting the selection. This is the case for screen reader users as well; if you inspect you will see that both aria-activedescendant and aria-selected change value as you press the arrow keys.

In single-select widgets where selection follows focus, there is not typically a distinct "confirmation" action. That is because the selection is changing as you move focus. Blur, whether via mouse or Tab, keeps the current selection. Listbox, tree, radio group, and combobox are consistent in this way.

One single select widget where selection does not follow focus is a menu that contains menu item checkbox (role="menuitemcheckbox") elements. There, Pressing arrow moves focus but does not change which item is selected (checked). In that case, Enter or space checks the item and closes the menu.

there is no clue to know my action to "Skip component by tabbing" is actually confirming a selection.

The clue is the item is selected both visually and in the ARIA.

Confirming a selection should be done only by space/enter.

In multi-select composite widgets, space typically toggles the selected state. Enter often performs other actions. As mentioned above, Enter and Space usually perform other actions or are no-ops in single select widgets. In the case of the select-only combobox, since the focused item is selected, Enter updates the input value and moves focus back to the input.

If we decide to use tab key to confirm a selection we should announce the new selection since it is not the normal way to confirm things.

Since tabbing moves focus, there will be a focus change that triggers screen reader speech. Triggering an announcement on blur would interfere with normal announcement of the next focused item and could cause confusion as users will expect to hear only speech related to the newly focused element.

Personally I think that base this behaviour that browser is doing it in thas way" is not a really good point or reference to assume this patter is correct.

We study browser behavior as well as behavior of native Windows and macOS widgets. It is difficult to say any specific behavior is "correct" because there is no specification that normatively defines keyboard interfaces. The Task Force does its best to document the most conventional, accessible behavior. It's an art more than a science. We welcome data when we can get it. One thing that we have not done well, that we should do, is clearly document the approach to resolving inconsistencies among platforms when documenting keyboard conventions.

Another approach is to modify the arrow key behavior so that it not only moves focus in the list but updates the input at the same time. We opted not to do that in this implementation because keeping the input unchanged until the dropdown is closed helps users understand that pressing Escape leaves the value unchanged.

[marcoscv-work]

@mcking65 thanks a lot for your time explaining the reasoning and all clarifications, it really helps