Bug 244093 - AX: option elements are not spoken to VoiceOver during arrow key selection when combobox not created from a button or input element
Summary: AX: option elements are not spoken to VoiceOver during arrow key selection wh...
Status: RESOLVED DUPLICATE of bug 272565
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: Safari 15
Hardware: Mac (Apple Silicon) macOS 12
: P1 Blocker
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2022-08-18 09:38 PDT by Paul J. Adam
Modified: 2024-06-10 08:09 PDT (History)
6 users (show)

See Also:


Attachments
screenshot of VoiceOver not speaking the selected option element (156.47 KB, image/png)
2022-08-18 09:38 PDT, Paul J. Adam
no flags Details
screenshot of VoiceOver speaking the option element correctly when the combobox is coded from an input (170.28 KB, image/png)
2022-08-18 09:39 PDT, Paul J. Adam
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paul J. Adam 2022-08-18 09:38:13 PDT
Created attachment 461711 [details]
screenshot of VoiceOver not speaking the selected option element

When VoiceOver in Safari on macOS is used to choose an option from an ARIA combobox control the options are not spoken as the user moves between options using the arrow keys when the combobox is coded as a non-button or non-input element. 

i.e. VoiceOver does not speak the options in this W3C ARIA combobox example https://w3c.github.io/aria-practices/examples/combobox/combobox-select-only.html

BUT VoiceOver does speak the options in this W3C ARIA combobox example https://w3c.github.io/aria-practices/examples/combobox/combobox-autocomplete-both.html

The reason VoiceOver works in the second example is because the role=combobox element is created from a natively focusable <input> element rather than from a static, non-interactive <div>. The tabindex=0 on the <div> does not make it work with VoiceOver in Safari. 

FYI Chrome does not have this same bug. 


Steps to Reproduce:
1. Turn on VoiceOver and open Safari on macOS
2. Visit https://w3c.github.io/aria-practices/examples/combobox/combobox-select-only.html
3. Set focus to the example combobox control.
4. Activate down and up arrow keys to move focus between the expanded option elements.

Expected Results:
VoiceOver speaks the name of each option element after pressing the arrow key to move focus to that option.

Actual Results:
VoiceOver speaks nothing after pressing the arrow key to move focus to an option.
Comment 1 Radar WebKit Bug Importer 2022-08-18 09:38:26 PDT
<rdar://problem/98836326>
Comment 2 Paul J. Adam 2022-08-18 09:39:09 PDT
Created attachment 461712 [details]
screenshot of VoiceOver speaking the option element correctly when the combobox is coded from an input
Comment 3 Patrick H. Lauke 2024-03-09 02:31:18 PST
I just recently hit on this bug again as well. Trying the (now relocated) https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-select-only/ pattern, it remains completely silent in Safari/VoiceOver. It does work as expected in Chrome/VoiceOver and Firefox/VoiceOver.

I've also been experiencing this bug with an actual <input> that then uses activedescendant (but does NOT automatically change the value of the <input> when moving the cursor through the combobox autocomplete list of options). I suspect this may actually be a more fundamental problem with activedescendant not working (and for the other combobox examples in the APG that do work, it only works because the currently focused <input>'s value is dynamically changed).
Comment 4 Daniel Adams 2024-06-09 23:38:12 PDT
During recent testing with assistive technology at GitHub, we've run into what appears to be the same problem here. When items in a listbox are navigated programmatically with aria-activedescendant referenced, the changes are not announced by VoiceOver in Safari on macOS.

Here's a simplified combobox example that illustrates the problem when used with Safari and VoiceOver: https://codepen.io/dipree/pen/WNBOJgd

Navigating the list of items programmatically without shifting actual focus is a common pattern widely used across many web pages. Please consider fixing this issue.

Note: The same problem is also described in this bug report https://bugs.webkit.org/show_bug.cgi?id=209076 but it's only classified as P2, however, it is a blocking bug.
Comment 5 Andres Gonzalez 2024-06-10 08:07:19 PDT

*** This bug has been marked as a duplicate of bug 272565 ***
Comment 6 Andres Gonzalez 2024-06-10 08:09:39 PDT
This problem also requires changes in VoiceOver. I will update this record when a public build of VoiceOver containing the fix is available.