[SELECT] Does space remove the open state and select the currently selected option

[gregwhitworth]

@dandclark noticed a gap during a PR for type ahead so I'm filing an issue for the group to weigh in. Currently the spec states that the space key event is tied to the listbox part. What this means is that when the listbox one of its children has focus and the space key is pressed, it will change the state of open and select the currently selected option. This would only be true of selects that don't have an attribute of multiple.

Should space select the currently selected option and change state, here is what Daniel found looking at the UI libs:

No functionality would be lost because it 'space' currently has the same behavior as 'Enter' for listbox. Looking at the design systems listed at https://open-ui.org/components/select.research#names, (looking at button/listbox selects only, not the comboboxes with text input whose typeahead will work differently) I found these results: Space doesn't do anything: Ant Design, Evergreen, Lightning (this one has typeahead), Semantic UI, Bootstrap (space toggles when on the button, but not when focus tabs into the listbox) Space closes the popup, no typeahead: Atlassian, Material, Fluent UI Space closes the popup, has typeahead: Carbon Carbon is funny because in their live demo you can see that closing on space breaks their typahead. Try selecting "Gray 100" via typeahead -- it's painful.

If we want to keep the behavior where 'space' closes the listbox and/or selects an option, I only see two possibilities:

1. Don't allow 'space' in typeahead. This means that multi-word examples can't be easily selected via typahead, as in the Carbon example.
2. Treat 'space' as part of the typeahead if a search is underway, but make it select an option/close the popup otherwise. This seems even more confusing and opaque to users than the current typeahead behavior in browsers.

Neither of these are great so I'm in favor of removing the keyboard(space) handlers from the listbox and relying on Enter for that functionality.

[dandclark]

My findings including the links, in case anyone wants to look for themselves, are:

Space doesn't do anything: Ant Design, Evergreen, Lightning (this one has typeahead), Semantic UI, Bootstrap (space toggles when on the button, but not when focus tabs into the listbox) Space closes the popup, no typeahead: Atlassian, Material, Fluent UI Space closes the popup, has typeahead: Carbon Carbon is funny because in their live demo you can see that closing on space breaks their typahead. Try selecting "Gray 100" via typeahead -- it's painful.

[devongovett]

In React Aria we support the Space key to select an option and close the listbox, except if the user is currently using typeahead. In that case, the space is added to the search string. https://github.com/adobe/react-spectrum/blob/main/packages/@react-aria/selection/src/useTypeSelect.ts#L55-L62

[dandclark]

Interesting, thanks @devongovett . I'd considered that possibility but had dismissed it because I thought that dynamically changing the behavior of 'space' like that would be confusing for users. But I hadn't actually tried it yet. If that's working well in the wild then maybe I was wrong and that's the best option after all.

[chrisdholt]

@devongovett @dandclark I'm open to exploring this, but as we look to creating a standard I share some of Dan's original concerns.

@devongovett could you share a bit about what it means in your implementation for a user to be using typeahead, specifically as it relates to timing (or the timeout as noted in the above link). I think it's great to have a working example, but I'd like to dig into the implications of timed events and the WCAG success criteria for 2.2.3:

Success Criterion 2.2.3 No Timing (Level AAA): Timing is not an essential part of the event or activity presented by the content, except for non-interactive synchronized media and real-time events.

As of now, it seems more like the exception rather than the rule. I do have similar concerns though to changing the behavior of the listbox, but this specific scenario with space is complex.

[devongovett]

Our implementation attempts to recreate native <select> behavior. As the user types characters, they are appended to a search string. If no character has been typed after 500ms, the search string is reset. If the user types a space character, and there is already a search string containing non-whitespace, then we append the space to the search string and prevent the selection behavior. If a space is typed but there is no existing search string, then the option is selected and the listbox is closed. So, it depends whether preceding characters had been typed within the last 500ms. We did a bunch of testing, and this matches native typeahead behavior pretty closely, so I would imagine users are familiar with it already.

[carmacleod]

@dandclark

Carbon is funny because in their live demo you can see that closing on space breaks their typeahead. Try selecting "Gray 100" via typeahead -- it's painful.

Just for the record, the control containing "Gray 100" is a Carbon Dropdown and not a Carbon Select. Their Dropdown does have weird typeahead behaviors. I have opened a couple of issues to address those:

• https://github.com/carbon-design-system/carbon/issues/10628
• https://github.com/carbon-design-system/carbon/issues/10634

Their actual Select (the control labelled by Select) seems to work ok for typeahead containing space. https://www.carbondesignsystem.com/components/select/usage/#live-demo

[github-actions[bot]]

There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label.

[josepharhar]

This is similar to #386, here are my findings for spacebar behavior: https://github.com/openui/open-ui/issues/386#issuecomment-1439156154

[josepharhar]

I think that we should decide on this behavior in #386