`aria-selected="true"` on a listbox option not announced with Chrome/JAWS

[patrickhlauke]

Summary

1. Open https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-select-only/
2. Open the select-only combobox
3. Navigate through the options
4. Go to the option that is currently aria-selected="true" - visually indicated with a tick icon

Expected result

The fact that an option is selected should be announced.

Actual result

No indication is given that an option is selected

Video

Video recording of navigating through the combobox in Chrome using JAWS. Note how the option with the tick is not announced as being selected.

https://github.com/FreedomScientific/standards-support/assets/895831/3f240f79-5b14-4404-a567-76a0c73da3fa

For comparison, video of Firefox/JAWS, where the aria-selected="true"/ticked option is announced correctly

https://github.com/FreedomScientific/standards-support/assets/895831/4918b80c-bdbc-48c6-b081-2288ef05bde3

Example

https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-select-only/

Additional Information

Looking in Chrome Developer Tools' accessibility panel, it shows that Selected: true on the option that has aria-selected="true", so it seems this should be conveyed correctly in the accessibility API.

Note that the above works correctly in Firefox/JAWS.

JAWS version and build number

2023.2306.38

Operating System and version

Windows 11

Browser and version:

115.0.5790.110

[JAWS-test]

I can imagine that this is because JAWS assumes that the focused list entry is always automatically the selected list entry - then there is no need to output the status. This is the case for native selects - so I think the ARIA pattern is not implemented correctly.

[patrickhlauke]

it may assume all it wants, but the ARIA pattern is correct, since you can have multiselects where the whole idea is that no, what you're focused on is not necessarily what's actually selected.

if by "the ARIA pattern is not implemented correctly" you mean the APG pattern is wrong, I'd suggest filing an issue on the APG repo

also, as mentioned, Firefox/JAWS announces the pattern correctly.

[JAWS-test]

That is exactly the point: with multiselect, the output is done correctly by JAWS. Only with single select not, because it is not necessary there.

[JAWS-test]

https://www.w3.org/WAI/ARIA/apg/patterns/listbox/examples/listbox-scrollable: The supposedly correct output with JAWS+Firefox leads to the output of "selected" for each list entry, which can be confusing because one then assumes that all list entries are selected

[patrickhlauke]

The supposedly correct output with JAWS+Firefox leads to the output of "selected" for each list entry, which can be confusing because one then assumes that all list entries are selected

feel free to file a related bug here then

[JAWS-test]

I did it long time ago: https://github.com/w3c/aria/issues/1094

[JAWS-test]

Related: https://github.com/w3c/aria/issues/1661

[stevefaulkner]

@patrickhlauke can reproduce in chrome JAWS version and build number 2023.2307.37

Operating System and version Windows 10

Browser and version: 115.0.5790.171 (Official Build) (64-bit)

note: same behaviour observed in NVDA/Firefox

@BrettLewisVispero @ggordon-vispero any thoughts on this?

[jhausler1266]

Following for updates. We are noticing this as well with JAWS/Edge.

[stevefaulkner]

test case with native non multiple and APG code non multiple (select on enter)

NVDA does not announce selected on either native select or APG custom select

[patrickhlauke]

noting that in the native case, a user can't navigate through the non-selected options ... the act of navigating through them also immediately selects them. this is not the case in the ARIA-fied case, where a user can and will land on options that are either selected or not selected. so the situation is slightly different.

however, confirming that (from a brief check in Chrome/NVDA and even Firefox/NVDA), this may not be an AT-specific problem, nor a browser-specific problem either perhaps? unsure now where the fault lies, other than a general "this pattern/approach seems to be broken/not well supported"

[arodenbeck]

As a life long screen reader user, I am quite comfortable with JAWS and NVDA, in Chrome, not announcing the selected state, in a single select situation. When selection follows focus, we know that every option arrowed across is selected, and the added verbosity would be quite annoying, and very much is in the Firefox example with JAWS. If one holds down the CTRL key, causing multiselect functionality, the unselected state is announced. As this is a binary state, not hearing "not selected" implies "selected", and I would prefer things remain the same.

[patrickhlauke]

@arodenbeck

When selection follows focus, we know that every option arrowed across is selected

However, that's not what happens in https://www.w3.org/WAI/ARIA/apg/patterns/combobox/examples/combobox-select-only/ - and here visually there's a checkbox against the currently selected option, which is not voiced by screen readers, so unless you remember what the selected option was originally before you then open the combobox, you get no clue.

the added verbosity would be quite annoying, and very much is in the Firefox example with JAWS

So the one extra "selected" if says for "Boysenberry" in that case is ... too verbose for you?

[smhigley]

I think this may be a dupe of #440 from 2020 😅.

[patrickhlauke]

@smhigley so a spring chicken of an issue then...good stuff. maybe we can get this looked at before the decade ends

[BrettLewisVispero]

Here is the chromium issue for those who are interested. https://issues.chromium.org/issues/337904204