Keyboard accessibility fails when JAWS is ON

[jja-financial-com]

Hi,
We are doing a accessibility testing on a widget that we developed containing a react select drop down. Using JAWS screen reader, the select is not usable via keyboard. Down arrow key opens the select but pressing enter while focusing on a new option will not change the value of the select.

Initially we thought this was due to some misconfiguration from our side, but testing on examples provided at react-select.com also produces the same incorrect result.

[asharron]

I also am seeing issues with Jaws on react-select.com and when using react-select.

I am currently looking into this as a client desperately wants to support Jaws.

If I find what the issue is, I will definitely post it here as an update.

[RTG-MColeman]

We are also seeing this behavior with VoiceOver on OSx as well as iOS. When screen readers are active they utilize the arrow keys for primary navigation. The issues that we are seeing is that the captured keydown event for down arrow is not being triggered properly and thus the reader will jump to the next focusable element.

Keyboard navigation is flawless when the reader is turned off.

[ebonow]

Greetings @jja-financial-com, @asharron , @RTG-MColeman ,

As part of the v4.2 release, there were some focused efforts put towards accessibility with two particular updates worth mentioning:

1. The DOM element with the aria-live attributes are rendered on component mount which should improve JAWS compatibility.
2. aria-live is exposed as a prop on react-select now for those who wish to customize the voice to assertive, passive, or off.

The decision for number two is a "use at your own discretion" for those who are familiar enough with the existing limitations of aria attributes and roles to address things such as "textbox is blank" and multiValue support.

