Bug 30895 – [Gtk] The accessible hierarchy of tables is significantly incorrect for Atk

• Component: Accessibility
• Status: RESOLVED FIXED

[Joanmarie Diggs]

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.

[Joanmarie Diggs]

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.

[Joanmarie Diggs]

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....) :-(

[Joanmarie Diggs]

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.

[Eric Seidel (no email)]

Comment on attachment 49704 [details]
proposed fix - includes layout test

OK.

[Eric Seidel (no email)]

Is the second patch supposed to be marked for review?

[Joanmarie Diggs]

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.

[WebKit Commit Bot]

Comment on attachment 49704 [details]
proposed fix - includes layout test

Clearing flags on attachment: 49704

Committed r55623: <http://trac.webkit.org/changeset/55623>

[Xan Lopez]

Comment on attachment 49730 [details]
rest of the fix - includes additional layout test

Looks good to me.

[WebKit Commit Bot]

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>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.