Bug 209076 – aria-selected options in listboxes not properly announced

• Status: NEW
• Component: Accessibility

[Greg Yingling]

I've found that using Safari + VoiceOver is practically unusable in most scenarios:

Scenario 1:
You can easily test this one one the ARIA Practices page: https://w3c.github.io/aria-practices/examples/listbox/listbox-grouped.html
It seems to navigate through the listbox twice, the first time it doesn't read any of the options, the second time, it reads the options, but you can't select any of them.

Scenario 2:
https://w3c.github.io/aria-practices/examples/listbox/listbox-rearrangeable.html
Example 1: Single-Select Listbox is actually somewhat functional, though I again had it appear to navigate through the options twice, but in this case, they're only selectable the first time. The point of repeat seems... inconsistent.

Example 2: Multi-Select Listbox is initial functional, on par with Example 1, until you select your first option. It then starts incorrectly reading "2 items selected" when you navigate to the next item, as if it's registering the "focused" item as a selected item, but it seems to sporadically decide if it even bothers to read that item. If you navigate 2+ items away, it might mention that the selection was replaced, and 2 items are still selected. Sometimes, when you refocus on the actually selected item, it may read out that the item you navigate from was removed, even though it was never selected. It's incredibly confusing.

Scenario 3:
https://pattern-library.dequelabs.com/components/selects

The previous scenarios all implemented the 'aria-activedescendant' method of "focusing" elements, this implementation changes the focused element. In the two provided examples, all of the options get read and navigate well, but there is no indication of which element is selected vs which are not. If the selection is following the focus, this isn't problematic, but in this use case, the selection does not follow focus. There is an icon associated with the selected element, but this isn't read by the screen reader.

[Radar WebKit Bug Importer]

<rdar://problem/60432552>

I am also struggling with Example 2, it seems that Safari + VO is combining aria-activedescendant (the item with focus) with any items having aria-selected="true" when it creates the list of selected items. Would love to see a fix or a recommendation for working around this bug.

[James Craig]

Also not working with this sample code demo from 2014:
https://webkit.org/blog-files/aria1.0/combobox_with_live_region_status.html

Type ahead a letter or two ("t") and use arrow keys to change the selection, but the current selection is not announced.

[James Craig]

Related to #167671. Possibly the same issue.
That one is being addressed in VO, not WK.

[James Craig]

(In reply to James Craig from comment #4)
> Related to #167671. 

Bug 167671

[James Nurthen]

You can find a bunch more examples following the ARIA 1.2 pattern at 
https://reactspectrum.blob.core.windows.net/reactspectrum/7dbfd5a0b144c2ee54cbd555ab6a02deb0f2b5ae/storybook/index.html?path=/story/combobox--static-items

Adding these in case more examples are needed.

I'd love to get an update to this to know whether we will need to implement ugly workarounds or if we can wait for a webkit fix. Note that the examples mostly work in Chrome w/ VO but not with Safari.

Codepen example: https://codepen.io/achint-singh/pen/rNKxVed

Codepen places code within an iframe. In this example, if you view this outside of an iframe (for example, in debug mode)--you will notice a similar issue to Scenario 3 mentioned. There is another bug where aria-activedescendant is broken in an iframe, so this example should be viewed outside of an iframe to view the issue.

Steps to reproduce:
1. Turn on VO in the example.
2. Click the button using enter key, and navigate through the list using the down arrow key.

Notice that once you go past the selected item, (in this case, Option C), the dropdown selector stops moving in sync with the VO focus ring. The VO focus ring remains on option C, while the dropdown selector keeps moving forward. If you keep pressing the down arrow to reach Option A, the VO focus ring and the dropdown selector will sync up again.

The expected behavior is that using the down arrow key should simultaneously move the VO focus ring as well as the dropdown selector and read the options.

----

Tested in: Monterey + Safari Technology Preview (16.4). 

This also does not work in Duck Duck Go + VO.

It works in Chrome + VO.

[Nick Williams]

This is still an issue even on Sonoma with Safari 17.2.1. The ARIA practices grouped listbox example is still a reproduction of the bug https://www.w3.org/WAI/ARIA/apg/patterns/listbox/examples/listbox-grouped/

This is a critical bug IMO. Without re-implementing all announcements in userland (difficult to get right and an unreasonable burden on devs), VO+Safari is completely unusable in these circumstances. It's a bug which affects devs and users alike, hence why i believe it is critical.

There may be a constellation of related bugs in Safari/VO causing this, but they overlap to such a degree they should be considered as one. The criteria for a fix should be "all ARIA APG combobox/listbox examples work as expected/intended"

[Kiya]

This is still an issue with Safari Version 17.5, MacOS: Sonoma Version 14.5

Reproducible at https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-select-only/ VoiceOver does not read the options in the listbox.
It works in other browsers (Chrome, Firefox).

+1 to what Nick Williams said; The criteria for a fix should be "all ARIA APG combobox/listbox examples work as expected/intended".

A fix for this would be really impactful for my company's design system and customers. Please!