Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Single-select collapsible listbox example: First down arrow when list closed should ONLY open the drop-down list #1850

Open
maryjom opened this issue Apr 8, 2021 · 5 comments

Comments

@maryjom
Copy link

maryjom commented Apr 8, 2021

Example for single-select dropdown list has unexpected keyboard behavior. When focus is on the dropdown when the list is not open, the first down arrow action should only open the dropdown list and put focus on the currently selected item. This example is ALSO moving focus (thus selecting) the next item in the list which changes the original selection. This is an unexpected behavior.

In addition, if you use enter key to open the drop-down the Neptunium item isn't showing that it's selected and focus isn't moved to it. Should it? I was thinking the interaction when the drop-down is closed and you use either enter or down arrow to open it that the behavior would be the same. Currently it isn't

@JAWS-test
Copy link

Note: The problem occurs only if the list was already open and not when the list is opened for the first time.

By the way, the page describes the behavior exactly like this: arrow key opens the list and moves the focus. So error would be that it doesn't happen the first time it is opened.

If the element is to be used to emulate the HTML select: This will not open with arrow key operation. Instead, it remains closed, but the next list entry is immediately selected when the arrow keys are pressed.

@carmacleod
Copy link
Contributor

Note that this example is going to be deprecated in favor of the Select-only Combobox example.

@maryjom
Copy link
Author

maryjom commented Apr 9, 2021

The select-only combobox also behaves differently than I would expect. Since focus is never moved to the drop-down list, there is no option to have the "Esc" key dismiss the list and undo your changes to the selection. Years ago I worked with Matt on an IBM UI element project that documented behaviors for keyboard, etc. @carmacleod I can give you access to that work that I preserved internally if you'd like to take a look.

It also eliminates the ability to extend its usage to become a multi-select dropdown where focus would have to be in the list to see/activate multiple selections. The multiselect example in the ARIA examples is not a dropdown but always-open variety so doesn't capture some of the keyboard behaviors and interaction that should happen when opening/closing the dropdown. (by tabbing away, by pressing escape, by pressing Alt+up arrow.

@smhigley
Copy link
Contributor

smhigley commented Apr 9, 2021

@maryjom the escape behavior was a choice on our part, and isn't tied to whether the focus remains on the combobox, or moves into the listbox. Multiselect listboxes can also be created without moving focus into the listbox itself, e.g. like last example here: https://codepen.io/smhigley/pen/gObMVzv.

Right now, the escape key in the select-only combobox example should be undoing changes to the selection, since that example does not move selection with focus. If you're finding something different, please let us know!

@carmacleod
Copy link
Contributor

@maryjom What platform/browser are you using? I just tried the Select-only Combobox example on Chrome/FF Windows, and Chrome/Safari Mac, and for me, Escape does dismiss the list without changing the selection from what it was previously. Also, just making sure you noticed the Accessibility Features section on the example page? It mentions the rationale behind the decision for selection not to follow focus, and the behavior of the Escape, Space, Enter, and Tab keys. @mcking65 was on board with these changes.

We have an open issue to add a Multiselect combobox example. When we work on that, we will have plenty to discuss regarding keyboard support. It would be great if you could add a comment to that issue with suggestions for expected keyboard behavior!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants