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

Select : keyboard interaction of live demo differs from accessibility description #3690

Closed
Regine-Lambrecht opened this issue Aug 9, 2023 · 6 comments

Comments

@Regine-Lambrecht
Copy link

Regine-Lambrecht commented Aug 9, 2023

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 ?

@tw15egan
Copy link
Collaborator

tw15egan commented Aug 9, 2023

@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

@Regine-Lambrecht
Copy link
Author

Regine-Lambrecht commented Aug 9, 2023

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.
Then, according to the accessibility description, you should be able to navigate the options without selecting them one after the other, via the down arrow. If you want to change the selection, then you should click ENTER. On the contrary, in the demo, using the down arrow once the list of options is displayed changes the selection one after the other already.

My setting: WIN 11, Chrome 115.0.5790.171. No screen reader ON.

@tw15egan
Copy link
Collaborator

tw15egan commented Aug 9, 2023

Wondering if this is a Windows-specific behavior? Do other <select> elements behave this way on your machine? We are just rendering the browser/os native select element, and do not implement any extra keystroke functionality.

I'm only able to test on Mac at the moment, but this is what I am getting.

2023-08-09 14 47 12

@Regine-Lambrecht
Copy link
Author

Yes, the SELECT behaves differently on Windows, apparently ;( I found documentation of that lack of support.
You can see it here

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:
See also https://github.com/microsoft/sonder-ui/tree/master/src/components/select

@tw15egan
Copy link
Collaborator

@Regine-Lambrecht I would recommend trying the Dropdown component then, as that should implement the select-only combobox pattern shown here. The Select component is intentionally left untouched and is simply the browser's native implementation without any added styling (except the unopened display)

@sstrubberg sstrubberg moved this to ⏱ Backlog in Design System Aug 23, 2023
@guidari
Copy link
Contributor

guidari commented Aug 23, 2023

We are planning the OS handle the Select component, since it is not a issue in Carbon.
If you like a consitent behavior you can try the Dropdown component.

@guidari guidari closed this as not planned Won't fix, can't repro, duplicate, stale Aug 23, 2023
@github-project-automation github-project-automation bot moved this from ⏱ Backlog to ✅ Done in Design System Aug 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Archived in project
Development

No branches or pull requests

4 participants