This appeared on the Uaccess-l mailing list out of the Trace R&D
Center. Maybe some of you have some ideas you would want to share
regarding the viewing of tables with speech and braille.
-- Lloyd Rasmussen, lras@loc.gov, l.rasmussen2@genie.com
----- Forwarded message begins here -----
From: dnewers <dnewers@facstaff.wisc.edu>
To: Multiple recipients of list <uaccess-l@trace.wisc.edu>
Date: Mon, 18 Dec 1995 18:17:49 -0600
Subject: Making tables accessible to screen readers
The following E-mail messages are Trace internal memos on the
subject of making tables accessible to persons who use screen
readers. We are posting them to this listserv with the hope that
anyone who reads them and has some input they would like to offer
would do exactly that. Any comments and/or suggestions you have
will be appreciated.
MEMOS
Neal, I've been looking through the HTML 3.0 specifications
working document and I have found some interesting things about
how tables will be implemented. One of the claims they make is,
"cells can be merged across rows and columns, and include
attributes assisting rendering to speech and braille." how nice
of them eh? The way they plan to make rendering to speech
possible is to include AXIS and AXES attributes for cells. These
attributes will be used to provide abbreviated names for the
headers relevant to each cell. From what I remember of our
conversations, this won't make tables a whole lot more readable.
What ideas do you have about making tables readable? Should we
suggest that people find a way to present the information in text
also? give me your thoughts oh wise one! --w
Hi Wendy,
Below are a few possible alternatives for presenting tables that
are accessible to screen readers. Braille displays have some
different needs which we can go in to at another time.
1. Separate lines for each table entry presented with their
column or row heading. Tables are difficult in that the screen
reader will most always read the entire row of data with no pause
between each entry on the row. We have come up with strategies
at trace to make tables work with screen readers when we did the
open enrollment insurance booklets for the Employee Trust Fund of
the state of Wisconsin. This consisted of having each column or
row entry, depending on which way you were viewing the table, on
a separate line with the label of that entry preceding the data.
Thus, if you were looking at a table which contained the column
headings of "Name," "Street," and "City/State," your entry would
look like:
Name: John Smith
Street: 2234 Braille Street
City/State: Madison WI 53705
There would be a blank line before the next entry in the table so
that people who downloaded the file could use their DOS screen
reader to search for the next occurrence of two carriage returns
and thus be taken directly to the first entry on each row.
(Windows screen readers are not very good at allowing a person to
search for returns.)
I believe this format would not work well on the web, because it
would take too many screens of very short lines to reproduce each
table. What we really need is a utility which used the html
"table data: tags to produce an accessible version of the file
once it was down-loaded and processed with the utility. Or is
there an easy way to do an on-line conversion for the people who
need it and are willing to scroll down the number of screens it
might take to present the information?
2. Another option is to publish a lot of helpful hints on how to
make screen readers work more effectively with tables. Many
screen readers allow the user to set up macros or configuration
files which cause the speech to read a specified window on the
screen. Such a window can be as large as the entire screen, or
as small as a single table entry. The problem is that these have
to be set up to read specific portions of the screen. For
example, the user might set up a window to read line 3, from
column 45 to column 60. It doesn't take much imagination to
realize that this procedure would have to be re-done each time a
different table with different column and row positions was
encountered. What a bummer.
One screen reader, Vocal-Eyes, makes this a bit easier with what
they call floating windows. I'll be doing more experimenting
with this in the future.
3. A third option is to set up windows in a screen reader which
get read each time a particular portion of text triggers them.
This is the kind of window which is often set up in, for example,
the wordperfect speller. When the screen reader sees the text at
the top of the screen which notifies it, and the sighted user,
that the information below is a part of the speller, the screen
reader loads a configuration to better read that particular
window. So, could one place certain text boundaries between
columns and rows which would cause the screen reader to
understand that it was entering a different window each time it
got to new row or column information? The user would simply press
the key he or she had designated as the "next window" command and
the screen reader would read whatever was in that window. You
could probably work out a strategy to have the screen reader read
columns, individual rows, etc. Again, this would take some time,
and in that there are a lot of screen readers on the market for
which configuration files would have to be written, this is not a
very practical solution for helping lots of people at one time.
4. Another alternative would be to present tables just as they
are presented to the sighted user but with a "comma" or a
"period" after each entry. This punctuation would at least cause
the screen reader to pause after each column instead of reading
all the numbers in one non-pausing string. This doesn't do much
for dealing with information which wraps to the next one or more
lines, and it doesn't offer any really effective way for finding
a particular cell in the table.
More later. I'm off to a meeting.
Neal
Please address any comments you have on this topic either to the
listserv or directly to me at "dnewers@facstaff.wisc.edu." Thank
you very much for taking the time to read and possibly comment on
this issue.
!
*****
Neal Ewers
Field Coordinator
Trace Research and Development Center
Room S153 Waisman Center
1500 Highland Avenue
Madison, WI 53705
Phone: 608-262-6966
Internet: dnewers@facstaff.wisc.edu
To subscribe to the uaccess listserv, send a message to
listproc@trace.wisc.edu. In the body of the message, type
subscribe uaccess-l firstname lastname.
------ Forwarded message ends here ------
Lloyd Rasmussen
Senior Staff Engineer
National Library Service f/t Blind and Physically Handicapped
Library of Congress 202-707-0535
lras@loc.gov
This archive was generated by hypermail 2b29 : Sun Dec 02 2012 - 01:30:03 PST