Apache OpenOffice (AOO) Bugzilla – Issue 87532
[a11y] Expose table headings as such to ATs
Last modified: 2013-08-07 14:44:07 UTC
When you create a table in Writer, one of the things you can indicate is that the table has column headings and in which row(s) those headings belong. If the cells defined as the table's column headings could be exposed to assistive technologies as such (e.g. via table.getColumnHeader() and table.getColumnDescription()), screen readers could then automatically read those headers as a user navigated from column to column. In Writer, there does not seem to be an explicit way to define row headers for a table. But, at least visually, one can achieve the same effect by applying the Table Heading paragraph style. If that's all the dialog box is doing w.r.t. column headers, then would it be possible to similarly expose a tables row headers? Thanks in advance!!
Reassigned to Requirements
Trackback to the Orca bug: http://bugzilla.gnome.org/show_bug.cgi?id=524723
IIRC, when selecting heading (and also "repeat heading"_) in the table dialog, it should work. But please verify, and fix in 3.3 if it doesn't work then. At least from the ODF perspective in the file format it worked in that combination, as we figured out with the OASIS ODF Accessibility TC
Writer tables support column headers, but no row headers. The table column headers equals the repeated heading rows - see Menu Table - Table Properties, pane Text Flow - check box Repeat Heading The Writer's accessibility API provides for <XAccessibleTable> instances the column headers - see issue 77106 OD->AB: Please check, if our ATK bridge and our JAVA access bridge support a corresponding mapping of the Writer's accessibility API to ATK respectively JAVA access and if an extension of the Writer's accessibility API is needed. Thanks.
A short look into Writer's implementation of <XAccessibleTable> reveals its implementation of <XAccessibleTable::getAccessibleColumnDescription(long nColumn)> always returns an empty string. I assume that it shall return the text content of the table cells of <XAccessibleTable.getColumnHeaders()> for the given column. Right? If Yes, this needs to be implemented. It would support ATK method <AtkTable.atk_table_get_column_description(..)>. Right?
Getting the description would be OK, but getting the Accessible for the header would be desirable as well. From the Accessible, we should be able to obtain the text, but we can also use it as a means to help us determine if the header spans multiple columns or rows.
STARTED
There's already an implementation in the ATK bridge / atktable.cxx: table_wrapper_get_row_header table_wrapper_get_column_header returning the accessible cell in column 0 respectively row 0.
mt->od: returning cell/column 0 doesn't seems to be right. Might be correct in 90%, but IIRC there is some table API for getting the real cells/columns. Please make sure that the information that the Writer probably already exposes is handled by the bridge.
Investigation reveals the following: - Implementations of <atk_table_get_row_header(AtkTable, row)> and <atk_table_get_column_header(AtkTable, column)> in OOo's ATK-brigde are correct. The UNO-A11y-API methods <XAccessibleTable::getAccessibleRowHeaders()> resp. <XAccessibleTable::getAccessibleColumnHeaders()> are used. If the corresponding header exists the table cell of the first column resp. the first row is returned as an <AtkObject> instance. This is correct in cases where the row header resp. the column header consists of one column resp. one row. In the other cases nothing else can be done, because the corresponding ATK methods does not allow to return more than one <AtkObject> instance which would be needed if e.g. a column header consists of two or more table rows. Thus, nothing has to be adjusted here for this issue. - Implementations of <atk_table_get_row_description(AtkTable, row)> and <atk_table_get_table_description(AtkTable, column)> in OOo's ATK-brigde are also correct. They rely on UNO-A11y-API methods <XAccessibleTable::getAccessibleRowDescription(row)> resp. <XAccessibleColumnDescription(column)>. But the Writer's implementation of these UNO-A11y-API methods always return an empty string. Thus, nothing has to be adjusted in OOo's ATK-bridge for this issue. But the Writer's UNO-A11y-API implementation needs adjustment. - Writer table does not support row headers. Thus, the corresponding methods will return 'nothing' for a Writer table. Short summary: For this issue Writer's implementation of <XAccessibleTable::getAccessibleColumnDescription(column) will be corrected. Anything else is already working. Fix in progress in cws sw33a11y01.
solved in cws sw33a11y01 - changed file: /sw/source/core/access/acctable.cxx, change set 8b8c46488866
OD->ES: Checked in internal installation set of cws sw33a11y01 - please verify. To test you use the Accerciser: - create a Writer document with table which has a table header (Table - Table Properties - Text Flow - Repeat heading) - select in Accerciser's object hierarchy the table - perform the following commands in the Python console: -- acc.queryTable().getColumnHeader( <number of column starting counting with 0> ) -- acc.queryTable().getColumnDescription( <number of column starting counting with 0> )
Verified in CWS sw33a11y01
Closing accessibility issues which have been fixed, verified and integrated...