TABLE discussion

TABLE     Making TABLEs comprehensible

BACKGROUND:

Tables have been a serious problem for people using audio browsing.

Today HTML pages use tables for two purposes: to layout pages,
and to present tabular information. Both uses present
accessibility problems.

When tables are being used purely for visual layout, the issue is
mainly one of reading order and style sheet are probably the best
way to improve accessibility in that situation. This message will
focus on how to improve the browsing experience for tabular
information.

Tabular information generally consists of headers and data. Imagine
using a speech-based browser to examine a table designed for visual
browsers. If there are more than just a few cells it will be easy to
forget the headers as you move from cell to cell. If there was some
way of knowing which headers are appropriate to this cell, then
perhaps you could ask for these headers to be spoken, either on
request, or automatically when you move to a new cell. This will work
much better if the author has been so kind as to provide abbreviations
for headers.

We also need to improve communication between applications and screen
readers.  Sometimes what browsers do to de-tabulate table contents
works better than the tabular presentation; sometimes you really have
to browse the material in its two-dimensional pattern of relationships
to get what you are being told.

The HTML working group has introduced new features in version 4.0 to
fix this situation, and the HC working group has recommended that the
WAI ask for a little more.


PROPOSAL:

The WAI Browser Guidelines group should seek functions from
browsers which break down a table into alternate presentations.
One useful alternate presentation is a hierarchical list such as
is used for listing tables of contents.  

The WAI Markup Guidelines group should develop recommended CLASS
values to be used in TABLEs to indicate when tables should be read by
rows, when by columns, and whatever other structural classes they find
necessary to guide the selection of non-tabular presentations.

The AXIS attribute in HTML can be used to associate table cells
with a conceptual category such as dates, expense catetories,
etc.  This can be done on the individual cell or indirectly by an
AXIS value on a header cell which describes a cell in the body of
the table.  This should be used to guide browser functions that
list table contents.

For audio browsing it is important to have a clear indication
outside the visual layout of which headers go with which body
cells in a table.  The SCOPE and AXES attributes, together with
defaulting rules, should be used to capture this information.
The WAI Browser Guidelines and Markup Guidelines can be used to
clarify defaulting rules and compatible markup practices using
SCOPE, AXES and CLASS.

The proposals for specifying which headers are relevant to each
cell are designed to allow these headers to be grouped and for
these groups to be ranked. This is intended to give implementors
the freedom to treat the table as a hierarchy that is independent
of the visual layout chosen for windows based browsers. The idea
is to allow large and complex tables to be browsed in a similar
way to browsing file system directories, with the ability to
hide or expose levels of detail.

The scope attribute allows authors to state whether a given header
applies to the current row, column, row group or column group.
This takes advantage of new table features in HTML 4.0 for
specifying column properties and for grouping rows and columns.
Scope works well for most simple tables. Here is an example:

 <TABLE summary="History courses in Bath arranged by course name, 
                  tutor, summary, code and fee">
  <TR>
    <TH colspan="5" scope="colgroup">Community Courses -
       Bath Autumn 1997</TH>
  </TR>
  <TR>
    <TH scope="col" abbr="Name">Course Name</TH>
    <TH scope="col" abbr="Tutor">Course Tutor</TH>
    <TH scope="col">Summary</TH>
    <TH scope="col">Code</TH>
    <TH scope="col">Fee</TH>
  </TR>

The summary attribute is used to summarise the role and structure
of the table:

   "History courses in Bath arranged by course name, 
    tutor, summary, code and fee"

Each row is represented by the TR element. The first row contains
column headers. These are marked up using the TH element, each of
which has scope="col" to indicate its role as a column header.
The abbr attribute is used to provide an abbreviation for longer
headers.

The next row is marked up as:

  <TR>
    <TD scope="row">After the Civil War</TD>
    <TD>Dr John Wroughton</TD>
    <TD>
       The course will examine the turbulent years in England
       after 1646. <EM>6 weekly meetings starting Monday 13th
      October.</EM>
    </TD>
    <TD>H27</TD>
    <TD>&pound;32</TD>
  </TR>

The TD element is used to markup each data cell. The first cell
in the column gives the course name. Since this is considered
to be helpful when browsing subsequent cells in the row, it has
been marked up with the scope attribute, this time with scope=row
to indicate that its relevant to the rest of the current row.

The scope attribute is of limited generality. For cases where
it breaks down, we propose an attribute called "axes" that is
used to list the ID's of all relevant headers. The name is based
upon the idea of thinking of tabular data in terms of values
at points in an n-dimensional space. The headers then form
marks along the axes of this space. An attribute called "axis"
is used to supply a name indicating which axis a given header
belongs.  Scope and axes are interelated and implementors are
likely to map them both into the same internal model of which
headers are relevant to each cell.

Finally, there is interest in being able to associate tables
with meta-information that describe richer semantics about
the table.

The WAI Browser Guidelines group should seek functions from
browsers which support browsing tables on a cell-by-cell basis.
Moving through the table by one or some number of cells up, down,
backwards, and forwards are desirable.  

A more extensive strawman operational model is available.
See the REF&META discussion for more on this, in particular how it
relates to RDF.

The W3C should ensure that a table can be linked to a data
dictionary or other resource providing additional documentation
of the data usage in the table.  One way to do this in HTML is to
provide the capability through LINK elements.  See the REF&META
discussion for more on this.

Finally, the SUMMARY attribute should be suitable to be spoken after
the CAPTION element, when there is a CAPTION for a table.  This should
be made clear in the WAI Markup Guidelines, and in the prose of the
HTML specification as well.

QUESTIONS:

These are representative questions the Interest Group may wish to
discuss.

How would the proposed markup be applied to this table (give
URL)?

Who has experience with browsers that support cell-by-cell
browsing, and how did it work?

FOLLOW UP:

Please discuss this issue by sending email to w3c-wai-ig@w3.org .
Include the symbol TABLE in the subject heading of your message,
to help other subscribers organize the volume of mail we hope
this will generate.

Received on Thursday, 16 October 1997 13:23:10 UTC