[Autocomplete] a11y issues: popup/clear buttons not keyboard accessible

[slayybelle]

Current behavior 😯

from demo example: https://mui.com/components/autocomplete/#combo-box

1. Using keyboard, tab into the input section and type 'The' and then down-arrow, enter (should select The Shawshank Redemption).
2. Input text says "The Shawshank Redemption" and cursor is at end of the title, now tab again
3. Exits the component

Expected behavior 🤔

from demo example: https://mui.com/components/autocomplete/#combo-box

1. Using keyboard, tab into the input section and type 'The' and then down-arrow, enter (should select The Shawshank Redemption).
2. Input text says "The Shawshank Redemption" and cursor is at end of the title, now tab again
3. Focus should now be on the "X" button (clearIndicator), now tab again...
4. Focus should now be on the "^" button (popupIndicator)

If a component (clear and popup indicators) are accessible by mouse, then they should also be accessible by keyboard.

Another thing, sometimes the X button disappears from the tab order. Rather than removing it, maybe you should just make it invisible until focused?

Context 🔦

I noticed this code in useAutocomplete.js which is hardcoding these two iconbuttons to have tab-index= -1:

Your environment 🌎

`npx @mui/envinfo`

  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

[mnajdova]

The autocomplete follows the WAI ARIA guildes, it indicates that:

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

Source: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/

There are keys that enable these actions, like Backspace, Down Arrow, etc.

Another thing, sometimes the X button disappears from the tab order. Rather than removing it, maybe you should just make it invisible until focused?

It is shown only on hover/focus, it is intended. And it should not be focusable, so this should be fine.

---

Could you maybe share some aria docs that supports the requirements you asked for. I must have missed something.

[slayybelle]

Thank you for the link. Damn, I'm sorry to have wasted your time on this one. I got feedback from a customer (rather than our auditors) and I just assumed they knew what they were talking about. Will definitely look at the doc first.

[oliviertassinari]

The autocomplete follows the WAI ARIA spec

@mnajdova Ah interesting, I didn't know the WAI ARIA had this content.

I fixed the terminology though, the ARIA Authoring Practices Guide is not a spec, we can do things differently.

Learn to use the accessibility semantics defined by the Accessible Rich Internet Application (ARIA) specification to create accessible web experiences. This guide describes how to apply accessibility semantics to common design patterns and widgets. It provides design patterns and functional examples complemented by in-depth guidance for fundamental practices.

https://www.w3.org/WAI/ARIA/apg/

I saw this question in the past too, I can't find this thread again, but I can share my thoughts here on why I designed it this way in the past:

• This button is meant for mouse users. It feels like keyboard users don't need the clear button, pressing the backspace buttons achieves the same outcome.
• Now, for keyboard users, making the clear button in the tab sequence / tabbable feels like it makes the experience worse for complex forms, it doesn't allow end-users to quickly/predictably Tab between inputs inside a form.