381602 - First tab to HTML listbox does not actually focus an item (only provides fake appearance of focus on first item)

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[Scott Haeger]

Tabbing to a list triggers a focus event on the list, but there is no other event that gives information to what item is in focus.  As it works now, Firefox gives focus to the item which last had focus (as seen by dotted rectangular box) in the list box.  Ideally, we would like an active-descendant-changed event on the list item that has focus.  Less than ideal would be a second focus event on the item that has focus.

Comment 1

[Aaron Leventhal]

Is this a regression or was there always a problem?

Did you test with today's build? I think this is probably the same as the tree regression.

Why is activedescendant better? We don't use activedescendant at all -- everything gets mapped to a focus events, for reasons related to how ARIA handles focus.

Comment 2

[Scott Haeger]

I don't know how long this has been a problem.

Yes, I just tested the latest build with accerciser.  The following two events were received when tabbing to the list (focus and all object events):

focus(0, 0, None)
	source: [list | Single selection box]
	application: [application | Minefield]
object:state-changed:focused(1, 0, None)
	source: [list | Single selection box]
	application: [application | Minefield]


I would expect at least a focus event on the item that receives focus.  It is my understanding that GTK uses activedescendant for list, tables etc.  Internally, LSR is equipped to handle this arrangement.  An additional focus event should be sufficient for our needs.

Comment 3

[Aaron Leventhal]

Right but it's hard for Mozilla to use activedescendant for ARIA cases where true focus is sent to the list item.

LSR needs to map focus on list items and activedescendant to the same thing.

> I would expect at least a focus event on the item that receives focus. 

Yes, I would have thought we do that already.

Is the bug in HTML or XUL listboxes, or both? Please point me to where you're testing it.

Comment 4

[Scott Haeger]

The above test was done on both a single and multi selection HTML list.  Example markup would be:

<select id="ssb" size="5">
  <option>One</option>
  <option>Two</option>
  <option>Three</option>
</select>

Comment 5

[Aaron Leventhal]

Attachment: Testcase

Comment 6

[Aaron Leventhal]

I'm not seeing focus on the item when I tab to the list, but subsequent arrow key presses provide the correct focus events.

Do you see the same thing?

Comment 7

[Aaron Leventhal]

In fact this problem exists on Windows. It's not a regression -- broken in Firefox 2 as well.

Comment 8

[Aaron Leventhal]

Attachment: 1) Starting index should be on first item, 2) Fire a DOMMenuItemActive when list gets focus

This actually fixes two things:
1) The missing focus event on the focused <option> for <select> where size > 1, as you tab to the list
2) The first down arrow key press is no longer swallowed. I never noticed that before, but it's weird. We painted focus on the first item even though it wasn't focused. Then you down arrow which really puts focus on the first item, but it looks like nothing has happened. Rather than have all that I think focus should actually start on the first item -- we're still not selecting it so this should be fine.

Comment 9

[Mats Palmgren (inactive)]

Attachment: Testcase #2

Comment 10

[Mats Palmgren (inactive)]

Comment on attachment 265762 [details] [diff] [review]
1) Starting index should be on first item, 2) Fire a DOMMenuItemActive when list gets focus

Changing the initial values from kNothingSelected to zero worries me. 
Historically, changes to this code has proven to be very regression prone.
Would it be possible to fix this bug without that change?
Perhaps by just changing what FireMenuItemActiveEvent() does when
focusedIndex == kNothingSelected?

I've found three regressions with this patch so far, see Testcase #2.

Comment 11

[Aaron Leventhal]

> Would it be possible to fix this bug without that change?
> Perhaps by just changing what FireMenuItemActiveEvent() does when
> focusedIndex == kNothingSelected?

But that doesn't fix the fact that two down arrow key presses are required. That makes no sense. Either the first item is focused or it isn't.

Comment 12

[Aaron Leventhal]

Attachment: 1) Don't change Init(), 2) Change ResetList() so first item is focused only if there is an item and nothing is selected

Comment 13

[Mats Palmgren (inactive)]

