526703 - Screen readers announce ARIA list items, tree items, and listbox items as "not selected"

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Hans Hillen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b1) Gecko/20091029 Firefox/3.6b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b1) Gecko/20091029 Firefox/3.6b1

In FF 3.6, when an ARIA listitem, treeitem or listbox option element receives focus, the screen reader indicates it as "not selected". This is caused by FF3.6 now exposing the "selectable" MSAA state.

Reproducible: Always

Steps to Reproduce:
Use the attached test case. This page contains two samples, both showing an aria listbox with 3 items. The second item in each list is part of the tab order. Using NVDA or JAWS 11, move focus between those tabbable items. 
Actual Results:  
The screen reader indicates the tabbable item in the first list as "not selected". 


Expected Results:  
The screen reader does not say "not selected" for the first sample.

This issue occurs in FF3.6 beta because it exposes the "selectable" MSAA state (STATE__SYSTEM_SELECTABLE) for listitem, option and treeitem ARIA roles. This causes the screen reader to check for the "selected" state (STATE_SYSTEM_SELECTED), and if this is not set, it will announce the item as "not selected".

The issue can be solved by the developer by explicitly setting aria-selected="true" on the focused item. However, the ARIA specs state that aria-selected only needs to be used in two situations:

1. The widget supports multiple items to be selected (indicated by aria-multiselectable="true"). In this situation, aria-selected indicates whether the current item is part of the widget's selected items.
2. The widget only supports a single item to be selected, but does allow non-selected list items to receive focus. In this case, aria-selected is only used to specify "false" for non selected items, and omission of aria-selected on the focused item means that item is the selected one.

However, for single selectable widgets where the focused item is always the selected one, aria-selected does not need to be set explicitly (according to the ARIA specs). Instead, the focused item is automatically assumed to be selected. Also, it is an unnecessary hassle for the developer to have keep track on aria-selected values with focus and blur events in this case, as setting aria-selected doesn't add any meaning for such a widget.

So instead, Firefox should do the following for focused ARIA list items, listbox options, and tree items:

- If the widget supports multiple selection, expose the "selectable" state. Only expose the "selected" state if aria-selected has been set to "true" by the developer (this is the current behavior in 3.6 beta).
- If the widget only supports single selection, expose the "selectable" state, and automatically expose the "selected" state UNLESS aria-selected has been set to "false" by the developer. This way, the screen reader will stop announcing "not selected", without requiring unnecessary effort on the developer's side.

Comment 1

[Hans Hillen]

Attachment: Contains two basic samples that demonstrate this issue.

Comment 2

[alexander :surkov (:asurkov)]

Hans, thank you for very descriptive bug.

