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 15:04:19 UTC