Last Comment Bug 526703 - Screen readers announce ARIA list items, tree items, and listbox items as "not selected"
: Screen readers announce ARIA list items, tree items, and listbox items as "no...
: access
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: x86 Windows XP
-- normal (vote)
: mozilla12
Assigned To: alexander :surkov
: alexander :surkov
Depends on:
Blocks: aria
  Show dependency treegraph
Reported: 2009-11-04 20:46 PST by Hans Hillen
Modified: 2012-01-22 09:16 PST (History)
5 users (show)
surkov.alexander: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Contains two basic samples that demonstrate this issue. (1.01 KB, text/html)
2009-11-04 20:47 PST, Hans Hillen
no flags Details
Updated aria-selected testcase (2.80 KB, text/html)
2009-11-05 16:41 PST, Hans Hillen
no flags Details
patch (25.99 KB, patch)
2009-11-19 20:48 PST, alexander :surkov
no flags Details | Diff | Splinter Review
patch (11.10 KB, patch)
2011-11-29 08:43 PST, alexander :surkov
mzehe: review+
Details | Diff | Splinter Review

Description User image Hans Hillen 2009-11-04 20:46:22 PST
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 User image Hans Hillen 2009-11-04 20:47:27 PST
Created attachment 410438 [details]
Contains two basic samples that demonstrate this issue.
Comment 2 User image alexander :surkov 2009-11-04 23:38:07 PST
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 User image Marco Zehe (:MarcoZ) 2009-11-05 00:47:03 PST
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 User image Hans Hillen 2009-11-05 16:41:36 PST
Created attachment 410670 [details]
Updated aria-selected testcase
Comment 5 User image Hans Hillen 2009-11-05 17:01:27 PST
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 User image David Bolter [:davidb] 2009-11-05 17:21:27 PST
Marco, if possible I'd like a regression window.
Comment 7 User image alexander :surkov 2009-11-19 02:58:41 PST
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 User image alexander :surkov 2009-11-19 20:48:29 PST
Created attachment 413516 [details] [diff] [review]
Comment 9 User image alexander :surkov 2009-11-19 22:40:30 PST
Comment on attachment 413516 [details] [diff] [review]

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 User image alexander :surkov 2009-11-19 23:05:12 PST
Btw, I filed part of this patch as bug 530014.
Comment 11 User image Michael Kohler [:mkohler] 2010-05-13 10:11:47 PDT
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 User image Marco Zehe (:MarcoZ) 2011-11-01 16:40:02 PDT
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 User image alexander :surkov 2011-11-01 16:44:52 PDT
I'm not sure, I provided my opinion in comment #9. Hans, what do you think?
Comment 14 User image James Teh [:Jamie] 2011-11-01 17:40:26 PDT
(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 User image alexander :surkov 2011-11-29 08:42:10 PST
Ok, I think we need it. Regardless original Hans report, Yahoo example there's third one
Comment 16 User image alexander :surkov 2011-11-29 08:43:18 PST
Created attachment 577637 [details] [diff] [review]
Comment 17 User image Hans Hillen 2011-11-29 09:02:41 PST
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 User image alexander :surkov 2011-11-29 09:07:21 PST
Thanks, Hans. Does it mean it should be applied to multiselectable containers too?
Comment 19 User image Marco Zehe (:MarcoZ) 2011-11-29 09:07:49 PST
Comment on attachment 577637 [details] [diff] [review]

r=me, thanks!
Comment 20 User image Hans Hillen 2011-11-30 03:42:56 PST
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 User image alexander :surkov 2011-11-30 04:28:52 PST
Thanks, Hans.
Comment 22 User image alexander :surkov 2012-01-21 03:04:35 PST
inbound land
Comment 23 User image alexander :surkov 2012-01-22 09:16:21 PST

Note You need to log in before you can comment on or make changes to this bug.