Augmented User Agent Techniques for Tables
based on User Agent Techniques 19991029

Review by Harvey Bingham

Metanotation:

_insert_

XdeleteX

HB: ... new material

3.3 Table techniques

Tables were designed to structure relationships among data. In graphical media, tables are often rendered on a two-dimensional grid, but this is just one possible interpretation of the data. On the Web, the HTML TABLE element has been used more often than not to achieve a formatting effect ("layout tables") rather than as a way to structure true tabular data ("data tables").

Layout tables cause problems for some screen readers and when rendered, confuse users. Even data tables can be difficult to understand for users that browse in essentially one dimension, i.e. for whom tables are rendered serially. The content of any table cell that visually wraps onto more than one line can be a problem. If only one cell has content that wraps, there is less problem if it is in the last column. Large tables pose particular problems since remembering cell position and header information becomes more difficult as the table grows.

User agents facilitate browsing by providing access to specific table cells and their associated header information. How headers are associated with table cells is markup language-dependent.

Tabular navigation is required by people with visual impairments and some types of learning disabilities to determine the content of a particular cell and spatial relationships between cells (which may convey information). If table navigation is not available users with some types of visual impairments and learning disabilities may not be able to understand the purpose of a table or table cell.

3.3.1 Table rendering

A linear view of tables -- cells presented row by row or column by column -- can be useful, but generally only for simple tables. Where more complex structures are designed, allowing for the reading of a whole column from header downward is important as is carrying the ability to perceive which header belongs to which column or group of columns if more than one is spanned by that header. It is important for whole cells to be made available as chunks of data in a logical form. It might be that a header spans several cells so the header associated with that cell is part of the document chunk for that and each of the other cells spanned by that header. Inside the cell, order is important. It must be possible to understand what the relationships of the items in a cell are to each other.

Properly constructed data tables generally have distinct TH head cells and TD data cells. The TD cell content gains implicit identification from TH cells in the same column and/or row.

For layout tables, a user agent can assist the reader by indicating that no relationships among cells should be expected. Authors should not use TH cells just for their formatting purpose in layout tables, as those TH cells imply that some TD cells should gain meaning from the TH cell content.

When a table is "read" from the screen, the contents of multiline cells may become intermingled. For example, consider the following table:

This is the top left cell    This is the top right cell 
of the table.                of the table.

This is the bottom left      This is the bottom right 
cell of the table.           cell of the table.

If read directly from the screen, this table might be rendered as "This is the top left cell This is the top right cell", which would be confusing to the user.

A user agent should provide a means of determining the contents of cells as discrete from neighboring cells, regardless of the size and formatting of the cells. This information is made available through the DOM [DOM1]).

HB: _Note that the table representation in the DOM is hierarchic: rows contain cells. Information about a TD cell needs to find corresponding information not only by row, but by column, so special means to find corresponding positions in different rows is important._

3.3.2 Cell rendering

Non-graphical rendering of information by a browser or an assistive technology working through a browser will generally not render more than a single cell, or a few adjacent cells at a time. Because of this, the location of a cell of interest within a large table may be difficult to determine for the users of non-graphical rendering.

In order to provide equivalent access to these users, compliant browsers should provide a means of determining the row and column coordinates of the cell having the selection via keyboard commands. Additionally, to allow the user of a non-graphical rendering technology to return to a cell, the browser should allow a means of moving the selection to a cell based on its row and column coordinates.

At the time the user enters a table, or while the selection is located within a table, the user agent should allow an assistive technology to provide information to the user regarding the dimensions (in rows and columns) of the table. This information, in combination with the summary, title, and caption, can allow the user with a disability to quickly decide whether to explore the table of skip over it.

Dimensions is an appropriate term, though dimensions needn't be constants. For example a table description could read: "4 columns for 4 rows with 2 header rows. In those 2 header rows the first two columns have "colspan=2". The last two columns have a common header and two subheads. The first column, after the first two rows, contains the row headers.

Some parts of a table may have 2 dimensions, others three, others four, etc. Dimensionality higher than 2 are projected onto 2 in a table presentation.

The contents of a cell in a data table are generally only comprehensible in context (i.e., with associated header information, row/column position, neighboring cell information etc.). User agents provide users with header information and other contextual information. Techniques for rendering cells include:

Provide this information through an API.

Render cells as blocks. This may assist some screen readers. Using this strategy, the user agent might render individual cells with the relevant top and side headers attached.

Allow navigation and querying of cell/header information. When the selection is on an individual cell, the user would be able to use a keyboard command to receive the top and left header information for that cell. The user agent should appropriately account for headers that span multiple cells.

Allow users to read one table column or row at a time, which may help them identify headers.

Ignore table markup entirely. This may assist some screen readers. However, for anything more than simple tables, this technique may lead to confusion.

3.3.3 Cell header algorithm

User agents should use the algorithm to calculate header information provided in the HTML 4.0 specification ([HTML40], section 11.4.3. (This algorithm assumes left-to-right direction). Here it is slightly amplified, shown in _..._ :

• First, search left from the _TD _cell's position to find row header cells. Then search upwards _from the TD cell's position_ to find column header cells. The search in a given direction stops when the edge of the table is reached or when a data cell is found after a header cell.
• Row headers are inserted into the list in the order they appear in the table. For left-to-right tables, headers are inserted from left to right, _including values implicitly resulting from TH cells in prior rows with ROWSPAN="R", sufficient to extend into the current row_.
• Column headers are inserted after row headers, in the order they appear in the table, from top to bottom_, including values implicitly resulting from TH cells in other columns with COLSPAN="C", sufficient to extend into the current column containing the TD cell_.
• If a header cell has the headers attribute set, then the headers referenced by this attribute are inserted into the list and the search stops for the current direction.
• Cells that set the axis attribute are also treated as header cells.

HB: Note that that algorithm isn't explicit in the following cases:

• Propagating the TH identifying information to the subsequent R-1 rows below a row where some TH cells have rowspan="R" where R > 1.
• Propagating the TH identifying information to the subsequent C-1 columns for TH cells that have colspan="C" where C > 1.
• It fails to recognize columns at the right, or rows at the bottom containing TH cells.
• It doesn't say to use any value of the abbr="abbreviation" attribute on TH cells in place of that cell content itself.
• It doesn't address what implicit information from TH applies to a TD that itself contains ROWSPAN="R" or COLSPAN="C" for R > 1 or C > 1.
• It ignores cases where the effective number of TH cells difers among the TD cells, particularly one where either ROWSPAN or COLSPAN values are greater than one.
• It ignores the direction (row or column) that an embedded TH in the middle of TD is to stop search for other TH.
• It ignores the table attribute dir="rtl" whose effect is to reverse the order of columns in a row.

HB: end incomplete algorithm issues

HB: In a table with leading row and column of TH cells, the interpretation of the top-left cell as an empty TD or TH should not contribute to the set of headings that are used to identify the implicit information for TD cells in a table.

Since not all tables are designed with the header information, user agents should provide, as an option, a "best guess" of the header information for a cell. Note that data tables may be organized top-to-bottom, bottom-to-top, right-to-left, and left-to-right, so user agents should consider all edge rows when seeking header information.

Some repair strategies for finding header information include:

• Consider that the top or bottom row Xto Xcontains header information.
• Consider that the leftmost or rightmost column _or both_ in a column group contains header information.
• If cells in an edge row or column span more than one row or column, consider the following row or column to contain header information as well.

The user may choose the form and amount of this information, possibly announcing the row heads only once and then the column head or its abbreviation ("abbr") to announce the cell content.