There are still a number of issues left to address (many of which documented in the #4414) so it would be appreciated if you find the time to update and let us know if this issue can be closed to draw more attention to work that's still left to be done.

[vsorrentino]

I'm still seeing this issue as of version 4.3.1. With JAWS enabled, arrow functionality does not cycle through the options in the select, instead just highlighting the option's text, and pressing enter does not select the option. It is worth noting that Chrome Screen Reader and VoiceOver for OSX seem to be working as intended though, as is the case when JAWS is off.

[travisroth]

Hi,
What I observe is that the rendered component is being conveyed as a text input field. Therefore JAWS, and other screen readers, do not know that this is a combo box acting control. As such, when JAWS detects this is a single line edit field, and up/down arrow is pressed, it has a convenience feature for users to exit the field and keep moving through the page. (There is a way to change JAWS's behavior but this is out of scope for this issue as it really is an ARIA related issue that should be solved at the component level.)
For starters, role=combobx needs to be added as well as aria-haspopup=list.
I notice to much reliance on ARIA-Live regions being used as well. These should not be necessary. Please review the ARIA 1.1 best practices example for "ComboBox with Listbox Popup Examples" here: https://www.w3.org/TR/wai-aria-practices-1.1/examples/combobox/aria1.1pattern/listbox-combo.html .
Implementing this design pattern would be fantastic and solve a lot of the issues.
Thank you.

[ebonow]

Greetings @travisroth,

#4414 talks a lot about some of the TODO's left for aria-live support.

Regarding best practices using aria-attributes, yes, we are familiar with the examples and the original implementation of react-select had used those best practices, but the functionality was lacking due to several limitations. Some of these limitations off the top of memory include:

• Support for isMulti
• Support for reading selected values
• Support for isSearchable = false

react-select does not operate as a standard input control as the value is wiped onBlur by default in favor of showing a custom Value component. It's not to say that there aren't viable answers. This is to say that aria-live was implemented as a way to truly have a more customizable and accessible approach which is not as easily implemented relying on aria attributes.

One of the reasons the aria-live prop was exposed and added to the already 60+ props was so that users can choose to turn off aria-live if they choose to implement said functionality with custom components. sI've provided one such implementation suggestion here : #4322 (comment)

Before introducing these aria attributes as default behavior though, we want to responsibly ensure we have some testing around how it interacts/conflicts with aria-live. @seancurtis is the newest collaborator and has graciously taken on accessibility testing which was delayed by Emotion version conflicts.

Sorry if this was lengthy but a good amount of time has gone into looking at current issues and we know we still have a long way to go.

[travisroth]

Greetings @ebonow ,
Thank you for your informative reply. Accessibility is not always easy and ARIA has its nuances and bugs certainly. I appreciate your effort on it versus more often than I like to see just ignoring accessibility.
I read through the discussion about the early attempt at following ARIA design patterns. I have the following observations:
It appears the original implementation and testing was done in 2018. ARIA 1.1 was just released by the W3C WAI group around then and browsers and assistive technology were not really up to speed with it. The major browsers and screen readers JAWS and NVDA added a lot of this support in 2019. You were ahead of the curve and unfortunately it led to a lot of frustrations.
Also if I read it correctly it seems a lot of testing was done with VoiceOver and Safari on MacOS. If development is being done on Mac this is quite understandable. Unfortunately, Safari+VoiceOver does not lead the way when it comes to supporting ARIA. Some things work and some things do not. JAWS and NVDA are much better. Of course this does not solve the problem of trying to support all users. Sadly, Safari+VoiceOver MacOS users are frequently left behind but this is on Apple. (Accessibility is maintained better on iOS.)
I wanted to touch on what you mention you found to not be supported and give this a little update. I am not a React developer and I cannot test the new functionality that appears to be being worked on. I came across React-Select because a client we have is using it in a project so I started researching why it was behaving as it was with screen readers. (I do accessibility testing, not development.) Anyways, I looked at the W3C example for multiple selection which I assume is what you mean when you write "isMulti". Here are my test results:
Rearrangeable Listbox
https://www.w3.org/TR/wai-aria-practices-1.1/examples/listbox/listbox-rearrangeable.html
Using example 2 on this page demonstrating multiple select with aria-multiselectable=true:
Chrom 91 and JAWS 2021: Supports.
Firefox 89 and JAWS 2021: Supports.
Chrome 91 and NVDA 2020.4: Mostly supports. When the aria-multiselectable=true listbox is empty NVDA does not trap up and down arrows when the listbox is in focus. Not a showstopper.
Firefox 89 and NVDA 2020.4: Supports.
MacOS Big Sur (11) and VoiceOver: Does not support. VoiceOver can arrow through the choices, but pressing Space to select one results in selection behavior becoming erratic and expanding and collapsing depending on arrow key presses. User cannot tell what is selected or unselected. In addition, VoiceOver does not identify when buttons such as Remove are disabled.

If it would be possible to reinstate that early ARIA work and give it a test that may be a worthwhile thing to do to see how much more best practices and screen reader support you may have now. I don't want to discourage accessibility progress no matter how you choose to implement it. I hope this is helpful and encourages to not give up on the ARIA design patterns.

[ebonow]

@travisroth Thanks for the feedback. Without getting into the technical reasons of why and where the ARIA design patterns fail with regards to react-select, I'm afraid it will be difficult to properly have this discussion.

Perhaps my greatest frustration is WHY are so many against aria-live? It was developed with accessibility in mind to scale with the growing complexities and controls of modern web development. However, the criticism in many cases feels more about a11y compliance than it does a11y UX.

That all said, I provided a link to a code example demonstrating how to add ARIA attributes and there exists a prop to disable aria-live, so the only real thing preventing users from implementing this is themselves and our admittedly poor and under construction documentation.

If the attributes can be added, then why don't we just do it ourselves?

1. We know where it breaks
2. aria-live is more customizable
3. We don't know where/how these aria attributes conflict with the aria-live implementation
4. Testing requires multiple OS's, browsers, devices/VM's, etc... and lots of personal time

What's being done:

• To point # 4, @seancurtis is our new resident accessibility collaborator so please be nice to him :)
• To the other points, I'd like to release the aria components from the code example above as a group of components that can be imported in similar to animated components. Personally, I'd like to make component sets/composability its own library to be shared to support different sets of functionality, but that's another topic...
• We have at least 2 open PR's that have been patiently waiting feedback and that address a11y using aria attributes

[pleunv]

We received feedback that the MultiValue remove button is not keyboard accessible, which indeed appears to be the case. Since it can be highlighted and gives visual feedback when using the arrow keys you would expect it to behave like a button and respond to "Enter" and "Space" keys after which the corresponding item should be removed from the list, but this does not work. I'm not sure if this is what you are referencing with "Support for isMulti", @ebonow?

That said, I was wondering if this is an intentional choice, and, with the increased focus on accessibility, whether this is something that could be addressed and/or changed in the future?

[seancurtis]

@pleunv can you please try out the new react-select beta? We've drastically improved support in screen readers in this latest beta — it'd be great if you could try it out. I've created a simple codesandbox example using the latest beta: https://codesandbox.io/s/fervent-star-75spq?file=/src/App.js

[pleunv]

@seancurtis The codesandbox you linked has the same issue. One thing that seems to have changed is the addition of a role=button on the div, but none of the mandatory keyboard interactions are present. If anything, this change might have made it worse as AT will now announce it as a button while being completely non-functional.

[seancurtis]

@pleunv a standard keyboard user can clear them by pressing/holding delete/backspace, but we didn't want to make the close button focusable as that means every Select (if there's a value in it) now becomes 2 tab-stops in the UI. We added the role so that AT can access that clear all feature using the virtual cursor (Eg VO + Space would clear for VO).

This falls into the grey area for accessibility compliance for when there's an alternate manner to perform a task.

[flpehr0]

Hi all, super late to the discussion, but I was having Keyboard nav issues with JAWS turned on with react tabs and found this documentation that fixed the issue: https://docs.microfocus.com/doc/ESM/SaaS/ArrowkeynavigationIssueWithScreenReader

I don't know if this issue is the same as mine, but I have included it just incase this helps anyone else.

Description: When you are using JAWS 2024 in Edge or Chrome browser, if you use arrow keys for keybord navigation, the focus isn't shifting between different tabs...
Cause: This issue caused by the Virtual Cursor function in JAWS.
Solution: Switch off the Virtual Cursor function in JAWS by pressing INSERT+Z : JAWS has addressed this issue by introducing a toggle-off switch to disable the virtual cursor on chrome with the INSERT+Z command.

Hope this helps!