-
Notifications
You must be signed in to change notification settings - Fork 785
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
Select : keyboard interaction of live demo differs from accessibility description #3690
Comments
@Regine-Lambrecht This is the behavior I am seeing, what interaction is not matching? It may be a browser-specific issue, and in that case, could you provide the browser you're encountering this behavior? This link may be easier for testing: https://react.carbondesignsystem.com/iframe.html?args=&id=components-select--default&viewMode=story |
For instance, if you tab until you reach the Selector, and then uses the down arrow, it will change the selected option. The accessibility description says it should open the list of options instead. My setting: WIN 11, Chrome 115.0.5790.171. No screen reader ON. |
Wondering if this is a Windows-specific behavior? Do other I'm only able to test on Mac at the moment, but this is what I am getting. |
Yes, the SELECT behaves differently on Windows, apparently ;( I found documentation of that lack of support. There has been a study that still recommends using the SELECT, but it does not consider the usability issue of having to memorize the currently selected option and come back to it if you want to escape the list of options without modifying. That is the same issue as with radio buttons: you cannot discover the options without selecting each one you just wanted to hear, and you have to come back to the first if this is finally what you wanted. You also lose track of any default selection once you discovered the other options. But ok, there is no alternative for radio buttons, and they all behave like that until the W3C created a custom one based on ARIA that could behave better :). For the select feature, all other clickable components that also display a list of options with unique selection after user interaction, do have a "browse" only interaction, like the SELECT on Mac:
We have to remember that the visitor doesn't know which HTML is behind the scene. He just sees/hear something that is clickable and displays a list of choices. Why not coding them so that they all behave the same: arrow down opens, other arrow down puts focus/reads aloud without selecting, ENTER selects, ESC closes without changing the initial value ? To get that keyboard interaction for MacOS AND Windows, one should use the ARIA Select-only Combobox pattern: |
@Regine-Lambrecht I would recommend trying the |
We are planning the OS handle the Select component, since it is not a issue in Carbon. |
The Accessibility tab of the Select component says it should open the option list with Up/down arrow, and then only navigate options in the listbox when using Up/down arrow keys again. ENTER should select the item. It also says that ESC closes without changing the selected option. This is also what W3C recommends for the single select combobox in aria, explaining that it improves the HTML SELECT behaviour: "the following differences in behavior are implemented to improve both accessibility and general usability".
The issue is that the live demo of the SELECT in CARBON DS does not behave like that.
So how do we implement the keyboard interaction described in the accessibility tab ?
The text was updated successfully, but these errors were encountered: