UA Techniques on Tables

Current contents on tables from 1999-03-31 draft

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

HB: gains -gain-

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

HB: omit ... " is discouraged"

[Checkpoint 5.4.1] Provide access to the contents of a specific table cell.
[Priority 1] 
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 
table                        of the 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]). 

[Checkpoint 5.4.2] Provide access to header information for a specific table
cell. [Priority 1] 

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 should provide users with
header information and other contextual agent. Techniques include:
·       Provide this information through an API. 
·       Ignore table markup entirely. This may assist some screen readers. 
·       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
point
of regard 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. 
Since not all tables are designed with the header information, a conforming
user agent should provide, as an option, a "best guess" of the header
information for a cell. Possible strategies include: 
·       Consider the top and left-most cells of a column or row to be header
information. 
·       Consider upper and left-most cells which have formatting markup to be
header information. 
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. 


Table navigation
Users of non-visual rendering technologies and users with learning
disabilities, when browsing a page, should be able to quickly determine the
nature of a table located on a page. The able-bodied user is able to visually
examine the table and extract a sense of the table contents with a quick scan
of the cells. A non-visual user, or a user with difficulty translating printed
material is not able to do this. Providing table summary information in the
caption, when first moving the point-of-regard to a table allows the nature
of a
table to be easily determined. 

An auditory rendering agent, when the point-of-regard moves to a table, might
say, "Table: Tax tables for 1998," thus identifying the nature of the table.
The user could then use keyboard commands to move the point of regard to the
next logical block of information, or use a different command to "burrow" into
the table. 
The "burrow" command should have an opposite "pop" command, which would move
the point of regard from an individual cell to the table as a whole, so that
the user can leave a table from any cell within it, rather than navigating to
the end. 
If the user "pops" up to look over the summary information, it should be
possible to "burrow" back to the same cell.
 
When navigating a table that contains another table, this strategy can avoid
confusion. For example, if each row of a table contained five cells, but the
second row contained a 4x4 table in the third cell, a user could be disoriented
when the row did not end as expected. However, when the point of regard moved
to the third cell of the table, a compliant browser would report that this was
a table, and describe its contents. The user would have the option of
navigating to the forth cell of the parent table, or burrowing into the table
within this cell. 

[Checkpoint 5.4.3] Allow the user to navigate among tables in a document.
[-Tnav-sequential] [Priority 2] 
When rendering tabular information, the fact that it is tabular information
should be apparent. For a visual user agent, such information is commonly made
obvious by the border attribute. However, for a non-visual agent, such
information must also be made appreciable. 

As the user agent shifts the point of regard to a table, it should first
provide information about the entire table. This information might be the
Caption, Title, or Summary information of the table. Access to this information
would allow the user to determine whether or not to examine the contents of the
table, or to move the point of regard to the next block of content.

HB: The caption element is appropriate to describe the table in its 
context. The title attribute on the table is an alternative to the caption for
an 
informal table that does not have a caption. The summary attribute information
is expected to be the more descriptive of the table structure. The user agent
can present information in that order, skipping any without content. The user
agent
in the absence of the summary information may synthesize the table structure
description from counting rows and columns. If heading cells are present, the
summary can indicate their content and any available abbreviations for them.
The headings should be provided first across rows, possibly those in the THEAD 
and separately the TFOOT sets of rows, then those heading cells that provide
row
stubs. 
 
[Checkpoint 5.4.4] Allow the user to navigate among table cells of a table
(notably left and right within a row and up and down within a column).
[Priority 1] 

HB: For internationalization, be prepared for tables with rtl (right to left)
writing language, reversing the normal cell progression direction.

In many data tables, the meaning of the contents of a cell are related to the
contents of adjacent cells. For example, in a table of sales figures, the sales
for the current quarter might be best understood in relation to the sales for
the previous quarter, located in the adjacent cell. 

In order to provide access to contextual information for individuals using
non-visual browsers, or for individuals with certain types of learning
disabilities, it is necessary for the user agent to allow the point of regard
to be moved from cell to cell, both right/left and up/down via keyboard
commands. 
The most direct method of performing such navigation would be via the cursor
keys, though other navigation strategies might be used. 

HB: Motion across rows and along columns must consider spanning cells, as
achieved
by the rowspan and colspan attributes on TH and TD cells. The actual content
only
appears in the first such cell in the writing direction of the table.


Regards/Harvey Bingham

Received on Wednesday, 7 April 1999 12:00:31 UTC