GNOME Bugzilla – Bug 469894
Table navigation fails on ARIA tables
Last modified: 2007-08-30 15:16:43 UTC
ARIA tables are failing for the table navigation keys (Alt-Shift-Arrows). Preliminary investigation shows that the first table cell is navigated to correctly. However, the next navigation event fails, possibly because the container is not found correctly. Who originally implemented the table navigation code? Any insight this person could provide regarding this issue would be welcome. Test case: http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_Table.html
Created attachment 94262 [details] [review] first version of Table navigation fails on ARIA tables The difference between navigating the ARIA table and the HTML table is that ARIA tables trigger a caret-moved event on the 'section' that contains the table. HTML table navigation does not trigger caret-moved events. It should be noted that the 'section' referred to in the ARIA example retains focus (dotted box) during navigation. The patch involves short-circuiting onCaretMoved() for table cells that have the locus of focus. The patch seems to fix the problem, but I am not sure of any consequences. It is mainly posted as a starting point to begin discussions about the problem. The ARIA table does not have proper ARIA markup. Although this is not the source of the problem, I will address this with the Dojo developers. Once this is fixed it may give us an additional tool to help solve the problem.
The dojo table is not considered a working ARIA grid and should not be used for testing. This bug will remain in place until a valid test is posted. However, the invalid test does highlight an Orca table navigation bug or a Firefox bug caused by the extra caret-moved event. The Mozilla ARIA grid example is performing fine. see http://www.mozilla.org/access/dhtml/spreadsheet
Scott, I'm not sure I'm following. So... Is your question: Why is the first table (the scrollable HTML one) failing to work properly in Orca whereas the second one is working? (At least that is the issue I'm seeing). If so, it seems that something is triggering a focus: event for the section that contains the table. That event is setting the locusOfFocus outside of the table. Orca's table navigation code looks at the locusOfFocus, finds the table that contains it, and then does its thing. If it doesn't find the table that contains the locusOfFocus (which it won't in this case), Orca claims "not in a table" and gives up. So the question is what is triggering the focus: event on the parent object? And I'm dying to know the answer because Mike gave me a test case last week where we "get stuck" and the very same thing was going on. I haven't yet been able to figure it out and then got busy with other things the past couple of days. :-( I'll look at this general issue more tonight/tomorrow. In the meantime, if you happen to know what's triggering it, do tell please. :-)
(In reply to comment #3) > Scott, I'm not sure I'm following. So... Is your question: Why is the first > table (the scrollable HTML one) failing to work properly in Orca whereas the > second one is working? (At least that is the issue I'm seeing). If so, it > seems that something is triggering a focus: event for the section that contains > the table. That event is setting the locusOfFocus outside of the table. I am seeing a caret-moved event, not a focus event on the 'section' containing the top table. I am not seeing a focus or caret-moved event for the bottom table. > > Orca's table navigation code looks at the locusOfFocus, finds the table that > contains it, and then does its thing. If it doesn't find the table that > contains the locusOfFocus (which it won't in this case), Orca claims "not in a > table" and gives up. I see. That helps to clear things up. > > So the question is what is triggering the focus: event on the parent object? > And I'm dying to know the answer because Mike gave me a test case last week > where we "get stuck" and the very same thing was going on. I haven't yet been > able to figure it out and then got busy with other things the past couple of > days. :-( I'll look at this general issue more tonight/tomorrow. In the > meantime, if you happen to know what's triggering it, do tell please. :-) > I am not sure what is causing the extra event. I assume the top table is managed by some Javascript. This could possibly be triggering a DOM mutation event that is triggering the extra AT-SPI event, but that is just a guess. We may want to construct a simple HTML test case of a table within a container without any Javascript. The comparison of the two may lead us to the answer.
In the weird test case, the culprit is the style overflow:auto; (I took it out of the style sheet and the focus event went away). I just looked at your sample: div.dijitGridBody { height:200px; overflow:auto; } Coincidence? I think not. ;-) If you save a copy of your page, and update the style to be the full path i.e. @import "http://archive.dojotoolkit.org/nightly/dojotoolkit/dojo/resources/dojo.css"; Things will look normal and Orca will do its "not in a table" routine when you use table navigation commands (e.g. Alt Shift Arrow) from within the table. Nuke the overflow:auto; and give it another go. This time table navigation commands work as expected -- at least as far as Orca is concerned. Why overflow:auto; is the problem and what we are doing to trigger it is currently still a mystery to me.
(In reply to comment #5) > In the weird test case, the culprit is the style overflow:auto; (I took it out > of the style sheet and the focus event went away). > I agree, but I am getting extra caret-moved events, not focus events. > > Why overflow:auto; is the problem and what we are doing to trigger it is > currently still a mystery to me. > Sounds like a Firefox bug to me. Here is the W3C reference for the overflow property http://www.w3.org/TR/REC-CSS2/visufx.html#overflow
Scott, Will had an idea that may solve these problems. Please see: http://bugzilla.gnome.org/show_bug.cgi?id=471537
*** This bug has been marked as a duplicate of 471537 ***