GNOME Bugzilla – Bug 473611
Orca announces two list items when navigating to ARIA listboxes
Last modified: 2007-11-01 18:59:46 UTC
Will observed the following when testing a previous listbox patch seen here http://bugzilla.gnome.org/show_bug.cgi?id=468968. In http://www.mozilla.org/access/dhtml/listbox, I'm also noticing the following: 1) Select the "Violet" item. 2) Move the caret between the 'i' and 't' in 'item'. Clicking with the mouse is fine if you can do it. 3) Down arrow to the list box. You will hear "Green list item" and then "Violet list item" instead of just "Violet list item" I believe the problem is that the first list item is announced due to a focus event on the list and the second announcement is due to another focus event on the list item that is currently selected.
Created attachment 94954 [details] [review] first version of Orca announces two list items when navigating to ARIA listboxes Performing the steps outlined in the opening comment results in the execution of two sets of code paths, thus creating the two announcements. The first stems from the user input (eg. down arrow) which calls goNextLine(). This method does a setCaretPosition() which sets the caret and grabs the focus followed by speaking the first announcement. The grab focus call triggers a focus event on the selected list item which leads to the second announcement. I see two potential solutions to the problem. 1) tweak findNextLine() so it returns the selected item instead of the first item for lists. This seems like a difficult solution and I don't know if there would be any side effects. 2) Just return in _getSpeechForListItem() when the listitem does not have focus. This is a very simple solution, but once again I do not know the complete ramifications of this fix. The patch uses this approach. Note: These patches are also required: http://bugzilla.gnome.org/attachment.cgi?id=94652 http://bugzilla.gnome.org/attachment.cgi?id=94936
I am unsure of the fix and could use some feedback. You will still need http://bugzilla.gnome.org/attachment.cgi?id=94936 to thoroughly test. The other patch has been applied to trunk.
(In reply to comment #2) > I am unsure of the fix and could use some feedback. You will still need > http://bugzilla.gnome.org/attachment.cgi?id=94936 to thoroughly test. The > other patch has been applied to trunk. I'm not sure I like the idea of having the speechgenerator circumvent things. I think incorporating knowledge of where the caret/focus is going to end up might be a better way to go. Is there a way to identify and filter out the first focus event?
> I'm not sure I like the idea of having the speechgenerator circumvent things. I can agree with that. > I think incorporating knowledge of where the caret/focus is going to end up > might be a better way to go. This could be difficult and could potentially impact performance, especially for long lists. > Is there a way to identify and filter out the first focus event? There might be if Firefox provided state SELECTED. At the moment they don't. This may be our best path. I'll talk to Aaron about getting this done.
> > Is there a way to identify and filter out the first focus event? > > There might be if Firefox provided state SELECTED. At the moment they don't. > This may be our best path. I'll talk to Aaron about getting this done. I'll admit I'm not looking at the debug logs. I have a question about the ordering of the focus events. Is the first one on the list and the next on the list item? If so, is it the case that we could do some sort of check like: "if the focus landed on an aria list that has a non-empty selection, then ignore the focus because we're going to get one for the list item anyway?"
This bug is complicated to follow due to the grabFocus() used in setCaretPosition(). Here are the sequence of events as I understand them: 1) User hits down arrow. 2) goNextLine() is called resulting in the first announcement of the first list item. Also, setCaretPosition() is called (before announcement). 3) setCaretPosition() calls IComponent.grabFocus(). 4) Two focus events are triggered with both of the events being on the selected list item. The multiple events may be a Firefox bug, but I am not sure. 5) OnFocus catches both focus events but only acts on the first event. I assume that the focus_track_presenter filters the second event out. The strange thing is that we are grabbing focus on the list but are getting focus events back on the selected list item. This may be due to the list using activedescendant.
The root of the problem is caused by the items in the list not having state FOCUSABLE. I thought this might be caused by the list using activedescendant, but the selected item has state FOCUSED. This leads me to think that the lacking state is a Firefox bug. Monitor the Mozilla bug here https://bugzilla.mozilla.org/show_bug.cgi?id=395041
Aaron's response to the list items not having state FOCUSABLE: "There's no way to indicate that something might become the activedescendant.". This means it is technically impossible to tell if a list item is focusable until it is focused. This fact will make this bug fix much more difficult.
Created attachment 95367 [details] [review] second version of Orca announces two list items when navigating to ARIA listboxes This patch does a good job at filtering out the incorrect first announcement stemming from the goNextLine() call. However, Orca still does not set the caret on the selected item.
The work being done on bug 478204 might help this bug a lot. The resulting user experience is to have caret navigation skip over editable lists (as opposed to bulleted lists). For this bug, I think the following work/tests might be needed: 1) Check the behavior when tabbing to/from an editable ARIA list. Fix it if need be. This should hopefully be independent of bug 478204. 2) After bug 478204 is fixed, check the behavior wrt arrowing around editable ARIA lists. Fix it to act like editable XUL lists if need be.
Created attachment 96300 [details] test case with various HTML lists and a single ARIA listbox
This bug report might be obsolete with Mike's new list navigation model. Monitor bug 478204
Scott - is this bug obsolete with the new navigation model?
This bug is now obsolete with the new list navigation model. Marked as obsolete.