[Webkit-unassigned] [Bug 209076] New: aria-selected options in listboxes not properly announced

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Mar 13 13:59:19 PDT 2020


            Bug ID: 209076
           Summary: aria-selected options in listboxes not properly
           Product: WebKit
           Version: Safari 13
          Hardware: Macintosh
                OS: macOS 10.15
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Accessibility
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: greg at transientmonkey.com
                CC: webkit-bug-importer at group.apple.com

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:
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:

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.

You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200313/7aa79760/attachment-0001.htm>

More information about the webkit-unassigned mailing list