Re: lynx-dev new tables idea for SoCR

[Lloyd G. Rasmussen]

At 10:01 PM 7/14/99 -0400, you wrote:
>>     * Subject: Re: lynx-dev new tables idea for SoCR
>>     * From: Heather Stern <address@hidden>
>>     * Date: Wed, 14 Jul 1999 16:43:15 -0700 (PDT)
>>     * In-Reply-To: <address@hidden> from "Larry W. Virden"
>>       at "Jul 14, 1999 7: 0:23 pm"
>>   
>>Larry W. Virden wrote:
>>> As long as this is only one of many ways of producing tables, it wouldn't
>>> bother me for it to be there.
>>>
>>> One of the methods of outputing tables needs to keep the user who has
>>> screen speaking software active so that tables are output in _some_
fashion
>>> that makes sense when they are being read...  The trick is that this
>>> _MAY_ need  to be dynamically switching from column first to row first,
>>> since people insist on using html in manners not really in its first
>>> nature.
>>
>>Ah, hopefully you have experience with them then.  Do you like method 1
>>(deeper indents per column) or method 2 (some sort of "spliiter" tag shown
>>at cell breaks, a special one at row ends) better for screen reading?
>>In my admittedly untutored opinion, the first, since it leaves paragraphs
>>as they sit, and doesn't introduce any fluff characters but spacing.  Your
>>opinion?
>>
>
>Heather, I like the basic idea of a stair-step format in lieu of tabulation.
>
>Tables-to-audio is a pretty hot topic.
>
>The new Home Page Reader from IBM sets a high standard for making tables 
>comprehensible in audio.  You might want to get one and get the idea of 
>how it works.
>
>As far as experience, I think I have more than Larry and I have just enough
>to know I don't know enough.  By this I mean, put the page mockups in 
>plain text files on the web somewhere and ask politely on
address@hidden 
>and maybe on the blinux list at redhat what people think of the options.  
>I hope Lloyd will agree that is a good plan.
>
  Yes, I do agree that you might get some good feedback over on Webwatch.
address@hidden is also supposed to be about browsers and screen
readers, but it is pretty inactive.

The stairstep format is one of the allowable table renderings in recently
adopted North American braille rules.  Given that we have a braille line
length on paper of 38 or 40 characters, we use two characters per level.
It gets pretty useless at about the thirteenth column, and sometimes wastes
a large amount of space.

I'm glad to see people thinking about table rendering.  Lynx's current
behavior of decolumnizing tables which are used for layout (because of
their embedded <br>'s, has been emulated by several Windows screen readers,
and people are ecstatic about the results most of the time.  But when you
get a table which is displaying real data, those screen readers keep on
decolumnizing, and you will have a hard time finding your way around the
data. 

I have HPR version 2.5 on this computer, and admit that I *must* learn how
it does tables.   

I run my speech screen reader with Lynx with punctuation and format
notification turned off, so I might not even notice some of the changes you
are proposing.  But these attributes are hard to turn off if you are using
a braille display, where people are accustomed to having more of the print
format exposed anyway.  I think very few blind Lynx users have a line
length (on screen) different from 80 characters.  But if they are using a
braille display or magnification software, they will be seeing half of that
line or less at a time.

To see a draft of work we  are doing on producing accessible electronic and
digital audio books, you can check out 
  http://www.loc.gov/nls/niso/
It's a work in progress, but we think XML is where it's going to be at.

Lynx still rulz!




Lloyd Rasmussen, Senior Staff Engineer
National Library Service f/t Blind and Physically Handicapped
Library of Congress    (202) 707-0535  <address@hidden>
<http://www.loc.gov/nls/>
HOME:  <address@hidden>   <http://lras.home.sprynet.com