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

RE: A table navigation technique

From: Scott Luebking <phoenixl@netcom.com>
Date: Mon, 16 Nov 1998 19:59:12 -0800 (PST)
Message-Id: <199811170359.TAA08900@netcom11.netcom.com>
To: chuckop@microsoft.com, w3c-wai-ua@w3.org
Hi, Chuck

I don't disagree with your point, that they are universal issues.  However,
why not try to fix the problems when possible?

You asked whether all browser would support table serialization.  It depends
on whether each browser wants to follow the guidelines.  (I've been told
by at least one browser developer that it would probably be fairly easy
to implement table serialization.)

Actually, unrolling a table isn't that hard.  I did my version in 2 days.
It is easier than the more general version of a "text only" view.
I believe that writing a guideline for unrolling a table to be quite
readily achievable.  (I've been working on one.)

Scott

> Most of these are universal problems, not specific to browsing or tables.
> 
> <<
>   1.  a blind user doen't have to worry about whether the access technology
>       being used has the necessary table navigation functions for
>       the browser being used
> >>
> 
> Same is true for working with Microsoft Word or Corel WordPerfect ("Does
> this screen reader support X software?")
> 
> <<
>   2.  a blind person can switch more easily among browsers and among
>       access technologies
> >>
> 
> So all the browsers are going to support this?
> 
> <<
>   3.  the blind person isn't forced to learn new table navigation each
>       time he changes access technology
> >>
> 
> The blind person needs to relearn EVERYTHING when switching access
> technology!  The better question is this - why should the browser have one
> model of table navigation and word processors or any grids have different
> models?  By exposing the information - the accessibility aid can provide a
> consistent keyboard model for all applications.
> 
> <<
>   4.  the blind person isn't forced into using some access technology
>       which may not be as desirable as some other preferred technology
>       just because the preferred access technology does not support
>       table navigation for the desired browser
> >>
> 
> The information is available.  Any screen reader can use it if they choose
> to.
> 
> <<  5.  the blind person has a back-up arrangement in case the access
>       technology runs into a bug when using Active Accessibility for
>       table navigation
> >>
> 
> Bugs can happen everywhere.  FYI - Active Accessibility is in the same .DLL
> as the main browser.  From a testing perspective, Active Accessibility is
> going to get a heck of a lot more coverage than a little used feature.
> 
> What if our way of rendering the table isn't acceptable?  What if Netscape
> and IE do it differently?  Aren't you back at square one?
> 
> There are so many minute differences between the way browsers display tables
> and styles and everything now, and they have a very large set of documents
> describing how to do it.  Will the guideline also contain a specification
> for unrolling?  The Authoring Tools group has a similar problem -
> recommending how to show a page in "text only" view.  What does text only
> mean in this case?  What is a unrolled table?
> 
> Unrolling a table isn't a matter of removing <TABLE> and </TABLE>, there are
> heuristics to apply, and a lot of reformatting.
> 
> I bet the way JAWS for Windows currently unrolls a table will be different
> from the way a another screen reader presents it, which is different than
> the way LYNX does it.  That's exactly the benefit of accessibility aids -
> they are answering their customers needs and desires, each with their own
> particular style that fits into there own philosophy of access.
> 
> So unless the rest of the group feels this merits additional discussion,
> I'll bow out now.
Received on Monday, 16 November 1998 23:00:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:48:38 GMT