RE: A table navigation technique

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.

-Chuck
-----Original Message-----
From: Scott Luebking [mailto:phoenixl@netcom.com]
Sent: Monday, November 16, 1998 5:33 PM
To: w3c-wai-ua@w3.org
Subject: RE: A table navigation technique


Hi,
Here are a few reasons I've come up with for making table serialization
a priority 1 item.

  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

  2.  a blind person can switch more easily among browsers and among
      access technologies

  3.  the blind person isn't forced to learn new table navigation each
      time he changes access technology

  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

  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

Can anyone else come up with other reasons?

Scott

Received on Monday, 16 November 1998 21:10:40 UTC