W3C home > Mailing lists > Public > w3c-wai-hc@w3.org > October to December 1997


From: Daniel Dardailler <danield@w3.org>
Date: Thu, 16 Oct 1997 07:04:05 +0200
Message-Id: <199710160504.HAA12425@www47.inria.fr>
To: w3c-wai-hc@w3.org

This is my attempt to converge on one TABLE proposal from Dave and Al

Added Dave's example for SCOPE and tried to regourp ref to the
LINK/META proposal and mention their relevance to RDF.

I think we need to be more compact for the HTML WG, closer to the DTD
diff format without going that far. Sort of a summary at the end.
We can work on that in the upcoming week.


TABLE     Making TABLEs comprehensible


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 go int hat 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.


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 group rows or columns
into related groups and 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

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">
    <TH colspan="5" scope="colgroup">Community Courses -
       Bath Autumn 1997</TH>
    <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>

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

The next row is marked up as:

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

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.


These are representative questions the Interest Group may wish to

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

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


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 01:04:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:35:00 UTC