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

RESOLVED FIXED in mozilla12

Status

()

Core
Disability Access APIs
RESOLVED FIXED
8 years ago
5 years ago

People

(Reporter: Hans Hillen, Assigned: surkov)

Tracking

(Blocks: 1 bug, {access})

Trunk
mozilla12
x86
Windows XP
access
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

8 years ago
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.
(Reporter)

Comment 1

8 years ago
Created attachment 410438 [details]
Contains two basic samples that demonstrate this issue.
(Reporter)

Updated

8 years ago
Component: General → Disability Access
Version: unspecified → 3.6 Branch
(Reporter)

Updated

8 years ago
Keywords: access
(Assignee)

Updated

8 years ago
Component: Disability Access → Disability Access APIs
Product: Firefox → Core
QA Contact: general → accessibility-apis
Version: 3.6 Branch → Trunk
(Assignee)

Comment 2

8 years ago
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

8 years ago
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.
(Reporter)

Comment 4

8 years ago
Created attachment 410670 [details]
Updated aria-selected testcase
(Reporter)

Comment 5

8 years ago
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.
Marco, if possible I'd like a regression window.
(Assignee)

Comment 7

8 years ago
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?
(Assignee)

Updated

8 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 8

8 years ago
Created attachment 413516 [details] [diff] [review]
patch
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #413516 - Flags: review?(marco.zehe)
Attachment #413516 - Flags: review?(bolterbugz)
(Assignee)

Comment 9

8 years ago
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.
Attachment #413516 - Flags: review?(marco.zehe)
Attachment #413516 - Flags: review?(bolterbugz)
(Assignee)

Comment 10

8 years ago
Btw, I filed part of this patch as bug 530014.
(Assignee)

Updated

8 years ago
Assignee: surkov.alexander → nobody
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.
Status: ASSIGNED → NEW
(Assignee)

Updated

6 years ago
Blocks: 343213
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.
(Assignee)

Comment 13

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

Comment 14

6 years ago
(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.
(Assignee)

Comment 15

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

Comment 16

6 years ago
Created attachment 577637 [details] [diff] [review]
patch
Assignee: nobody → surkov.alexander
Attachment #413516 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #577637 - Flags: review?(marco.zehe)
(Reporter)

Comment 17

6 years ago
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."
(Assignee)

Comment 18

6 years ago
Thanks, Hans. Does it mean it should be applied to multiselectable containers too?
Comment on attachment 577637 [details] [diff] [review]
patch

r=me, thanks!
Attachment #577637 - Flags: review?(marco.zehe) → review+
(Reporter)

Comment 20

6 years ago
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.
(Assignee)

Comment 21

6 years ago
Thanks, Hans.
(Assignee)

Comment 22

5 years ago
inbound land https://hg.mozilla.org/integration/mozilla-inbound/rev/8c9477207cf6
(Assignee)

Comment 23

5 years ago
landed https://hg.mozilla.org/mozilla-central/rev/8c9477207cf6
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla12
You need to log in before you can comment on or make changes to this bug.