On Mon, 2004-08-30 at 23:22, Karsten Wade wrote:
Here's an example to illustrate the value of proper content
not worrying about the presentation:
One of your readers is very visually impaired. She has to use two
monitors set at 640x480 with large fonts and contrasting colors, and has
both a regular and Braille keyboard, and a Braille printer for output.
keyboard normally ~= soft braille display,
a beast that sits under the keyboard, with 40 or 80 character single
If your content was marked up with enough proper detail, an XSLT could
be used to get the XML ready for a custom low-vision reading system that
* Take the <programlisting> blocks and send them intact to the reader's
monitor and Braille output printer (both configured to receive STDOUT);
this lets her see them on screen and confirm what she reads with Braille
As it does with any html, wrapping only the content which is not marked
as preserve space.
The problem with big magnification is that panning is usually
mandatory, since (worst case I've seen) fewer than 20 chars are
visible on the screen at once?
Special stylesheets won't help in cases like that.
* Take the <gui...> elements and display them in a properly nested
fashion to STDOUT, similar to the way they give us File -> Edit -> Foo,
that could be a visually descending tree done in a very big font.
Except that a person whose reading media is tactile is restricted to
tty class of output? I.e. line at a time, hence they need to
keep any 'visual' structure in their heads whilst reading.
* Take the <screen> and <computeroutput> tags and send that content
straight to the console and Braille keyboard (STDIN), while teeing it to
STDOUT for confirmation via monitor and Braille printer.
I've never seen software or devices which split output like that
Karsten. Assistive technology on Linux is quite good at accessing
And if current trends are maintained, the combination of braille output
and low vision tools is a waste of time.
The number of people learning braille is diminishing.