A possible plan to improve v2 accessibility and make it ARIA compliant

[afercia]

Sorry to open a so broader issue, it's meant more for initial discussion and can be closed at any time, no problem :)

Pretty excited to see al the new features coming in V2, especially the ability to use custom components. Very interesting architectural direction.

On the other hand, accessibility is very important to me and for the team I work with, where we're evaluating the adoption of react-select. FWIW I'm also collaborating with the WordPress accessibility team, where in the past we've done extensive research and testing about similar (non-react) tools, namely Select2, in the hope to find one with a high level of accessibility and to try to help improving it.

After some initial testing and digging into V2, I've noticed there's room for accessibility improvements and I'd be happy to help. I'd tend to think the best option would be sticking to the latest recommended practices and trying to implement an ARIA "Combobox" as defined in the ARIA authoring practices. Please notice the implementation in ARIA 1.1 has changed and it's a bit different from the one used in ARIA 1.0, Some references:

WAI-ARIA Authoring Practices 1.1
https://www.w3.org/TR/wai-aria-practices/

Combobox:
https://www.w3.org/TR/wai-aria-practices/#combobox

NOTE:
The options for a combobox to popup a grid, tree, or dialog were introduced in ARIA 1.1. Changes made in the ARIA 1.1 specification also add support for a code pattern that enables assistive technologies to present the textbox and popup as separately perceivable elements. both ARIA 1.0 and 1.1 patterns are described in the following sections. While using the ARIA 1.1 pattern is recommended as soon as assistive technology support is sufficient, there are no plans to deprecate the ARIA 1.0 pattern.

See also one of their example, please notice the differences in the markup:

Examples of ARIA 1.1 Combobox with Listbox Popup:
https://www.w3.org/TR/wai-aria-practices/examples/combobox/aria1.1pattern/listbox-combo.html

I understand this would require some good refactoring, so I'd kindly ask if there's interest and availability in collaborating to improve accessibility before opening specific issues and submitting PRs :)

Worth noting that even fully implementing the pattern described in the ARIA Authoring Practices wouldn't solve all the accessibility issues. Thinking for example at the selected values and the "tags" as you've also pointed out in the readme accessibility notes.

Thanks very much for reading this, any feedback would be greatly appreciated :)

[afercia]

One of the main, initial, accessibility issues, is that Safari + VoiceOver don't announce the "focused" option when using the arrow keys on the dropdown listbox. Instead, they always announce the "selected" option:

I've tested the current v2 master and, as far as I see, aria-owns and aria-activedescendant are used correctly. On all the combobox implementations I've tested so far, this makes other screen readers like NVDA and JAWS announce the "focused" options correctly.

