docs/react-v9/contributing/rfcs/react-components/components/combobox-spacebar.md
@smhigley @jurokapsiar
This RFC deals with how to provide space-to-type behavior in v9 Comboboxes.
The central issue is that spacebar is both a common selection key and a typeable character, and Combobox is a control with both selection and typing functionality.
While this RFC deals only with Combobox and not Dropdown, it is important to note that semantically Combobox and Dropdown are essentially the same. Expectations among screen reader users for keyboard behavior seem to easily carry over between the two. Non-editable comboboxes are a more common and simple control, and are likely influencing keyboard expectations with editable comboboxes.
Another important factor to note is that using Enter to select is not as common as might be expected, since it is also the key that submits a form, and often avoided within forms for that reason. This is less of an issue with a standalone combobox where selection and submission are not different interactions.
Currently, there is an agreement on inserting a space character when freeform variant is used and the user has not interacted with the dropdown list. See feat: react-combobox space conditionally inserts character when freeform is true for details.
In an A/B user study focusing primarily on screen reader users and alternative input users (keyboard, switch, voice control), people using the keyboard overwhelmingly expected space to select in all comboboxes. In variations where space did not select, this was called out as one of the primary confusing things about the component, particularly strongly with multiselect comboboxes.
The two caveats to consider when evaluating the user study are that it is impossible to fully and realistically recreate real-world app context and expectations in an isolated test UI, and also that it focused on a small group (~12) of participants who all used some form of assistive tech. It points towards an expected behavior, but is not an absolute conclusion.
The surrounding context of an app or website is also likely to influence user expectations on keyboard behavior. Typing a name into a To: input in Outlook or Teams is likely to influence users to expect space to insert a character. Moving through multiple fields in a form is more likely to influence users to expect space to select. The ideal spacebar behavior is likely to differ based on how and where the v9 Combobox is being used.
The content of options also influences user expectations -- there would be a greater expectation of space-to-type when options contain a space in them, for example multi-word options, names, states or cities.
One of the risks is that the developers and designers may not be in a position to make a correct decision on the value of the prop. This is because options are usually either translations or user data, which may contain spaces that the authoring team was not aware of. We generally can't expect authors to understand all possible translations across supported languages or the specific validations of the user data at UI authoring time. While the occaisonal space character does not necessarily mean that space should not select, translations and user data do introduce the possibility of frequent spaces within multiple options.
We cannot fully know whether the ideal spacebar behavior is to select or insert a character, since we don't know the full context of usage. Our choices mostly revolve around balancing providing more flexibility vs. more consistency, and choosing the best default if we do provide flexibility.
After the offline discussion (happened at 17th May 23) we went with the following solution.
Dropdown does select on spaceCombobox does not select on space, always inserts a character in the inputallowSpaceCharacter prop, default to trueThis is the option that allows authors to choose the best behavior for their use case, defaulting to allowing space to insert a character. This borrows the behavior from the freeform PR, where space will still select if the user is actively interacting with the dropdown listbox (i.e. it is open, and the last interaction was to navigate through options).
We would likely include author guidance that all Comboboxes within their app use the same behavior for allowSpaceCharacter.
true means the default probably(?) matches the majority of Combobox usagetrue means that often-missed use cases like spaces in translated strings or user-generated options won't cause issuestrue means the simplest/most basic use case is not the defaulttrue means the Combobox space behavior is different from Dropdown by default, which primarily affects keyboard and screen reader users.allowSpaceCharacter prop, default to falseThis is the same as (1), but with a different default. The Pros/Cons list is essentially the same, but reversed.
Since options visually look like they have check marks and semantically use aria-checked instead of aria-selected, there is a stronger expectation of space-to-select. Additionally, multiselect comboboxes are already hitting a limit of too much complexity for one component, and most use cases would benefit from using either the multiselect Dropdown or single-select Combobox + tags instead. Opting into a simpler, more intuitive but less feature-rich UX might result in a less error-prone UX in this variant in particular.
In this option, we would still have an allowSpaceCharacter prop with one of the defaults in (1) or (2), but also provide a context that allows an entire app to change the default for all Comboboxes within it.
Spacebar behavior issues: https://github.com/microsoft/fluentui/issues/26361, https://github.com/microsoft/fluentui/issues/26295 Freeform PR: https://github.com/microsoft/fluentui/pull/27025