Open marcoscv-work opened 1 year ago
... 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.
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?
The ARIA Authoring Practices (APG) Task Force just discussed Select-Only Combobox Example Tabbing as selection
.
The ARIA Authoring Practices (APG) Task Force just discussed Select-Only Combobox Example Tabbing as selection
.
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
@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.
@mcking65 thanks a lot for your time explaining the reasoning and all clarifications, it really helps
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:
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