GNOME Bugzilla – Bug 468968
[mike] Support ARIA listbox
Last modified: 2007-09-05 15:02:01 UTC
As expected, ARIA listboxes consist of a list with list item children. Moving between the items triggers only a focus and object:state-changed:focus events because the caret position does not change. The problem is gecko.onFocus() returns early for ARIA widgets when the up/down arrow keys are used. This was required for other ARIA widgets because we were getting double announcements. A new strategy will thus need to be employed.
This problem illustrates the general problem of how to deal with widgets that use activedescendant. These types of widgets will only trigger focus changed events and not caret moved events because the caret does not move. Contrast this with ARIA trees where we get both a focus change and caret moved events because the caret does move. Aaron suggested that there is a managesdescendants/activedescendant mechanism in atk/at-spi, but he would only pursue it as a last ditch solution. So, my questions are the following: 1) How can we make onFocus() smarter so it returns early for some ARIA widgets, but not for others that use activedescendant? 2) Are listboxes the only widgets that could use activedescendant? Certainly there must be more. Which ones? 3) Will the lack of caret-moved events cause any problems because the onCaretMoved() code path is not executed? Test cases Listbox : http://www.mozilla.org/access/dhtml/listbox Tree: http://test.cita.uiuc.edu/aria/tree/xhtml.php?title=Tree%20Example%201&ginc=includes/tree1a.inc&gcss=css/tree1a.css&gjs=../js/globals.js,../js/enable_app.js,js/tree1a.js
The solution may be to remove the following code from gecko.onFocus() and put it at the top of gecko.onCaretMoved(). if self.isAriaWidget(event.source) \ and isinstance(orca_state.lastInputEvent, input_event.KeyboardEvent) \ and orca_state.lastInputEvent.event_string in ["Up", "Down"]: return Any ramifications that I may be unaware of? It seems to work fine for both trees and listboxes. I believe we should always receive focus change events but maybe not caret-moved events. This may be a way of circumventing this problem.
Created attachment 94120 [details] [review] first version of Support ARIA listbox A patch to try my idea stated in previous comment.
(In reply to comment #3) > Created an attachment (id=94120) [edit] > first version of Support ARIA listbox > > A patch to try my idea stated in previous comment. > I'm still trying to soak this up. I'm trying to understand the notion of what Gecko has decided to do with focus: and parents that manage their descendants. I cannot remember what the intended behavior is supposed to be: is it that only the parent gets focus and issues active descendant changed events, or is it intended that the children actually get focus. I'm not sure and need to do some digging.
The parent gets focus as seen by the dotted box, but focus events on the list items are triggered when selecting the items. The dotted box is never placed around the items. Right now there are no active descendant changed events. This could be added but Aaron would like to avoid this right now due to work load. Try poking around the listbox example to get a better idea of what is involved here.
Adding mike for review -- please take a look at the patch.
A patch was posted here http://bugzilla.gnome.org/show_bug.cgi?id=471878 that also fixes this problem.
This seems like a good patch. I see a few oddities with the following demos, though, which may or may not be related problems. In http://www.mozilla.org/access/dhtml/listbox, I'm noticing the following: 1) Position the caret between the 'i' and 't' of "item" in the paragraph above the list box. 2) Down arrow to the list. 3) Press the right arrow. This takes you to the 'm' in item. Strange. 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" In http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_Tree.html, I notice that I cannot arrow up/down out of the tree once I get in it. There might be some special logic that needs to be done to handle these cases. We handle multiline text areas specially in Gecko.py:useCarentNavigationModel. Something might need to be done for crazy ARIA widgets here. In any case, these are just observations from testing with the patch. Scott said he would investigate and open new bugs if necessary. Thanks Scott!
The first two problems listed in comment #8 are due to improperly setting either the focus or caret on the list or list item. Another potential issue may be extra events being triggered when the focus or caret is set on the widget. The tree issue may not be a bug. All three problems will have to wait until Mike defines the behavior for navigating in and out of widgets where the arrow keys are used for navigating the widget eg. listboxes, trees, comboboxes, multiline textboxes. I will post new bugs when I get a better understanding of the desired behavior. The fix for this bug should also come after http://bugzilla.gnome.org/show_bug.cgi?id=471537 .
The original bug has been fixed with http://bugzilla.gnome.org/show_bug.cgi?id=471878 . The issues that were brought up in comment #8 are being addressed here http://bugzilla.gnome.org/show_bug.cgi?id=473585 and here http://bugzilla.gnome.org/show_bug.cgi?id=473611 . This bug will be marked as fixed.