RE: priorities on table techniques

It seems we may be confusing issues and techniques here.  The essential need
is to be able to obtain the contents of a cell of a table, and to know its
relationship to the contents of other cells in the table.

Retrieving contents without stirring them up between cells is obviously a
major issue.  Knowing that this content lies to the right of that content,
and below this other content is a separate, but equally important issue.
(I'd say that, for some tables, the context is every bit as important as the
contents of a cell.)

Serializing tables to provide access is one way to provide access to the
content, but at the sacrifice of some of the information about context.  I
was talking with Larry Scadden at the RESNA board retreat this weekend,
discussing how we might provide access to tables.  I described serializing,
and he felt that he could "put it back together" after it had been
serialized, but that this would be an additional cognitive load.  Less
successful blind folks might not be able to intrinsically put the table back
together.

It seems as if the ideal solution would be to have a user agent/screen
reader that read cells in situ, and also provided cell-to-cell navigation
via keyboard control.  That is a technique.  So is serializing tables.

Denis Anson

-----Original Message-----
From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On
Behalf Of Scott Luebking
Sent: Friday, November 13, 1998 3:04 PM
To: asgilman@access.digex.net; w3c-wai-ua@w3.org
Subject: Re: priorities on table techniques


Hi, Al
Please forgive my not responding sooner.  I got caught up with trying
figure out why JAWS was not recognizing web pages created by javascript

One reason why I believe that table navigation is as important
as access to cells' contents is related to needs of particular
audiences.  I agree with you that many tables are used for
layout.  However, blind people who are students or in work environments
often have a need to navigate tables because of their studies or employment.
An inability to do table navigation could seriously impact their
endeavors in these areas.

I'm not convinced that providing table navigation via element navigation
is sufficient.  Learniing to navigate elements may be a harder task
for people than is being realized.

Scott

> 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
> equally.
>
> 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.
>
> Al

Received on Friday, 13 November 1998 16:02:48 UTC