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

A table navigation technique

From: Scott Luebking <phoenixl@netcom.com>
Date: Fri, 13 Nov 1998 22:09:50 -0800 (PST)
Message-Id: <199811140609.WAA06046@netcom6.netcom.com>
To: w3c-wai-ua@w3.org

(Note to screen reader users.  This message uses the period in different
types of representations.  You might want to be sure that your screen
reader will be reading the periods to you.)

Here's the approach I mentioned on the last telecom call.  When I was
working on my browser, one observation I had was that accessibility of
web pages could be significantly be increased by the browser's augmenting the
presentation of the web pages with various types of annontation.  A
benefit to this approach was that adding annotation is pretty simple
during the rendering phase.  Another benefit was that it reduced the
amount of work that had to be done by access technology.

This annotation approach could be used for providing simple table
navigation.  Each cell in a serialized table could be rendered with a
"table cell id".  One possible format is  t?.r?.c?. where each '?' is a
null string or a number.  The first number is a table number.  The
second number is a row number.  The third number is a column number.
(If a web page has only one table, the t?. part of the cell id could
be dropped.)

An example of a table with a television schedule could be written in a serial
format with table cell id's like:



    7pm - 7:30 pm

    7:30 pm - 8pm

    8pm - 8:30 pm



    financial update

    Sports summary


    Theatre of enlightenment

    Interview with Meryl Streep

    Early movies


The t1.r0.c0. id represents the beginning of the table while id t1.r.c.
is the end of the table.  (Table cell ids for the header rows and
footer rows would be written with 'rh' and 'rf' respectively replacing
the 'r'.)  (A useful browser feature would be to allow the blind user
to control whether serialized tables would include table cell ids.)

The blind user can then navigate through the table by using the basic
text searching functions of the browser.  (It has been interesting
seeing how some of the discussion on search versus navigation paralells
this approach.)  If the blind user wanted to go to the cell in row 5
column 4 in table 2, the blind user only searches for text string
t2.r5.c4.  .  If the blind user then wanted to go to the eighth
column in the same row, the blind user just searches for c8. .

If the blind user wants to move to the beginning of the first table, he
can search for id t1.r0.c0. . Now if he wants to go down the third
column, he searches for text string c3. . This can be made easier after
reaching the first cell in the third column by using the repeat search
key that browsers have or could have implemented.  Similarly, the blind
person could jump to the beginning of each cell by searching for text
string .c .  (Searching for the .c string might be frequent enough, that
the browser might want to bind searching for that text string to a

One slight draw-back is that there is a possibility that the text strings
may not be unique to cell table ids.  However, the design of the table
cell id format is such that the chances of a text string not being
a table cell id is quite minimal.

An additional benefit to the table cell id approach is that since the
cell ids are generated by the browser, a blind user can use the same
navigation technique without learning a new one each time he
switches access technology.

Received on Saturday, 14 November 1998 01:09:52 GMT

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