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

TABLE discussion (-starter DRAFT)

From: Al Gilman <asgilman@access.digex.net>
Date: Wed, 15 Oct 1997 13:42:57 -0400 (EDT)
Message-Id: <199710151742.NAA17219@access5.digex.net>
To: w3c-wai-hc@w3.org (HC team)
Cc: jbrewer@w3.org
TABLE     Making TABLEs comprehensible

BACKGROUND:

Tables have been a serious problem for people using audio
browsing.  This is aggravated by poor 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 group rows or columns
into related groups and this should be used to guide browser
functions that list table contents.

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 LINK:
strawman operational model is available.

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 proposed LINK and META extensions allow authors and the WAI
working groups to experiment with other forms of markup as well.
See the REF&META discussion for more on this.

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.

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 Wednesday, 15 October 1997 13:43:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:56:11 UTC