433418 - Accessibles for focused HTML Select elements are not getting focused state

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[Michael Curran]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008051206 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008051206 Minefield/3.0pre

Combo boxes and lists, created in the accessibility hyerarchy representing HTML Select elements, do not get state_focused when they are focused. It is very important that if an Accessible object does have focus that it does have state_focused, as this makes things consistant. If some arn't going to have this state, then ATs can never depend on it nor use it in any useful way. It seems that quite a few different types of accessibles are missing their focused state these days. Documents it has been added back again, combo boxes and lists are missing them... there could be others. For lists at least, it could be said that the focused list item gets the focused state, so therefore the list doesn't need it. This is ok, as long as the list item actually is the one that gets the focus event, and not the list. But for all html examples I can see, including this bugzilla form, its the list that gets the focus event, and it doesn't have state_focused.  

Reproducible: Always

Steps to Reproduce:
1. Open the attached testcase in Firefox.
2. Open Accessibility Probe and watch for focus events on Firefox. Make sure to have the states column showing in the event list.
3. In firefox move focus to either the combo box or one of the lists, in the test case page.
4. In Accessibility probe look at the focus event generated by moving the focus to one of those nodes.
Actual Results:  
The object does not have state_focused.

Expected Results:  
The object should have state_focused.

Comment 1

[Michael Curran]

Attachment: A test web page that contains three HTML select elements. For accessibility, one is a combo box, and the other two are lists (one a single selectable and one a multi-selectable).

Using this web page in Firefox and focusing on one of the select elements shows that the accessible object for the node does not get state_focused.

Comment 2

[Marco Zehe (:MarcoZ)]

It was done on purpose to fix bug 391490. If an option is focused, the select itself should not get state focused. See http://mxr.mozilla.org/mozilla/source/accessible/src/html/nsHTMLSelectAccessible.cpp#338.

Mick, please check to see if you always get a focused state on the selected item. If not, then we indeed have a bug, otherwise it's as designed.

Comment 3

[James Teh [:Jamie]]

There is indeed a focused state on the active item when the list is expanded. However, in the case of a collapsed combo box, the focus event is fired on the combo box, not the list beneath it. At this point, the combo box should have state focused.

Also, in the case of lists, the focus event is fired on the list, not the active item. If the focused state is going to be set on the list item and not the list, the focus event really should be fired on the list item. That is, the focused state should be set on the object for which a focus event was fired.

In NVDA, we use the focused state to ensure the accuracy of a focus event, as incorrect focus events are far too often fired. We currently have a specific exception for Mozilla combo boxes and lists due to the issue described here. Thus, this issue is not of major importance. However, it is an inconsistent implementation detail and should therefore be considered.

Comment 4

[Marco Zehe (:MarcoZ)]

Making sure this stays on the radar for after Firefox 3.0 ships.

Comment 5

[James Teh [:Jamie]]

Ping!

The combo box/list fails to get the focused state even when there are no items in it. This is also true for tables and trees, which is particularly annoying in Thunderbird when the message list contains no items. We can keep adding exceptions for this in NVDA, but this really is a bit broken.

Comment 6

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

Hi James,

I just tried DOM Inspector

(In reply to comment #3)
> There is indeed a focused state on the active item when the list is expanded.
> However, in the case of a collapsed combo box, the focus event is fired on the
> combo box, not the list beneath it. At this point, the combo box should have
> state focused.

Yeah. It appears that the first combobox option "Oranges" has focus. The combobox appears collapsed.

> Also, in the case of lists, the focus event is fired on the list, not the
> active item. If the focused state is going to be set on the list item and not
> the list, the focus event really should be fired on the list item. That is, the
> focused state should be set on the object for which a focus event was fired.

I agree. I guess we should fire the focus event on the item (or option in the case of combobox).

> In NVDA, we use the focused state to ensure the accuracy of a focus event, as
> incorrect focus events are far too often fired. We currently have a specific
> exception for Mozilla combo boxes and lists due to the issue described here.
> Thus, this issue is not of major importance. However, it is an inconsistent
> implementation detail and should therefore be considered.

We have some special case code for comboboxes as well, so I think there is some history I don't know about here.

Comment 7

[alexander :surkov (:asurkov)]

To summarize:

1) fire focus event and set focused state on items.
2) fire focus event and set focused state on container if it doesn't contain any items

Sounds right?

Comment 8

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

Right.

Note in my comment #6:

> Hi James,
> 
> I just tried DOM Inspector
> 
> (In reply to comment #3)
> > There is indeed a focused state on the active item when the list is expanded.
> > However, in the case of a collapsed combo box, the focus event is fired on the
> > combo box, not the list beneath it. At this point, the combo box should have
> > state focused.
> 
> Yeah. It appears that the first combobox option "Oranges" has focus. The
> combobox appears collapsed.
> 

Here I am just confirming what appears visually. I think there is a bug, and that we do not set the focus on "Oranges" even though it visually has focus.

Comment 9

[James Teh [:Jamie]]

(In reply to comment #7)
> 
> 1) fire focus event and set focused state on items.
For collapsed combo boxes, the focus (both event and state) should probably still be the container, as it hasn't been expanded yet. For lists, it should be as you suggest.

> 2) fire focus event and set focused state on container if it doesn't contain
> any items
Yes.

Comment 10

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #9)
> (In reply to comment #7)
> > 
> > 1) fire focus event and set focused state on items.
> For collapsed combo boxes, the focus (both event and state) should probably
> still be the container, as it hasn't been expanded yet.

What events should we fire when combobox is collapsed and option is changed? Selection change and value change events? I assume we shouldn't fire repeated focus event since in this case focus isn't changed actually (stays on combobox)?

Comment 11

[alexander :surkov (:asurkov)]

(In reply to alexander surkov from comment #10)
> > For collapsed combo boxes, the focus (both event and state) should probably
> > still be the container, as it hasn't been expanded yet.
> 
> What events should we fire when combobox is collapsed and option is changed?
> Selection change and value change events? I assume we shouldn't fire
> repeated focus event since in this case focus isn't changed actually (stays
> on combobox)?

we had a bug 399128 which required to fire focus on options rather than combobox, that was needed for Orca. I wonder if it's still necessary since screen reader should announce value change event for focused combobox.

Comment 12

[James Teh [:Jamie]]

(In reply to alexander surkov from comment #10)
> What events should we fire when combobox is collapsed and option is changed?
> Selection change and value change events?
Value change certainly. I'm not sure about selection change, though. Does it currently get fired?
> I assume we shouldn't fire
> repeated focus event since in this case focus isn't changed actually (stays
> on combobox)?
This is true for most combo boxes. However, as you noted later, Gecko does fire focus on the item when it is changed even when the combo box is collapsed. Personally, I don't mind if this behaviour remains as is so long as the initial focus is the combo box itself.

Comment 13

[alexander :surkov (:asurkov)]

(In reply to James Teh [:Jamie] from comment #12)
> (In reply to alexander surkov from comment #10)
> > What events should we fire when combobox is collapsed and option is changed?
> > Selection change and value change events?
> Value change certainly.

ok, sounds good to me

> I'm not sure about selection change, though. Does it
> currently get fired?

I wouldn't rely on current behavior since selection change is pretty broken in gecko. But technically if selection change events are subject of focused accessible then we shouldn't. Let's get back to this later.

> > I assume we shouldn't fire
> > repeated focus event since in this case focus isn't changed actually (stays
> > on combobox)?
> This is true for most combo boxes. However, as you noted later, Gecko does
> fire focus on the item when it is changed even when the combo box is
> collapsed. Personally, I don't mind if this behaviour remains as is so long
> as the initial focus is the combo box itself.

Ok. Btw, in bug 673958 I switched to "not fire focus event" approach. Quick screen reader testing didn't show me a difference in behavior. Marco, will do that more. If existing ATs are fine with that then I prefer to keep this behavior.

Comment 14

[James Teh [:Jamie]]

(In reply to alexander surkov from comment #13)
> Ok. Btw, in bug 673958 I switched to "not fire focus event" approach. Quick
> screen reader testing didn't show me a difference in behavior.
There should be a subtle difference. When moving focus to the items (the current behaviour), when changing the active item in a collapsed combo box with NVDA running, you should hear "list" and the item will report position information; i.e. "<label> list, <item> <x> of <y>". Without moving focus, you will just hear the item with no position information; i.e. "<item>". Note that I don't believe sighted users can see the number of items in a collapsed combo box when they hit down arrow/up arrow, so I think this is acceptable.

Comment 15

[James Teh [:Jamie]]

I verified that this is fixed in the last try build for bug 673958.

Comment 16

[alexander :surkov (:asurkov)]

fixed by bug 673958

Comment 17

[Marco Zehe (:MarcoZ)]

Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1