Re: A table navigation technique

Hi, Charles

You have some interesting points, though I think I might be seeing things
in a different way with a different set of priorities.

I'm looking at the problem of access to web pages with a concern for
the blind person who is of average intelligence and with a moderate
interest in the web.  This person might be using web pages because they
are required as part of their work or school.  They basically
want to get the information of the page with the least amount of
learning and/or effort.

I believe that providing the method of table cell identifiers would address
a number of the table navigation needs of this type of user.  From
various informal tests I've done, people seemed to pick up the concept
of table cells having identifiers fairly quickly.  To find an
identifier, just ask the browser to look for a particular string.
(Certain types of frequent string searches could be more automated
by assigning them to keyboard commands.)

In your comment, you used the phrase "true table navigation".  I'm not
quite clear what that means.  How often do sighted individuals use
true table navigation?

A second concern I have was the phrase "allow the user to find out
where they are".  It is an interesting subtlety.  Browsers do not
have a sense of sighted people being at just one location in a table.
Often, access technology can have more of a sense of where a blind person
is focused on a web page.  For this reason, providing the table
navigation you are talking about in the access technology might make more
sense.

One concern I have is forcing the blind user to navigate a page
by elements in a document tree.  I do not object to giving blind
users the option of using document trees.  However, why should
a blind person be forced to learn about what elements mean,
document trees mean, etc?  A sighted person doesn't have to.
It's a lot for a blind person of average intelligence and motivation
to go through to get the same information that a sighted person gets.

Awhile back, someone designed an blind access method for windows
where the blind user would navigate through the window tree structure.
It failed miserably.  The designers had this idea that blind people
would just naturally want to learn about the window tree structure.
Many didn't.

I believe the best of both worlds would be for visual browsers to
provide built-in option-controlled table serialization with table cell
identifiers and column and/or row headers included in each table cell
representation.  This would provide a basic form of table navigation
with a minimal amount of learning required by blind users.  In addition,
the visual browsers provide an appropriate API for access technology
developers to get acces to the table information specified in the page's
HTML.  The access technology could then provided additional table
navigation techniques for those blind users who want them.

Scott

> True table navigation would allow the user to find out where they are in 
> the table, and would apply either the algorithm specified in HTML 4 or 
> use the TABLE attributes and elements to provide additional context, such 
> as headers which apply ot the current cell.
> 
> It would then enable movement to the next cell in a row or column, or 
> along an arbitrarily defined AXIS.
> 
> This is the kind of implementation that would be ideal.
> 
> A User Agent which allowed the user to navigate within a page by 
> element, traversing or ascending/descending the document tree, would 
> provide some of these functions. It would be possible to move across a 
> row, cell by cell, or to move up and down rows. This provides no context 
> information, and requires the user to remember where they are. This 
> strikes me as the minimum acceptable native implementation, assuming that 
> all the information is exposed for a 3rd party product which actually 
> does the job properly.
> 
> Charles McCathieNevile

Received on Saturday, 14 November 1998 19:24:32 UTC