Bug 30895 - [Gtk] The accessible hierarchy of tables is significantly incorrect for Atk
Summary: [Gtk] The accessible hierarchy of tables is significantly incorrect for Atk
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords: Gtk
Depends on:
Blocks: 25531 35504
  Show dependency treegraph
 
Reported: 2009-10-28 22:07 PDT by Joanmarie Diggs (irc: joanie)
Modified: 2010-03-08 13:06 PST (History)
5 users (show)

See Also:


Attachments
proposed fix - includes layout test (8.23 KB, patch)
2010-02-28 14:26 PST, Joanmarie Diggs (irc: joanie)
no flags Details | Formatted Diff | Diff
rest of the fix - includes additional layout test (11.22 KB, patch)
2010-03-01 10:36 PST, Joanmarie Diggs (irc: joanie)
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Joanmarie Diggs (irc: joanie) 2009-10-28 22:07:09 PDT
An AtkTable, in which the table does not manage its descendants, has a simple hierarchy, namely something like:

-> table
   -> table cell
   -> table cell
   -> table cell
   -> table cell
   -> table cell

The above hierarchy might represent:

* a single column with five rows
* a single row with five columns
* two rows and three columns in which one cell spans two rows
* etc., etc., etc.

(Headers and captions can also be in the hierarchy, but they at the same level as the cells.)

The remaining details about the table are not exposed through hierarchical structure, but rather through the AtkTable interface (the bulk of which was implemented in bug 25534).

The accessible hierarchy of tables exposed to ATs by WebKitGtk is quite different: The table cells appear to each be represented by two children within the table rather than one. First they appear in row order as children of objects of ROLE_LIST_ITEM. Then they appear again in column order as children of objects of ROLE_UNKNOWN.

While ATs providing access to Gtk+ apps do have to largely rely upon querying the table interface, they also have a need -- and an expectation -- to be able to access the table's hierarchy. The current implementation is too different (broken?) for this to be reliable.
Comment 1 Joanmarie Diggs (irc: joanie) 2010-02-28 14:26:16 PST
Created attachment 49704 [details]
proposed fix - includes layout test

It turns out that the fix for bug 35418 also unborked the accessible table hierarchy somewhat. This patch seems to finish the job.
Comment 2 Joanmarie Diggs (irc: joanie) 2010-02-28 15:18:38 PST
Drat! There are still other cases of borked tables. The previous patch changes are necessary, but additional changes will be as well. (I knew it seemed too easy....) :-(
Comment 3 Joanmarie Diggs (irc: joanie) 2010-03-01 10:36:30 PST
Created attachment 49730 [details]
rest of the fix - includes additional layout test

The other issue turned out to be that any table identified as an AccessibilityTable always added a bunch of children without considering whether or not those children should be "ignored" by the platform. This patch changes that so an AccessibilityTable only adds children that are not "ignored." It also makes corresponding Gtk-specific changes so that we can actually specify that they should be ignored.

Note that this patch assumes/depends upon the previous one. Therefore, I'm not yet flagging it for review as the bots will just spit up on it. But as far as I'm concerned at the moment, this is everything that needs to be done w.r.t. this bug pending code review.
Comment 4 Eric Seidel (no email) 2010-03-05 13:02:20 PST
Comment on attachment 49704 [details]
proposed fix - includes layout test

OK.
Comment 5 Eric Seidel (no email) 2010-03-05 16:36:22 PST
Is the second patch supposed to be marked for review?
Comment 6 Joanmarie Diggs (irc: joanie) 2010-03-05 17:50:27 PST
Comment on attachment 49730 [details]
rest of the fix - includes additional layout test

I assume the bots will spit up on this one (seeing as how the first one is still in the commit queue and this patch assumes the first). But having said that, a review would be lovely. Thanks for asking, Eric.
Comment 7 WebKit Commit Bot 2010-03-06 06:40:43 PST
Comment on attachment 49704 [details]
proposed fix - includes layout test

Clearing flags on attachment: 49704

Committed r55623: <http://trac.webkit.org/changeset/55623>
Comment 8 Xan Lopez 2010-03-08 10:37:48 PST
Comment on attachment 49730 [details]
rest of the fix - includes additional layout test

Looks good to me.
Comment 9 WebKit Commit Bot 2010-03-08 13:06:14 PST
Comment on attachment 49730 [details]
rest of the fix - includes additional layout test

Clearing flags on attachment: 49730

Committed r55680: <http://trac.webkit.org/changeset/55680>
Comment 10 WebKit Commit Bot 2010-03-08 13:06:19 PST
All reviewed patches have been landed.  Closing bug.