(In reply to comment #11)
> But that doesn't fix the fact that two down arrow key presses are required.
> That makes no sense. Either the first item is focused or it isn't.

I'm not so sure, it might just be intentional.  Firefox, IE7, Opera 9 and
Safari selects the first option when pressing DOWN_ARROW in a single-select
list.  In a multiple-select list IE7 and Opera selects the second option,
Safari and Firefox selects the first.

As I see it, the outline has two purposes, it is visual feedback that the
<select> as a whole has keyboard focus and it shows which <option> is the
"selection caret".  In my view, individual <option>s can't have focus.
Note that on MacOSX the focus outline is drawn around the entire
list and there is no visual feedback of which option is the caret.

Can we agree that typing DOWN on a list that has keyboard focus means
the user wants select some item(s) in the list?
If so, and given that the list have no selected items, isn't selecting
the first item more convenient?
I think we should consider that this is what the four most popular UAs
currently do, so it might be what users expect.

I think we should keep the current behavior.
I'd like to hear what other people think.

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

I agree with Mats, the current behavior feels right to me.

Comment 15

[Boris Zbarsky [:bzbarsky]]

I seem to recall there being a way to move the "selection caret" as Mats aptly describes it around without selecting things until you get to the item you really want and can select it...

And yes, I think the current behavior (consistency between single and multiple selects, and compat with IE on single selects) is pretty much what we want.

In fact, it would be nice to get tests checked in for this behavior.

Comment 16

[Aaron Leventhal]

You can move focus without changing selection with ctrl+up and ctrl+down.

I have to say I disagree with everyone here. If the first option looks focused it should be focused. If nothing is focused then the focus ring should somehow indicate the entire list is focused.

How does it make sense that we swallow the first down arrow and end up on the same item?

Comment 17

[Aaron Leventhal]

Maybe it helps to imagine yourself as a text-to-speech user.

For a list with
dog
cat
owl

If the AT reads that I'm focused on "dog" and I press down down arrow I expect to be on "cat".

Comment 18

[Aaron Leventhal]

This is also inconsistent with how we do things elsewhere.

For example, 
1) open bookmarks with Ctrl+B
2) tab to the list of bookmarks, notice that the first item has focus
3) down arrow, notice the second item is focused and selected

Or, in Windows explorer, 
1) open a folder, select detail view
2) Go the the location entry field
3) Enter c:\
4) Tab into the list 
5) Press down arrow, notice the second item is focused and selected

In both cases the first item starts out focused, and a space bar selects it, or down arrow goes to the next item.

Comment 19

[Aaron Leventhal]

So I guess it's a difference between single and multi select lists.

Opera is another example where a multi select list does what I'm proposing here.

Focus can be on an individual item in a multi select list (ctrl+arrow changes focus).

Comment 20

[Aaron Leventhal]

Hah, Opera and IE do the same thing, and we differ.

In all cases, on first tab to the list, the first item has focus but is not selected.

Multi select: down arrow selects and focuses 2nd item
Single select: down arrow selects first item 

Comment 21

[Mats Palmgren (inactive)]

