Closed Bug 433418 Opened 17 years ago Closed 13 years ago

Accessibles for focused HTML Select elements are not getting focused state

Categories

(Core :: Disability Access APIs, defect)

x86
Windows Vista
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla10

People

(Reporter: mick, Assigned: surkov)

References

(Blocks 2 open bugs)

Details

(Keywords: access, Whiteboard: post1.9)

Attachments

(1 file)

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.
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.
Keywords: access
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Making sure this stays on the radar for after Firefox 3.0 ships.
Blocks: 191a11y
Whiteboard: post1.9
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.
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.
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?
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.
(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.
Blocks: a11ynext
No longer blocks: 191a11y
(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)?
(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.
Depends on: 673958
Flags: in-testsuite?
(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.
(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.
(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.
I verified that this is fixed in the last try build for bug 673958.
fixed by bug 673958
Assignee: nobody → surkov.alexander
Status: NEW → RESOLVED
Closed: 13 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: