JAWS does not announce the selected values, and it breaks the keyboard navigation.

UdhayaKumarDuraisamy commented 6 months ago

Summary

I have a custom MultiSelect component built using JavaScript. When selecting values from the component popup, the JAWS screen reader does not announce the selected values. Additionally, after selecting values, the keyboard navigation does not work properly. The keyboard navigation only breaks when using JAWS.

I have tried adding 'aria-activedescendant', 'aria-describedby', and 'aria-labelledby', but none of these resolved the issue.

Sample: https://stackblitz.com/edit/2tmhcn?file=index.js

Steps to reproduce:

Run the sample mentioned above.
Focus on the component using Tab key navigation.
Press the "Alt + Down Arrow" keys to open the popup.
Use the Down/Up arrows to navigate through the list items in the popup.
Select a value by pressing the space key.
After selecting a value, try to move any other list item in the popup.

Expected result

The JAWS does not announce the selected values properly, and the keyboard navigations are not working properly.

Actual result

While selecting/deselecting any values the JAWS should announce it and After that keyboard navigation needs to work properly.

Example

Sample: https://stackblitz.com/edit/2tmhcn?file=index.js

Additional Information

JAWS version and build number

JAWS 2024.2310.70 - October 2023

Operating System and version

Edition : Windows 11 Enterprise Version : 22H2

Browser and version:

Google Chrome & Version 120.0.6099.71 (Official Build) (64-bit)

JasonAment commented 6 months ago

BTW - I am not a Freedom Scientific employee

This doesn't really work for any screen reader (I checked iOS/Voiceover, NVDA, Narrator as well). I feel compelled to mention that Comboboxes are generally considered a bad pattern for accessibility (at the moment). Even the WAI notes that there are major issues with browser and AT support. The WAI cannot produce a code example that works in production environments (see note)... yet.

For all screen readers (and some) keyboard only users:

Keyboard navigation issues occur with or without a screen reader active. Sometimes the focus can get "stuck" on the "select all"/"unselect all" option even though the user is arrowing down the list. When they select a single item from the list, then all the items will get selected/deselected. (See attached video)
The initial combobox (there are two?) announces as readonly. This is not an editable state, so how would a user know that down arrow or alt+down arrow would even be an option.
When the focus is "stuck" on "(un)select all", if a state is selected, then the focus is reset to the top of the list. so if a user wants to select/deselect multiple items, they are basically in a keyboard trap of "unselecting/selecting all" at that point. (see attached video) It appears that if focus is ever on the select/unselect all option after it's been selected, then it returns to the "(un)select all" option, which is then activated again no matter what element in the list has focus after that point. The only way to deselect the "(un)select all" option is to arrow down the list, then arrow back up. Arrowing back up the list appears to be the only way to get a workaround.
"Select all" on VoiceOver/iOS moves the focus out of the control. In my case, it set the focus to a light blue sign up modal, but I would imagine this would just be sending focus to the first element on the page. Something to check.

https://github.com/FreedomScientific/standards-support/assets/16707962/629a005c-02ff-4689-a42f-b844e1606a71

JasonAment commented 6 months ago

Here is a sample of the iOS bugs with navigation.

The focus order bug mentioned in my other comment.
When all are selected, the “unselect all” does not announce unless you select/deselect an option below.
when the focus order bug occurs note that the the currently focused item in the list is still highlighted (canada in the video). I’m willing to bet there’s a scenario where I could activate it without focus in that state.

https://github.com/FreedomScientific/standards-support/assets/16707962/32a5bcb0-661d-4fe7-bcf1-5d2a1086a45b

JAWS-test commented 6 months ago

I feel compelled to mention that Comboboxes are generally considered a bad pattern for accessibility (at the moment).

That may be, but this is about a specific problem of combobox with JAWS. It has to be said:

combobox works well with JAWS, as long as the combobox is implemented correctly
there are many frameworks with incorrect combobox patterns. The W3C with its ARIA specification, which has massively changed the rules regarding combobox twice from ARIA 1.0 to 1.1 to 1.2, is somewhat to blame for this.
The example mentioned here has worked quite well for me with JAWS and Chrome, although it is partly implemented incorrectly (e.g. unselected options are in a listbox and selected ones are not in a listbox, so that JAWS announces that it is entering and leaving a selection list). I have not been able to reproduce the errors described in the issue or have not understood them.

JAWS-test commented 6 months ago

Even the WAI notes that there are major issues with browser and AT support

The warning is on the page for every pattern, even for something as simple as role=button. This warning does not speak against the correct use of combobox

FreedomScientific / standards-support