[Autocomplete] Accessibility issues with keyboard navigation Autocomplete

[martha]

Steps to reproduce

A) In Autocomplete, the Clear button is not accessible by keyboard. To reproduce:

1. Visit Combo box example
2. Select an option, then press tab

Expected: Focus moves to the now-visible Clear button
Current: Focus moves out of the example

My workaround:

slotProps={{
  clearIndicator: {
    tabIndex: 0,
    // In order to make the Clear Button focusable, disable the default behavior of hiding it except on hover
    sx: {
      visibility: 'visible',
    },
  },
}}

However, with this workaround, the clear button can only be activated with Space. Ideally, it would be activated with either Space or Enter.

B) In Autocomplete with Multi, pressing Enter when focused on a selected dropdown element causes the element to get deleted. To reproduce:

1. Visit Multiple Values example, press Reset Focus button
2. Press Tab then down-arrow to open the combobox
3. Press Enter

Current: The selected option is deleted from the selection.
Expected: My expectation is that the dropdown would close, and the selected option would stay selected. (But perhaps this is intended behavior?)

C) In Autocomplete with Multi, when navigating with Voiceover, after deleting an option, focus returns to the document body. To reproduce:

1. Visit Multiple Values example
2. Enter an option or two.
3. Using VO, ctrl-option(or capslock)-left to select an option and delete.

Current: Focus shifts to the document body
Expected: Focus remains on the autocomplete component. (Perhaps this a bug with VO, not MUI?)

D) In Autocomplete with Multi, users should be able to tab around the selected options. To reproduce:

1. Visit Multiple Values example
2. Select multiple options, then press shift-tab.

Expected: Focus moves to the option chips
Current: Focus moves out of the example. Option chips can only be focused using left-right arrows. Relates to other issues with chip accessibility #20470, but I think this is a separate problem specific to chips within Autocomplete.

Current behavior

No response

Expected behavior

No response

Context

Hi MUI maintainers! While my team was auditing our app's accessibility, we came across a few things that we thought were accessibility problems within the Autocomplete component. Since we couldn't find existing issues for these, we wanted to create an issue to discuss with you. Let us know, which ones of these are desired behavior, which you'd consider bugs, and which may be fixed with the upcoming work on #25365!

I'll add the caveat that we are not screenreader users, ourselves.

This is my first time creating an issue in the MUI repo. Please let me know if anything else would be helpful. Thanks!

Related issues:

• [Autocomplete] Update to ARIA 1.2 #25365
• [RFC] Chip markup #20470

Your environment

Tested using examples in the current MUI docs (see links above), using VoiceOver on Chrome.

Search keywords: accessibility autocomplete

[ZeeshanTamboli]

Hi @martha,

Thank you for raising these accessibility concerns! It would have been better to create separate issues for each. However, it's fine now. Here’s a response to each point:

A) This is expected behavior. Please refer to #30815 and the combobox ARIA pattern:

The popup indicator icon or button (if present), the popup, and the popup descendants are excluded from the page Tab sequence.

B) Pressing Enter on a selected option deselects (removes) it. This is intentional, as it provides a way to remove an option using the keyboard. Without this, keyboard users would lack a mechanism to remove selections.

C) I couldn’t fully understand the reproduction steps, especially:

Using VO, ctrl-option (or capslock) + left to select an option and delete.

Could you clarify or provide more details about this step?

D) This is expected behavior. The Tab key (or Shift + Tab) is intended to move focus between inputs, not chips. See #18150 (comment) for additional context. Navigation within chips is supported via Arrow Left/Right keys.

Thanks for bringing these up! Let us know if you need further clarification.

[martha]

Thank you so much @ZeeshanTamboli !

A) Sorry I missed that someone had already created a related issue. I have a follow-up question. The Combobox WAI docs that you linked don't seem to mention the Clear button, only the Popup indicator. Maybe I am missing something, but I wasn't able to find any aria docs that indicate that a Clear button should not be included in the page tab sequence. Do you have a link to such docs?

B) Here, I also wasn't able to find aria docs indicating that this would be expected behavior. The Combobox docs describe the following behavior on enter:

If the combobox is editable and an autocomplete suggestion is selected in the popup, accepts the suggestion either by placing the input cursor at the end of the accepted value in the combobox or by performing a default action on the value. For example, in a messaging application, the default action may be to add the accepted value to a list of message recipients and then clear the combobox so the user can add another recipient.

This doesn't mention removing the accepted (selected) value if it is already accepted.

To me, this seems related to A. If there were a keyboard-accessible way to access the Clear button, overloading the 'Enter' behavior in this confusing way would not be needed.

C) Yes! I'm sorry for the lack of clarity. Here is what I meant by "Using VO, ctrl-option(or capslock)-left to select an option and delete."

1. Turn on VoiceOver (VO), the Mac built-in screenreader. (My team used this for testing since it is free on our devices. We haven't tested using paid screen reader technology, such as NVDA.) By default, the command-f5 key sequence turns VO on. See About VoiceOver section in this guide.
2. Navigate left using the VO keys, which are Control-Option by default, but are often re-mapped to Caps Lock. (So this would be Control-Option-Left Arrow, unless the device has overwritten the VO keys, in which case it would be Caps Lock-Left Arrow.)
3. Press the Delete button to remove a selected option
4. Focus returns to the document body, but it should stay on the Autocomplete element.

Let me know if this helps!

D) Thanks again for the link to the prior conversation, and sorry that I missed it before! (I should have searched the closed issues more carefully.) On this, I'm also wondering whether you have links to any aria docs that describe this behavior as desirable.

Thank you very much for your time on this!

[ZeeshanTamboli]

A) I couldn't find any official documentation, only discussions:

• 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.

• A similar request is discussed in the react-select repository Accessibility: no way to clear the selection with a keyboard JedWatson/react-select#4988.

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

Since there’s no official documentation (or none I could find), this might be worth considering.

B) You might be right—this could be an accessibility issue.

C) I can’t test on Mac, as I use Windows OS.

D) Again, there’s no official documentation, only prior discussions.

I’ll keep this issue open to address accessibility concerns.