GNOME Bugzilla – Bug 639486
Table cells should know their index, coordinates, and spans (and possibly the parent table)
Last modified: 2011-05-28 23:29:47 UTC
Executive Summary: * Table cells know nothing about their position * ATs get events from table cells and need to report the position Long Version: When a user who is blind is navigating amongst cells in a table, he/she is often interested in knowing the coordinates of a given cell and, in the case of tabular data, whether or not a given cell spans more than one row and/or column. In order for a screen reader to provide that information to the user, it must first work out one of two pieces of information: 1. The cell's coordinates (which the cell doesn't know*), OR 2. The cell's index (which the cell doesn't know*) *You can obtain the coordinates if you have the index, and the index if you have the coordinates, by querying the AtkTable interface of the appropriate ancestor, which brings me to: Once you've obtained one of the aforementioned pieces of information, you must then locate the parent table in order to find out the rest. Locating this object is at times challenging (see bug #639479). But for the sake of this bug, assume we've ascended the accessible hierarchy and eventually located the appropriate ancestor which implements the AtkTable interface. If we started out (somehow) knowing the coordinates of the cell, we can get the row span with one call, itable.getRowExtentAt(), and the column span with another call, itable.getColumnExtentAt(). Personally, I don't think this is great, but it's not horrible. Unfortunately, we often don't have the coordinates; all we know is that a table cell just received focus and we want the coordinates and span. In that case, we must figure out the cell's index. Because originally an object of ATK_ROLE_TABLE was assumed to have as its immediate children all of the cells within that table, ATs could in turn safely assume that a cell's index was the same as that object's index in the parent. With the addition of intermediate objects (e.g. table rows), it is clear that we need some other, reliable means to get the cell index. Atk currently provides none. (Gecko exposes this information as an AtkObject attribute named 'table-cell-index' FWIW.) Once we've obtained the correct cell index, and located the parent table, we can use a pyatspi convenience method, itable.getRowColumnExtentsAtIndex() which doesn't exist in Atk itself (which I mention since making Atk and AT-SPI more similar has been mentioned as a good idea). I am of the opinion that if ATs most likely need this information because the AtkObject representing a table cell emitted some signal, it would be really nice if that same object could tell us its index, coordinates, and span so that we could just report it to the user. And perhaps there'd be value if the cell pointed to its parent table, too. At the very, very least a means to obtain the index of a cell should be added to Atk so that we can obtain the desired information through the ancestor table using the existing methods (getRowExtentAt(), getColumnExtentAt(), getRowAtIndex(), getColumnAtIndex(), getRowColumnExtentsAtIndex()).
UI Automation has an IGridItem interface like this: int Column { get; } int ColumnSpan { get; } IRawElementProviderSimple ContainingGrid { get; } int Row { get; } int RowSpan { get; } There is also an ITableItem which is like IGridItem but also has methods to retrieve row and column headers. Anyway, we could define an AtkTableItem interface with get_row, get_row_extent, get_table, get_index_in_table, etc.
See also IAccessibleTableCell Interface http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/interface_i_accessible_table_cell.html
(In reply to comment #0) > Because originally an object of ATK_ROLE_TABLE was assumed to have as its > immediate children all of the cells within that table, ATs could in turn safely > assume that a cell's index was the same as that object's index in the parent. > With the addition of intermediate objects (e.g. table rows), it is clear that > we need some other, reliable means to get the cell index. Atk currently > provides none. (Gecko exposes this information as an AtkObject attribute named > 'table-cell-index' FWIW.) By searching the gail code, I didn't find gail put any intermediate objects into the tables' children list. Does any other ATK implementation do this? Or do you mean expander?
(In reply to comment #3) > (In reply to comment #0) > > > Because originally an object of ATK_ROLE_TABLE was assumed to have as its > > immediate children all of the cells within that table, ATs could in turn safely > > assume that a cell's index was the same as that object's index in the parent. > > With the addition of intermediate objects (e.g. table rows), it is clear that > > we need some other, reliable means to get the cell index. Atk currently > > provides none. (Gecko exposes this information as an AtkObject attribute named > > 'table-cell-index' FWIW.) > > By searching the gail code, I didn't find gail put any intermediate objects > into the tables' children list. Does any other ATK implementation do this? Or > do you mean expander? I think that Joanie is specifically thinking on Gecko. (In reply to comment #2) > See also IAccessibleTableCell Interface > http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/interface_i_accessible_table_cell.html FWIW, gail has defined gailcell.h used to implement a11y support for gailtreeview. He has some subclasses really tied to gtktreeview like gailbooleancell, and so on, but I also used it for the implementation of HildonCalendar. One option would be try to use the current implementation of gailcell as the base implementation for a hypothetical AtkTableCell.
See: https://live.gnome.org/Hackfests/ATK2011/Agenda/table for conclusions from the ATK Hackfest.
Li, I saw that you signed up on the ATK Hackfest agenda page to do this for Gtk/Gail. Thanks! In addition to the changes in Gtk/Gail, however, we need: 1. The ATK implementation (i.e. adding what we are going to "steal" from IA2) 2. Documentation of the changes so that we can point to the docs when filing bugs against the other toolkits. Are these things also something you can do?
(Sorry for being spammy today. Must be something in the air....) In order to attempt to break up this "table cells suck" bug into discrete, manageable, bug-like tasks, I have just opened bug 651353 for the implementation of AtkTableCell interface based on IA2.
So.... 1. Bug 651353 addresses the implementation of AtkTableCell. 2. Bug 639479 addresses the need to document the agreed-upon recommended hierarchy. 3. Bug 651358 addresses the need to document that table {active-descendant, selection}-changed events should include the table row in event.any_data. 4. The only other thing on https://live.gnome.org/Hackfests/ATK2011/Agenda/table is "Evaluate IA2 Table Interface to see if we missed anything". With respect to the last item, I don't think there is. These two seem to provide very similar implementations: *http://developer.gnome.org/atk/unstable/AtkTable.html *http://accessibility.linuxfoundation.org/a11yspecs/ia2/docs/html/interface_i_accessible_table2.html As a result, I don't see a need to keep this bug open given that we have bugs for all the table issues.