Combobox Accessibility

[cogwizzle]

Description

When I inspect the HTML of the combobox output I expect to see:

• An input with the role of select (or maybe button?).
• A role of none when using autocomplete behavior. (datalist is not native behavior).
  Instead I see:
• A duplicated aria-labeledby aria attribute that should already be handled by the real label component.
• A role of "autocomplete" regardless if the combobox can be typed into.

Link to Reproduction

https://paste.twilio.design/components/combobox

Steps to reproduce

1. Go to 'https://paste.twilio.design/components/combobox#basic-combobox'
2. Inspect Element.
3. Go to 'https://paste.twilio.design/components/combobox#autocomplete-combobox'
4. Inspect Element.

Paste Core Version

latest

Browser

Google Chrome 123.0.6312.124

Operating System

• macOS
• Windows
• Linux

Additional Information

If we build these non native components that replicate native elements we need to ensure that we make it accessible to how users normally interact with these components.

[dosubot]

To address the accessibility concerns you've raised with the combobox component:

1. aria-labelledby Duplication: The component should ensure each combobox has a unique aria-labelledby attribute that matches the ID of its corresponding label. This requires generating unique IDs for each combobox and label pair to avoid duplication and ensure proper association for assistive technologies.

2. Role of "autocomplete": The role should accurately reflect the combobox's capabilities. If the combobox supports typing and filtering options (autocomplete), the implementation should be clear in enabling this functionality only when appropriate. For comboboxes that do not support typing, the autocomplete attribute should not imply otherwise. This distinction is crucial for user expectations and the accessibility of the component.

3. Improvements and Testing: It's important to focus on accurately mimicking native HTML select element interactions, including keyboard navigation and selection behavior. Utilizing accessibility testing tools like axe-core or Lighthouse, and conducting manual testing with screen readers, can help identify and resolve any accessibility issues, ensuring the component meets WCAG guidelines and ARIA authoring practices.

These steps aim to enhance the combobox component's accessibility, ensuring it provides a consistent and accessible experience for all users.

Sources

• packages/paste-core/components/combobox/tests/Combobox.spec.tsx

About Dosu

This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

If you want to continue the conversation, start your reply with @dosu-bot.

[TheSisb]

Hi @cogwizzle,

I just finished answering another one of your opened issues about Alert Dialogs. Allow me to extend my response there into this thread.

Comboboxes are especially complicated UI elements to make accessible. I don't recall why every decision was made the way it was. Instead I ask if you've found your accessibility software to parse the output from our component incorrectly?

Making changes based on what the code or markup should look like doesn't always lead to perfectly accessible user interfaces, to my chagrin. I see your keen interest in accessibility and just ask that you provide more information on how this breaks. Thanks!

[cogwizzle]

I see your keen interest in accessibility and just ask that you provide more information on how this breaks.

I'm just a guy with an inspect button. 😅 So first let's talk about the HTML that is rendered.

<div data-paste-element="BOX" data-paste-core-version="20.11.0" role="combobox" aria-haspopup="listbox" aria-owns="downshift-204-menu" aria-expanded="false" class="next-1vxmk41">
    <input data-paste-element="COMBOBOX_ELEMENT" data-paste-core-version="20.11.0" readonly="" type="text" id="downshift-204-input" tabindex="0" aria-autocomplete="list" aria-controls="downshift-204-menu" aria-labelledby="downshift-204-label" autocomplete="off" required="" class="next-14y35q4" value="Octavia Butler">
    <div data-paste-element="COMBOBOX_CHEVRON_WRAPPER" data-paste-core-version="20.11.0" class="next-pqor4o">
        .
        <span data-paste-element="ICON" data-paste-core-version="20.11.0" class="next-ggo522">
            <svg role="img" aria-hidden="true" xmlns="http://www.w3.org/2000/svg" width="100%" height="100%" viewBox="0 0 20 20" aria-labelledby="ChevronDownIcon-:ra7:"><path fill="currentColor" fill-rule="evenodd" d="M6.293 8.293a1 1 0 011.32-.083l.094.083L10 10.585l2.293-2.292a1 1 0 011.32-.083l.094.083a1 1 0 01.083 1.32l-.083.094-3 3a1 1 0 01-1.32.083l-.094-.083-3-3a1 1 0 010-1.414z"></path></svg>
        </span>
    </div>
</div>

This is the output of the basic Combobox on the documentation pages. As you can see we have aria-autocomplete="list" on the input inside of the wrapping div. This control creates the illusion that a user can type in order to select a value. I think I used the term "role" in the description however it is not a role, but rather a subset of other aria properties.

Aria's autocomplete list seems to be the right aria property to have if the autocomplete property is enabled on the Combobox react component.

My understanding of the "autocomplete" attribute value being off on the real rendered input is referring to the built in browser functionality which is why it is also off with the typeahead version.

My concern specifically lies in the fact that the user clicks or tabs to the input in order to focus and blur to toggle the state of the dropdown options.

I think it is happening in this file, but here is a picture that shows why I believe this.

As you can see the picture shows a blur and click event.

So based on this behavior when a user with vision impairment selects that element they're going to be conditioned to think autocomplete means I can type when it doesn't mean that all of the time with this component. It might be better if instead of using an input we use a button since you can't actually type in it. Or we change the type from combobox to select when autocomplete is not enabled. Or a mix of all of the above.

I should also note that this was a proactive browsing of Paste I made after noticing the spacebar didn't work on the combobox. That is why you're seeing so many issues from me today. There are no reports of this causing an issue, just me noticing it might cause an issue.

[TheSisb]

Just dropping a note here, we spoke about this during office hours (for any other readers who swing by). One thing every accessibility engineer will tell you is that you can't always trust "what should be right" to actually be the best user experience. There are many examples of the browser defaults being worse than custom solutions implemented in JS, and more of, what should be, intuitive solutions (such as icon labelling) which do not work properly across all screen reader software. Nothing can replace actual testing on NVDA, Jaws, and VoiceOver.
I want to trust that the previous work done on this component was thoughtful and accurate, and in that spirit do not want to rush a fix that can break other things. Hence, I'm leaving this open until we manage to allocate time to test this with screen reader software.