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.