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

priorities on table techniques

From: Al Gilman <asgilman@access.digex.net>
Date: Wed, 11 Nov 1998 19:36:48 -0500 (EST)
Message-Id: <199811120036.TAA00937@access2.digex.net>
To: w3c-wai-ua@w3.org

In today's telecon I suggested that being able to read the text
content of a table cell by itself takes a priority even greater
than having browser support for understanding the place of that
cell in the table.

Scott demurred.  He suggested that both should be required

There is probably a good argument for either of those statements.

The reason that I see a difference in priority has to do with two
things: the prevalence of layout tables and the fact that text in
layout tables is read line by line and not cell by cell by enough
screen readers.

There is a lot of illegible text on the web because of the
interleaving of text from different columns.  I believe that this
is so severe a problem that user agents should be asked not only
to expose the document structure per DOM 1 through an API but
also to include presentation controls which will serve to isolate
cells when operated with legacy screen readers.  Partly, this is
because I believe that such techniques are readily achievable,
and hence we should ask for them.

I do not equate this with structure transforms or linearization.

Linearizing the table after the simple manner of the Lynx
formatting is sufficient, but not necessarily necessary, to find
relief from this problem.

Another technique would be to have the functional equivalent of
display=none for all document content that is not in the focussed
element, and support element navigation at least enough so that
table cells were always focusable.  This is a combination of
element navigation that is part of a more general strategy that
is being pursued for a variety of reasons, and dynamic styling
that would appear to be on the agenda of the users agents for
reasons of market demand.  

One way to look at it would be to say the priority 1 requirement
is to solve the text interleaving problem.  Automated assistance
in understanding the structure of "true" tables is important, but
I am not sure it rises to Priority 1 if there is adequate support
for generic element navigation, and styling the current
vs. background content.

A debatable point is whether API support is enough, or whether
redundant techniques that work with legacy screen readers should
be sought.  Perhaps the latter is a Priority 2.

If as a policy matter it is desired to suport relief that works
with legacy screen readers as well as using the API to offer
relief, there is a contest between structural transforms and CSS
implementation i.e. presentation control, as to how the problem
is solved.

It may make sense to ask the browser implementation community to
comment on the relative difficulty of a structural transformation
vs. a style-control-based approach.

Received on Wednesday, 11 November 1998 19:36:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:21 UTC