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

more on braille as the only output

From: Claus Thoegersen <cltrar@login.dknet.dk>
Date: Sun, 27 Sep 1998 13:33:01 -0100
To: w3c-wai-ua@w3.org
Message-ID: <dykD2U86l44N092yn@login.dknet.dk >


Here are some more thoughts on requirements for users who are relying
on braille as the only output from the ua. As far as I know non of
the specialized User Agents, made for disabled such as PWwebspeak or
the new IBM browser supports any braille device directly. If this is
correct the only means of getting braille output is to use a standard
browser and a screenreader that supports braille output. My own
experience is limitted to using JFW 3.0 and 3.2 with IE3.0 and

Some of the features that are needed for braille users may or may not
be supported by the screenreader, but as a previous discussion here
suggests it will be preferable to move as much of the special
rendering up into the browser as possible. 

Using the viewport for displaying text. With a braille display that
most often is limitted to 40 or 80 characters, therefore almost any
viewport will be able to show the user more information than what the
braille display can show. Therefore the braille user will have to
scroll through the text in the visible part of the viewport, by using
special commands or keys on the braille device.  When
the user reaches the buttom of the visible text, the braille user will
have to use a keyboard scrolling command. Since the braille user is
doing a lot more scrolling it would be nice if the viewport could be
scrolled with the same command the braille user uses to get more text
on the braille display. This was the reason for my suggestion for an
insertion point in the browser, because at least JFW would be able to
scroll the text by linking what HJ calls the braille cursor to the pc
cursor, but without an insertion point this does not work. Another
alternative is to be able to permanently maximize the viewport so you
limit the number of times the braille user will have to perform the
keyboard scroll command. By permanently I mean that this option would
be on each time you launch the browser. This is second best but of
course a lot easier than the scrolling method. Permanent maximization
will also benefit speech users and I would guess that many non
disabled users would like this feature as well. 

Keyboard definable selection.
3.3 in the current UA draft points out that the selection is a set of
elements identified for a particular operation. The question is now
do you identify the selection. An example could be you want to copy 3
lines from the visible part of a web page to the clickboard. If the
browser has an insertion point you can use the standard keyboard
based celection commands in Windows, but without an IP you are only
left with the drag and drop method that requires the screenreader to
be able to emulate the mouse functions, and the user to be familiar
with the drag and drop procedure. What is needed is a way to select
the selection from the keyboard. I do not know if this point needs
more attention in the UA, in the current browsers from IE and
Netscape it seems not to be
possible to perform this from the keyboard. 


Claus Thøgersen
Received on Sunday, 27 September 1998 15:32:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:20 UTC