[combobox] Allow Combobox.Clear to be focusable and keyboard navigatable

[StefanDejanovskiOcuco]

Feature request

Allow the "Clear selection" button to be accessible by keyboard navigation (tab and arrow keys)

Summary

Currently Combobox.Clear renders with tabIndex={-1} which makes it inaccessible, it would be great if the component has a prop that allows the users to access it via keyboard

Examples in other libraries

https://www.mongodb.design/component/combobox/live-example

Motivation

Currently, keyboard-only users cannot clear their selections without using a mouse, creating a significant accessibility barrier.

Current workaround limitations:

• Users must either use a mouse (not possible for some users)
• Delete selections one by one (time-consuming for multiple selections)
• Navigate away and return to reset the field (disrupts workflow)

[mnajdova]

The cleara button is a mouse equivalent of the Del keyboard key, so there is no need to be focusable inside it will create more friction as each selected item will need to either act as a trap focus zone or have two tab stops.

So, in practice, Arrow left/right allow keyboard user to focus each combobox item that is selected, and Del removed the item.

[StefanDejanovskiOcuco]

I agree that two focusable elements will create friction for the Combobox.Chip component,

but this request is for the Combobox.Clear component not Combobox.ChipRemove

[atomiks]

<Combobox.Clear tabIndex={0}> works, no? But yes, the problem here is multiple tab stops in a form. Ideally each field is one single tab stop. For keyboard users (when not using a screen reader), Esc will clear the value in the input (when the popup is closed), or deleting all the text in the input

[sarthakmalik0810]

@atomiks Yes Esc works, but when you are in a Dialog, Esc would actually close the dialog as well. Atleast thats what happened when I used it in a Radix Dialog.

[StefanDejanovskiOcuco]

@atomiks <Combobox.Clear tabIndex={0}> doesn't work fully, this makes the element focusable via Tab, but the keyboard navigation with left and right arrow keys is done by the library and won't focus the Clear component.
Esc is great, but Clear is an interactive component and it should be able to be navigated to via keyboard consistently, as it is with the Chips elements.

@sarthakmalik0810 I think that's expected, the event should be prevented from bubbling up in order for the Dialog to stay open.

[atomiks]

It does prevent bubbling on Esc, and works with our Dialog at least

keyboard navigation with left and right arrow keys is done by the library and won't focus the Clear component

What is the reason the Clear button should be part of the composite loop? Other examples of this pattern (e.g. Chakra UI and Material UI) don't include the clear button as part of the focus loop or tab order

A blog post https://scottaohara.github.io/clear-text-field-button/ explains why the clear button is not in the tab order:

The clear button is purposefully not in the tabbing order of the web page. Keyboard users can use the Delete or Backspace keys (or first select all the text field's text and then use these keys) to delete the contents of the text field.

Important: if the clear button was part of the web page's tabbing order, every text field a user had entered data into would then require that they tab past the clear button that they have no use for. This clear button being useless to them if they had filled out the field with the data they intended. Adding clear buttons to the web page's tabbing order is not recommended for this reason, as it has the potential to require two keyboard focus stops for every text field on the page that has a clear button.

The HTML also excludes the clear button from the tab sequence https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/search.

mui/material-ui#44936 (comment)

[StefanDejanovskiOcuco]

It's interesting that the input with type="search" works in this way, though this was introduced in 2015 and seems outdated.

IMO, I don't agree with the blog post, and I think this is not great UX. There isn't a way for the screen reader to announce the clear button, and there IS obviously a button which is intentionally hidden from screen readers (i.e., people who rely on screen readers).

Hiding it from screen reader, on blur or on mouseout just makes it less discoverable.

Also, MDN states this: https://developer.mozilla.org/en-US/docs/Web/Accessibility/Guides/Understanding_WCAG/Keyboard#click%E2%80%A6 (Currently the Combobox.Clear is a button → clickable element, and has tabIndex={-1} which removes the interactive semantics)

https://www.w3.org/WAI/WCAG21/Understanding/keyboard.html - You can argue that the Esc key is enough to satisfy this constraint, but providing multiple paths is better UX.