(In reply to comment #16)
> How does it make sense that we swallow the first down arrow and end up on the
> same item?

Because we don't really "swallow" it - we do select the first item.

(In reply to comment #17)
> Maybe it helps to imagine yourself as a text-to-speech user.
> 
> For a list with
> dog
> cat
> owl
> 
> If the AT reads that I'm focused on "dog" and I press down down arrow I expect
> to be on "cat".
> 

The AT could say "list with no selected items, first item is dog" on focus
(isn't that more accurate?) and then "dog" on DOWN.

Comment 22

[Boris Zbarsky [:bzbarsky]]

Aaron, one question in my mind for AT purposes is whether having single and multi-select lists behave differently makes sense.  Does it?

Comment 23

[Aaron Leventhal]

Boris, there are additional keystrokes and modified-click features in a multiselect. Those wouldn't make sense in a single select.

Or are you asking about what the first tab and first down arrow should do, and whether that should be different as it is in IE and Opera?

Comment 24

[Boris Zbarsky [:bzbarsky]]

The latter, since that's what this bug is about....

Comment 25

[Aaron Leventhal]

> The AT could say "list with no selected items, first item is dog" on focus
> (isn't that more accurate?) and then "dog" on DOWN.

Or perhaps "List, dog, 1 of 3, unselected"

Boris, I'm not sure why IE and Opera made the distinction, so I'm on the fence.

Comment 26

[Aaron Leventhal]

Bottom line is: current behavior is incorrect.

The first item looks focused but really isn't. For example, the space bar does not select it.

Comment 27

[Boris Zbarsky [:bzbarsky]]

The thing that's focused is the <select> widget itself.  If the problem is that we want that to be indicated differently, we can just change it.  See nsListControlFrame::PaintFocus for where we paint it now.

What's the spec for the behavior we actually want?

Comment 28

[Mats Palmgren (inactive)]

(In reply to comment #26)
> Bottom line is: current behavior is incorrect.

Well, I think that drawing the outline around the first item in a list
without selection is what is incorrect, or perhaps ambiguous is a better
word for it.  I agree that it makes it appear as if the "selection caret"
is placed there when it isn't, it really signals that the list as a whole
is focused.  A better focus indication is of course what MacOSX has,
we /could/ do something like that on other platforms - say drawing the
outline around all visible items (inside the border), but since this is
different from the standard look-n-feel on those platforms I think the
ambiguity is acceptable.  It's a trade-off for the benefit of the use case
at hand - tabbing to a list with the intention of selecting some item(s).
Having to type DOWN and then UP to select the first item in this case
doesn't make sense to me.  For MacOSX I'd consider it a bug even.
All major UAs have the current behavior for single-select lists,
IE/Opera differs from Firefox/Safari for multiple-select lists but I still
want to keep the current behavior for multiple-select lists because
I don't see why it should differ from single-select.

Aaron, I think we basically agree on what the problem is, we just have
different opinions on which aspect is the more important one.

> For example, the space bar does not select it.

We could easily fix that without changing what DOWN does though.

Comment 29

[Marco Zehe (:MarcoZ)]

*ping* :-)

Comment 30

[Mats Palmgren (inactive)]

Comment on attachment 267734 [details] [diff] [review]
1) Don't change Init(), 2) Change ResetList() so first item is focused only if there is an item and nothing is selected

This changes the behavior of DOWN as described in my earlier comments
and I still think that's a regression.  Other than that it looks fine.

Comment 31

[Mats Palmgren (inactive)]

Attachment: wip

Aaron, would something like this be enough for a11y purposes?
It fires a DOMMenuItemActive event on the first item on focus in case
there isn't anything already selected.
It doesn't change form control behavior in any way, just a11y code.

Comment 32

[Marco Zehe (:MarcoZ)]

Here's my take on this:
1. I believe we all agree on the fact that, if an item visually looks focused, it should be focused also for a11y, and programmatically in general.
2. Question: Why do those of you who advocate for the behaviour that DownArrow should select the first item instead of the second in a single-select listbox, think that this is the behaviour to go for? Because IE does it, or do you see actual other benefits for it? Let me give you the user experience  that I, as a screen reader user, get when landing on such a single-select listbox: The screen reader would say "list, not selected Dog, 1 of 3". The fact that it is not selected usually means that I can press SPACE to select it. And because it tells me "1 of 3", I would, from a usability standpoint, always think that DownArrow actually takes me to the second item. Whenever I personally find one of these lists, I am irritated by the behaviour that DownArrow actually does not change items for me. It does change items in multi-select listboxes, ListViews like Windows Explorer's Details View, etc. I would strongly advocate for changing the behaviour, contrary to how IE, and Opera do it. With Safari, the story is a bit different because it does not have an initially focused item. There, DownArrow makes sense to focus, and select, the first item.

Comment 33

[Boris Zbarsky [:bzbarsky]]

> Why do those of you who advocate for the behaviour that DownArrow
> should select the first item instead of the second in a single-select listbox,
> think that this is the behaviour to go for?

The alternative is that tabbing through a single-select listbox will change its state in an irreversible way.  Specifically, with a single-select listbox there is no way to go back to having no selection at all once a selection has been made.  Since there is no random access while tabbing, users are forced to tab through controls.  Thus, having a listbox select an item when tabbed to would make it impossible to change the state of controls that are later in the tab order without changing the state of the listbox.

Most likely, this is also the source of the difference in IE behavior on single-select and multi-select listboxes.  For the latter, one _can_ unselect all items, thus restoring the listbox to its original state (though this is a huge pain in the behind if you're just trying to get to controls that are later in the tab order).

Comment 34

[Marco Zehe (:MarcoZ)]

(In reply to comment #33)
> > Why do those of you who advocate for the behaviour that DownArrow
> > should select the first item instead of the second in a single-select listbox,
> > think that this is the behaviour to go for?
> 
> The alternative is that tabbing through a single-select listbox will change its
> state in an irreversible way.  Specifically, with a single-select listbox there
> is no way to go back to having no selection at all once a selection has been
> made.
What I meant was: With DownArrow selecting the second item, when you tab to a single-select that has no selection, SPACE would select the first item.  Having the first item focused, but not selected, would still be there.
As for not being able to deselect anything once a selection has been made: That is the current behaviour. In a single-select, once a selection has been made, you cannot get rid of it, even when control-clicking the selected item. So if we were to go with DownArrow selecting the first item, as it is now, would you want a function added that UpArrowing on the first item removes the selection?

Comment 35

[Boris Zbarsky [:bzbarsky]]

> What I meant was: With DownArrow selecting the second item, when you tab to a
> single-select that has no selection, SPACE would select the first item. 

Ah, I see.  That might work, sure.

Comment 36

[Marco Zehe (:MarcoZ)]

(In reply to comment #35)
> > What I meant was: With DownArrow selecting the second item, when you tab to a
> > single-select that has no selection, SPACE would select the first item. 
> Ah, I see.  That might work, sure.

So, what should we do about the current inability to deselect a selected item, to return a single-listbox to a state where no item is selected? If we go with the solution that DownArrow selects the second item after the list is focused, and that SPACE selects the first, should Control+Space, and Control+MouseClick on the selected item return the list to a state where no item is selected?

Comment 37

[Aaron Leventhal]

Marco, I think that would work.

Mats, Smaug -- do you have any issue with this plan?

Comment 38

[Olli Pettay [:smaug][[e-mail]]]

I think that sounds ok.

Comment 39

[Aaron Leventhal]

Attachment: Allow control+space to toggle selection in any <select> (even single)

I believe this approach currently has no objections from Marco/Bz/Smaug/myself.

Comment 40

[Aaron Leventhal]

Attachment: Same thing, diff -uw (no whitespace changes)

Comment 41

[Boris Zbarsky [:bzbarsky]]

Hold on.  Have objections, sure.  No other UA I know of allows clearing the selection in a single-select altogether once it's been made.  I'm not sure we should make that change.  And I didn't get the impression that it was needed.  Did I miss something?

Comment 42

[Aaron Leventhal]

Bz, none of the UA's I'm testing with do a complete job of handling multi select lists. However, the Windows file browser, when in single select mode, allows Ctrl+space to deselect. Really, it just appears that UA's have not spent a lot of time refining <select> for single select where the size > 1. It's a bit of a weird case. Normally you'd just use a combo box.

If it is valid to have nothing selected, you should be able to get to that with the mouse or keyboard.

That said, I have no major objection to disallowing it if we can get the rest of this fix in.

Comment 43

[Boris Zbarsky [:bzbarsky]]

A single select with size > 1 is conceptually no different from a radiogroup with not button preselected.  And we don't allow deselecting radio buttons either, right?  Nor does any other UI I know of...

Comment 44

[Aaron Leventhal]

Bz, I don't care really. but I do care that we don't have a mode where an option looks focused and isn't. Do you have any objection to that part of the fix?

Comment 45

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #43)
> A single select with size > 1 is conceptually no different from a radiogroup
> with not button preselected.  And we don't allow deselecting radio buttons
> either, right?  Nor does any other UI I know of...

Ah, that is a good point and changing that would probably break some web apps, if
user could start unselecting something which is assumed to have always one
selected <option>

Comment 46

[Boris Zbarsky [:bzbarsky]]

Right.  Web apps are the reason for comment 41.

Aaron, I'm fine with a change that:

1)  Gives reasonably logical behavior
2)  Doesn't select an option as a result of merely tabbing through a
    single-select with size > 1.

Comment 47

[Aaron Leventhal]

Attachment: Don't allow ctrl+space or ctrl+click to unselect in a single select <select>

Comment 48

[[e-mail]]

(In reply to comment #18)
> This is also inconsistent with how we do things elsewhere.
> 
> For example, 
> 1) open bookmarks with Ctrl+B
> 2) tab to the list of bookmarks, notice that the first item has focus
> 3) down arrow, notice the second item is focused and selected
Only because you changed it (and broke the mail thread pane in doing so).

A native Windows single-selection listbox (which is what Netscape 4 would use in this situation) has the following behaviour:
1. Once an item has been selected, it can only be deselected by selecting another item. The user cannot clear the selection.
2. If no item is selected, then the first item has a dotted outline indicating that the listbox has focus. Both space and down arrow select the first item.
Also note that focus != selection, particularly in a multiselect listbox.

Comment 49

[[e-mail]]

Comment on attachment 286896 [details] [diff] [review]
Don't allow ctrl+space or ctrl+click to unselect in a single select <select>

...therefore the only change that I am prepared to sr would be for space to select the first item if there's nothing selected.

Comment 50

[Aaron Leventhal]

Neil, I believe the patch that we ended up asking you for sr= on is what you're looking for. It follows what you've asked for in comment 48. In order to make down arrow select and focus the second item we had to implement a change, because curently, the first tab to the listbox shows a fake focus, and the first down arrow then really focuses and selects the first item.

Comment 51

[Aaron Leventhal]

Comment on attachment 286896 [details] [diff] [review]
Don't allow ctrl+space or ctrl+click to unselect in a single select <select>

Wait, on re-reading your comment 48 I see you actually want the first item to show fake focus when the listbox has focus. Can you justify that?

Comment 52

[Aaron Leventhal]

Comment 48 is wrong afaict.

For example, try File->Save as in any app. First down arrow selects the second item.

Comment 53

[Aaron Leventhal]

Comment on attachment 286896 [details] [diff] [review]
Don't allow ctrl+space or ctrl+click to unselect in a single select <select>

Neil, on IRC you said "NeilAway>	aaronlev: well, if you want to copy a listview control, then you would set the default anchor index to 0"

That's what this patch does.

Comment 54

[[e-mail]]

Comment on attachment 286896 [details] [diff] [review]
Don't allow ctrl+space or ctrl+click to unselect in a single select <select>

It turns out that this isn't so easy, since you have to skip disabled items, and you also have to be able to deal with script adding, deleting or disabling items.

Comment 55

[Aaron Leventhal]

Attachment: Use AdjustIndexForDisabledOpt() to skip past disabled options

Comment 56

[Aaron Leventhal]

Attachment: Testcase #3: includes an empty select and a select with only disabled options

Comment 57

[[e-mail]]

Comment on attachment 287048 [details] [diff] [review]
Use AdjustIndexForDisabledOpt() to skip past disabled options

(In reply to comment #54)
>(From update of attachment 286896 [details] [diff] [review])
>and you also have to be able to deal with script adding, deleting or disabling items.
data:text/html,<body%20onload=document.body.firstChild.firstChild.disabled=false><select%20size=4><option%20disabled>disabled<option>enabled

Comment 58

[Aaron Leventhal]

Attachment: Handle dynamic case

Comment 59

[[e-mail]]

Comment on attachment 287116 [details] [diff] [review]
Handle dynamic case

>+        mStartSelectionIndex == kNothingSelected) {
This doesn't change so you can test it earlier.

Comment 60

[Mats Palmgren (inactive)]

(In reply to comment #32)
> Why do those of you who advocate for the behaviour that DownArrow
> should select the first item instead of the second in a single-select
> listbox, think that this is the behaviour to go for?

1. Compatibility. All four major UAs have this behaviour.
2. Ease of use. The assumption is that the intention of focusing a list
   is to select one or more items. Having to type DOWN then UP to select
   the first item is awkward, while this can be improved by using SPACE
   select the first item in this case, it makes selecting the first item
   "special" since you would use DOWN to select any other item; using the
   same key (DOWN) is easier to remember.
3. on MacOSX the new behaviour is clearly a bug since the focus outline
   is (or at least should be) drawn around the whole list and selecting
   the second item on DOWN in this case makes no sense.

> screen reader would say "list, not selected Dog, 1 of 3". The fact that it is
> not selected usually means that I can press SPACE to select it.

We could make SPACE select the first item without changing the behaviour
of DOWN.

> I am irritated by the behaviour that DownArrow actually does
> not change items for me. 

That seems like a separate bug.  When I tested one of the earlier patches
the unpatched behaviour at that time was to select the first item on DOWN
(like Firefox 2), so not selecting anything at all looks like a recent
regression(?)

Comment 61

[Mats Palmgren (inactive)]

Comment on attachment 287116 [details] [diff] [review]
Handle dynamic case

I tested the following screen readers, tabbing to the list element in
the following testcase:
data:text/html,<body><select size=3><option>dog<option>cat<option>owl

Orca on Ubuntu 7.10 (Gutsy) says:
"dog list" without the patch, "dog list dog" with the patch

VoiceOver on MacOSX 10.5 (Leopard) says:
"list no selection" both with and without the patch.
(selecting an item with mouse or keyboard does not speak anything)

JAWS 8.0 on Windows XP says:
"list box dog cat owl" both with and without the patch.

This is exactly the same result I get with the "wip" I attached earlier,
so it seems to me that it should be possible to fix the event problem
described in comment 0 without changing the behaviour of DOWN.

I still think we should keep the current behavior for the DOWN key
(Smaug agrees in comment 14 and Bz in comment 15 and Neil in comment 48)

(FWIW, the keyboard selection bug occurs with Orca and JAWS, but not
 VoiceOver. Both this patch and mine "fixes" it for Orca but not JAWS.)

Comment 62

[Evan Yan]

XUL listbox have different behaviors.

I tried the "Customize Character Encoding" dialog. (from menu View->Character Encoding->Customize List)
In Firefox 2, it behaviors like what Windows Explorer does, that is when focus to the listbox, it is initialized with the first item focused and no selection, pressing DOWN key makes the second item focused and selected.
In Firefox 3, the listbox is initialized with the first item focused and selected.

And also no DOMMenuItemActive event for the focused item when focus to a xul listbox. That's what bug 380848  is for.

Comment 63

[Boris Zbarsky [:bzbarsky]]

> XUL listbox have different behaviors.

See comment 48.  Sounds like we need a regression bug filed on that, no?

Comment 64

[Evan Yan]

(In reply to comment #63)
> > XUL listbox have different behaviors.
> 
> See comment 48.  Sounds like we need a regression bug filed on that, no?
> 
bookmarks organizer and mail thread pane are xul trees, there have the same behavior in Firefox 2 and Firefox 3.

Comment 65

[Aaron Leventhal]

Mats, 

Honestly I don't see the resistance to this fix. It makes it work like the Windows file explorer.

Don't pay attention to what Voice Over does with us yet. Our support there is not complete. Orca would prefer this fix but they can work around it either way.

The big thing is JAWS support. They have 90% of the screen reader market and are not willing to make changes for Firefox support at this point. We need the fix for bug 394190 and without this fix, that one won't work. At least one of the options has to have focus or the listbox doesn't even appear in the virtual buffer.

If you want to test with these 2 patches, you need to turn on off virtual cursor mode (Insert+Z).

Bug 349190 is one of our last major bugs with JAWS support. We need this fix in order to deal with that properly. We could put a fake focus state on the first item even though it doesn't have focus, which would mirror the fake focus outline on the first option, and then the extra down arrow is required to really focus it. So it's impossible to tell the difference between real focus and fake focus. 

Comment 66

[Mats Palmgren (inactive)]

(In reply to comment #65)
> The big thing is JAWS support. They have 90% of the screen reader market and
> are not willing to make changes for Firefox support at this point.

Firefox's single-select list currently behaves as IE7's, so it should be
possible to make Firefox send the same a11y events that IE7 sends?

> We need the fix for bug 394190 [...]
> Bug 349190 is one of our last major bugs with JAWS support.

Neither of those seem to be related to a11y - wrong bug numbers?

> We could put a fake focus state on the first
> item even though it doesn't have focus ...

Yes, that seems the way to go.  What does IE7 do?

Comment 67

[Aaron Leventhal]

We no longer need this for bug 391490.

We can mark it WONTFIX if everyone agrees.`

Comment 68

[Evan Yan]

In Accerciser, the focused listitem still doesn't have focus event when first tab to a list.
I tested with Orca, but get a little confused with Orca's reading. So I'm not sure whether Orca would have problem with it. It would be better to have some input from Orca user.

Comment 69

[Evan Yan]

Marco, could you please help try the testcases with Orca, to see whether we can mark this bug WONTFIX?

Comment 70

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

Mass un-assigning bugs assigned to Aaron.

Comment 71

[alexander :surkov (:asurkov)]

Trevor, could you check it please (see comment #68)?

Comment 72

[Trevor Saunders (:tbsaunde)]

Ok, this seems to work fine with orca, so marking as wontfix per comment 67.  However there is a spin off bug that we seem to have several objects in that case claiming focus.

Comment 73

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

Please file the spin off and/or mention it here.

Comment 74

[James Teh [:Jamie]]

Why wontfix? I still consider this a bug, even if some ATs have worked around it. This is still an issue in NVDA, as noted in bug 474893. I somehow missed this bug; bug 474893 is a duplicate, though it does cover another case of the same issue, so I'm wondering whether we should close this one as a duplicate instead.

Comment 75

[James Teh [:Jamie]]

Ping on an answer for comment #74? :) A fix for this isn't urgent, but it still shouldn't be wontfix. Nevertheless, I'm reluctant to reopen myself since I'm not sure if there is more history here than I know about.

Comment 76

[Mats Palmgren (inactive)]

The consensus is that the <select> element should have focus,
not the individual <option>s.  That's why this bug is wontfix.
That shouldn't stop bug 474893 from notifying a11y when an <option>
is being traversed/selected/unselected.

Comment 77

[James Teh [:Jamie]]

(In reply to comment #76)
> The consensus is that the <select> element should have focus,
> not the individual <option>s.  That's why this bug is wontfix.
I can't speak for other parts of the code, but my point is that this is most definitely incorrect for accessibility. Accessible focus should be fired on the element of interest to keyboard users. In this case, that is the active option, since pressing up/down arrow will move relative to that option.

Comment 78

[James Teh [:Jamie]]

(In reply to comment #76)
> The consensus is that the <select> element should have focus,
> not the individual <option>s.
Actually, this isn't currently true as far as a11y is concerned. The focused state is set on the option, not the select. It's just the focus *event* that is incorrectly fired on the select.

Perhaps I'm misunderstanding the scope of this bug. It refers to the first tab to the list box, not subsequent tabs. As noted, pressing down arrow after the first tab selects the first item, so perhaps it's okay for the first tab.

However, if a user selects an item, tabs out of the list box and then tabs back, we should definitely see a11y focus on the option, not the select. In that case, perhaps bug 474893 covers this issue.

Comment 79

[alexander :surkov (:asurkov)]

(In reply to comment #78)
> (In reply to comment #76)
> > The consensus is that the <select> element should have focus,
> > not the individual <option>s.
> Actually, this isn't currently true as far as a11y is concerned.

true, the bug is not about DOM events, it's about a11y events.

Comment 80

[James Teh [:Jamie]]

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

Comment 81

[alexander :surkov (:asurkov)]

fixed by bug 673958

Comment 82

[Marco Zehe (:MarcoZ)]

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

Comment 83

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1527381