RE: more on braille as the only output

Claus,

In my additions to the keyboard navigation issue, I pointed out that the
current UA guidelines refer to focus and selection, but need another "point"
in the document, which I called "point of regard."  (I think I got that term
from Greg Lowney, at Microsoft.)  The point of regard is the part of a
document currently being attended to by the user.  This is somewhat
different than an insertion point in that insertion into a web document
doesn't make sense.

If the browser has a movable point of regard, which works very much like
what you are calling an insertion point, then text could be highlighted by
moving the point of regard to the beginning of a block of text, activating a
"select" command, and moving to the end of the block of text. I would think
that, for a speech output browser, the point of regard would always be at
the word or character being spoken.  Similarly, for a braille output
browser, it would be at the beginning or end of the displayed text.  At the
bottom of the viewport, a "move down" command should move the point of
regard as well as the viewport down in the document.

For a visual/graphic display of a document, point of regard is a bit more
difficult to identify, since the user may actually be looking at any point
in the viewport.  But so long as the point of regard is movable via keyboard
commands as well as mouse commands, I don't see this as a problem.

Denis Anson

-----Original Message-----
From: w3c-wai-ua-request@w3.org [mailto:w3c-wai-ua-request@w3.org]On
Behalf Of Claus Thoegersen
Sent: Sunday, September 27, 1998 10:33 AM
To: w3c-wai-ua@w3.org
Subject: more on braille as the only output



Hi,

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
IE4.01.

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.

Regards

Claus Thøgersen

Received on Monday, 28 September 1998 08:25:58 UTC