However, Safari (I'm using 11.1 at the moment) and VoiceOver need also aria-selected set to true on the "focused" option. This is a somehow "gray area" in the specification but you can just test it 🙂

Regardless of what isSelected and isFocused do internally, the HTML attribute aria-selected needs to be set to true to make Safari + VoiceOver happy.

Worth noting that even when aria-selected is used ad described above, sometimes VoiceOver announces the wrong option. This is something noticed on several similar combobox implementations, for example even on the Twitter search or in WordPress (see https://core.trac.wordpress.org/ticket/38637 )

Also the ARIA 1.0 example from the W3C ARIA authoring practices doesn't work 100% corretly with VoiceOver and soemtimes the wrong option is announced, see https://www.w3.org/TR/wai-aria-practices/examples/combobox/aria1.0pattern/combobox-autocomplete-list.html

Instead, in ARIA 1.1 something has changed, seems to me the new example works better: https://www.w3.org/TR/wai-aria-practices/examples/combobox/aria1.1pattern/listbox-combo.html

For more details about what is changed in ARIA 1.1 see https://www.w3.org/TR/wai-aria-practices/#combobox

NOTE
The options for a combobox to popup a grid, tree, or dialog were introduced in ARIA 1.1. Changes made in the ARIA 1.1 specification also add support for a code pattern that enables assistive technologies to present the textbox and popup as separately perceivable elements. both ARIA 1.0 and 1.1 patterns are described in the following sections. While using the ARIA 1.1 pattern is recommended as soon as assistive technology support is sufficient, there are no plans to deprecate the ARIA 1.0 pattern.

[nottoseethesun]

The "axe" tool, run from the handy "axe" Chrome Browser Extension reports two critical accessibility errors on the ReactSelect elements on the react-select homepage (screenshots below):

• Certain ARIA roles must be contained by particular parents info
• ARIA attributes must conform to valid values info

These don't look too hard to fix. They also cause a lower score on Chrome Lighthouse in the Accessibility Category for any app that uses react-select.

[afercia]

error 1:
aria-owns should always have a value; insead, it's initially empty and gets populated only when the listbox opens

error 2:
when the selected option appears in the select-replacement, it still uses a role="option":
<span class="Select-value-label" role="option" aria-selected="true" id="react-select-2--value-item">New South Wales</span>

which at that point shouldn't be there

However, these are not the only errors. For example, the usage of aria-selected="true" is not conforming. A quick comparison with the ARIA Authoring Practices examples linked above can give further details on what's needed to be fully accessible.

[wszgxa]

I find in version 2, the role=combobox, aria-own have been removed.

And in version 1, aria-own is empty. And it doesn't have a child role="textbox".

I don't know if that is correct. For now, we are going to upgrade to v2. Because it will not throw error in the lighthouse, So the score will be higher... 😢

[morgs32]

@afercia you seem to have a good grip of accessibility concerns here. I'm wondering why these three icons buttons don't have any aria/role/tabIndex props:

• ClearIndicator
• The "x" to clear an item in multiselects
• The down chevron for the dropdown

I see the authors went so far as to add focusable=false to the svgs which is impressive/thoughtful (assuming it was done deliberately). Wondering if there's good reason that these icon/buttons listed above don't have these accessibility attributes.

[afercia]

@morgs32 right, seems the authors intentionally implemented those 3 controls as mouse / touch only. They're not usable with a keyboard to start with. They could be real buttons instead of div with ARIA roles / attributes.

focusable=false is pretty standard for SVG icons to workaround a bug in IE 11.

[seancurtis]

I can comment a little on these decisions. Not everything that is available to a mouse needs to be also available to the keyboard, however everything achievable with the mouse needs to also be achievable with the keyboard. The clear indicator would have meant tabbing through a form would be twice as long, and the user can achieve the same outcome just using the keyboard (backspace/select all + delete).

The "x" for selected values with multiselects can likewise be done by hitting "delete" when pseudo-focus (pressing left to highlight the selected values) is on them.

The "down" chevron is a visual affordance for mouse users to click on, and has the same effect as pressing the down arrow key.

[seancurtis]

We did try using aria, but support for comboboxes is atrocious at present. We backtracked after getting about half way through implementing it and opted to use Live Regions instead. They provide much finer grained control, at the cost of needing to expose strings in props in order to handle internationalisation of the text prompts that are read to screen readers.

It would have been awesome to use aria, but there were so many holes that we just couldn't do it. You'll notice a similar approach found in Downshift and many other highly interactive components (eg drag and drop libraries).

[morgs32]

@seancurtis thanks a lot for that background. Live Regions are a mystery to me. I'll read what I find on MDN but if you know of any other helpful resources on this subject I'd love to know about them.

[slafleche]

I would prefer to see an aria implementation than nothing at all. It is the spec and better compatibility with screen readers and/or browsers could be added later on.

[attilavago]

Any updates on this? It's virtually the only missing piece of the puzzle.

[hinterlandcreative]

Any updates on this?

[cabillin]

Chiming in on the conversation:

My team is currently using react-select extensively. It's the only option we've found that supports all the features we want and also provides a nice user experience. Thank you for this awesome control!

However, our company's internal accessibility review has flagged several a11y bugs (some of those are highlighted above or are filed as separate bugs on this repo, but some don't seem to be filed yet). We will not be able to continue using react-select if these issues are not fixed. We REALLY want to keep using this control.

I agree with @slafleche that aria implementation is preferred. I understand that it was probably a headache to try to get combobox etc. to work, but aria live regions are not intended as a way to replace/produce expected screen reader output. Also, the way the control is currently implemented with live regions is the root cause for a lot of the existing a11y issues (e.g. #1585 & #3356).

Would the contributor team (e.g. @JedWatson @seancurtis @ebonow) be open to moving away from aria live regions? I see some work that seems to further bake live regions into the implementation (e.g. #4414), but I also see other work to move towards aria attributes (e.g. #4322).

I have limited time right now, but I can be available the whole day (PST business hours) October 12-14 to work on these improvements (as part of my company's designated time for such work). I have ~4 years of experience in React + typescript. I also have access to Narrator, NVDA, & JAWS for testing.

[avanrider]

Has anyone found a solution to getting screen readers + arrow keys functional?
I've tried custom components, aria live, etc...but nothing seems to change the screen readers description as I arrow through the options. Still "Blank"+CHANGED TEXT GIBBERISH+Index Number. This results in a non-usable component.

[ebonow]

I wanted to stop in to ensure that those here are aware of the changes that have been made for accessibility purposes as a part of the version 5.0 release.

#4634 - The readonly attribute has been removed from the DummyInput to improve accessibility

#4697 - Add the role of combobox and the required ARIA attributes to the Input and DummyInput components to allow JAWS support and a better screen reader experience overall.

#4676 - The following improvements have been made for screen reader users:

• NVDA now announces the context text when initially focused
• Selected option/s (single and multi) are now announced when initially focused
• VoiceOver now announces the context text when re-focusing
• The clear action is now announced
• Placeholder text is now announced
• Mobile VoiceOver is now able to remove selected multi options

Meanwhile there was an implementation of aria-live massages templating created earlier that exposes the templating for customized messages. We still lack documentation on that api, and will need to discuss how this fits in with the current or new documentation that's been being worked on. The aria-live prop was also exposed to make it easier for users to disable this behavior entirely.

Regarding a path forward, I appreciate the suggestions and support. Now that version 5 has been released and we have a fresh TypeScript implementation in place, we will begin to sift through the existing issues and PR's regarding accessibility to gauge what's still relevant and what's still missing.

As a call to action, if someone would like to browse the existing issues for anything related to accessibility and create a new discussion similar to what was done here for menu bugs, it would allow us to at a glance better identify what's still left.

Thanks again all for your patience.

[dgreene1]

Based on @ebonow's message, should we close this issue in favor of individual accessibility issues that can be worked off one-by-one?