- From: Scott Luebking <phoenixl@netcom.com>
- Date: Fri, 13 Nov 1998 22:09:50 -0800 (PST)
- To: w3c-wai-ua@w3.org
Hi, (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: t1.r0.c0. t1.r1.c1. Times t1.r1.c2. 7pm - 7:30 pm t1.r1.c3. 7:30 pm - 8pm t1.r1.c4. 8pm - 8:30 pm t1.r2.c1. CNN t1.r2.c2. Viewpoint t1.r2.c3. financial update t1.r2.c4. Sports summary t1.r3.c1. Bravo t1.r3.c2. Theatre of enlightenment t1.r3.c3. Interview with Meryl Streep t1.r3.c4. Early movies t1.r.c. 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 key.) 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. Scott
Received on Saturday, 14 November 1998 01:09:52 UTC