Select : keyboard interaction of live demo differs from accessibility description about carbon-website

[tw15egan]

@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]

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]

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.

[Regine-Lambrecht]

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:

• an action button with focus,
• an action button with descendant ,
• a navigation menu with sub-menu (you expand, your browse the options, you click ENTER to select)
• editor menu bar
• all navigation menus of links "behind" a clickable entry

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]

@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)

[guidari]

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.