I have an opposite example is HTML select@size > 1, if you tab into it then list item is focused (it's called current item and has dotted border) but selected (blue background). What does screen reader say when you tab into HTML select?

Comment 3

[Marco Zehe (:MarcoZ)]

Hans, one additional question: What happens if you set aria-activedescendant to the ID of the currently focused item? I realise your testcase would need updating to get IDs. But I once learned (and we do have that in the test suite) that aria-activedescendant is used to indicate which is the focused/selected item in such constructs.

Comment 4

[Hans Hillen]

Attachment: Updated aria-selected testcase

Comment 5

[Hans Hillen]

I attached an updated version of the test case.

It contains two extra ARIA listboxes that use aria-activedecendant rather than tabindex to manage focus. It also contains two native HTMLlistboxes, one of which supports multiple selection.
Marco: The updated test case shows that using aria-activedescendant has no effect on this issue.

Surkov: Tabbing into a listbox (i.e. a <select> element that uses the "size" attribute, not a dropdown <select>) initially does not indicate a selected value. The dotted line around the first item only indicates focus, even though it is really the listbox itself, and not the item that is programmatically focused. JAWS will announce this 'focused' item as "not selected". NVDA does not announce the focused item at all when the listbox receives focus, only when you start navigating the actual list items. After actually selecting an item (indicated by the background color) that item will simply be announced by its label without the "not selected" announcement.

Comment 6

[David Bolter [:davidb] (NeedInfo me for attention)]

Marco, if possible I'd like a regression window.

Comment 7

[alexander :surkov (:asurkov)]

Ok. I think we can expose state selected on focused item of single selectable container if it helps ARIA widget developers. I don't mind. At least they can make ARIA widgets similar to HTML listbox by aria-selected="false" on focused item. And if this is more rare case then we can fix the bug on our side.

David, can you ensure it comes to ARIA implementation guide?

Comment 8

[alexander :surkov (:asurkov)]

Attachment: patch

Comment 9

[alexander :surkov (:asurkov)]

Comment on attachment 413516 [details] [diff] [review]
patch

unrequesting reviews until we come to unique opinion.

I think the idea of the bug is sugar in ARIA widget development which is might be nice. However I'm not ARIA widget developer so I can't estimate if this is really helpful. If most of ARIA single selectable controls has selected item always then it's worth to fix. If there are ARIA controls similar to HTML select (listbox) which allows focused but selected items and they are spread widely enough then we should drop this feature because the requirement to add aria-selected="false" in these cases might be found too implicit requirement.

I think we need to get more opinions from ARIA widget developers and ARIA impl guide group.

Comment 10

[alexander :surkov (:asurkov)]

Btw, I filed part of this patch as bug 530014.

Comment 11

[Michael Kohler [:mkohler]]

This is a mass change. Every comment has "assigned-to-new" in it.

I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.

Comment 12

[Marco Zehe (:MarcoZ)]

Do we want any action on this? I believe now, developers like the ones for Yahoo! Mail, rely on the fact that they have to set aria-selected explicitly to get consistent selected/unselected announcements.

Comment 13

[alexander :surkov (:asurkov)]

I'm not sure, I provided my opinion in comment #9. Hans, what do you think?

Comment 14

[James Teh [:Jamie]]

(In reply to Marco Zehe (:MarcoZ) from comment #12)
> I believe now, developers like the ones for
> Yahoo! Mail, rely on the fact that they have to set aria-selected explicitly
> to get consistent selected/unselected announcements.
That's only if they want something that is focused to be unselected; e.g. Yahoo! explicitly set aria-selected="false" on the focused tab if it isn't actually selected.

Comment 15

[alexander :surkov (:asurkov)]

Ok, I think we need it. Regardless original Hans report, Yahoo example there's third one http://oaa-accessibility.org/example/9/

Comment 16

[alexander :surkov (:asurkov)]

Attachment: patch

Comment 17

[Hans Hillen]

For what it's worth, Yes I still think it's important that this change is made. The current way is just making it unnecessarily  difficult for developer who want to create a basic widget like a listbox. It also causes existing widgets to break even though the developer did not do anything wrong. But most of all because it is explicitly mentioned in the spec. Quoting again: "The selection normally follows the focus, and is managed by the user agent. Authors need only explicitly specify aria-selected when the focused item is not selected. Otherwise the currently focused item is considered to be selected so aria-selected="true" is redundant."

Comment 18

[alexander :surkov (:asurkov)]

Thanks, Hans. Does it mean it should be applied to multiselectable containers too?

Comment 19

[Marco Zehe (:MarcoZ)]

Comment on attachment 577637 [details] [diff] [review]
patch

r=me, thanks!

Comment 20

[Hans Hillen]

Hi Surkov,

No, this bug only applies for the simplest situation where a widget only provides single selection (aria-multiselectable="false") and it is not possible to move focus to unselected items. 

So your check for 

!nsAccUtils::HasDefinedARIAToken(container->GetContent(), nsGkAtoms::aria_multiselectable) 

in your patch is correct.

Comment 21

[alexander :surkov (:asurkov)]

Thanks, Hans.

Comment 22

[alexander :surkov (:asurkov)]

inbound land https://hg.mozilla.org/integration/mozilla-inbound/rev/8c9477207cf6

Comment 23

[alexander :surkov (:asurkov)]

landed https://hg.mozilla.org/mozilla-central/rev/8c9477207cf6