Re: [orca-list] F123.org-sponsored work and Request for input: Braille scrolling and when to route the caret

["S. Massy" <lists wolfdream ca>]

On Mon, Aug 06, 2012 at 07:47:45PM +0200, Joanmarie Diggs wrote:
> Hey all.
Hello. Long time brltty/Linux user and occasional Orca user here.
Mostly, I'll be rehashing what others have said, but still...

[...]
> One of the things I am fixing on the Orca side of the equation is
> braille scrolling of WebKitGtk content, and that brings me to my request
> for input:
>
> Currently, Orca's braille scrolling is in general incomplete and
> inadequate, sometimes working and sometimes not. But when it is working
Yes! Fixing this issue would definitely improve the orca experience with
braille by an order of magnitude.

> we are automatically moving the caret. I am seriously questioning if
> this is what we want to do for the following reasons:
>
> 1. Scrolling in braille seems to me to be an awful lot like scrolling
>    visually. In other words, if I am reading a document, I can leave the
>    caret where it is and move the document's scrollbar to look visually
>    before and after my current location and read the surrounding text.
>    If I then want to move the caret to a new location, all I have to do
>    is click with the mouse. But if I just wanted to look around and I do
>    not click, the caret remains where it was. Shouldn't Orca work this
>    way too, especially given the next item.
Yes, in general, what the user wants is to have access to a maximum of
information with a minimum of fuss (such as the screen-reader trying to
do the right thing unbidden).

> 2. Three words: Cursor routing keys. As I am scrolling around via my
>    braille display, all I have to do to reposition the caret is press
>    the key associated with the cell of interest. This is actually easier
>    than clicking with the mouse. Given that one can explicitly and
>    easily update the caret position, wouldn't it make more sense to only
>    move the caret when the user has indicated the caret should be moved?
This is the right thing to do. As someone else pointed out, the user
should need to switch his hands from display to keyboard and back as
little as possible.

> 3. Focus side effects: In the case of Web content, if we move the caret
>    to a focusable object, there is an excellent chance we will also
>    change the focused item. Changing focus without the user explicitly
>    indicating focus should be changed strikes me as a bad idea.
As I said in point 1, the screen-reader should avoid changing things
unbidden, hence changing focus automatically is clearly a bad idea.
OTOH, as I mentioned for point 2, the user should have to lift hands
from the display as little as possible, so a command to change focus
from the display itself would be a great feature.

Speaking of which, would it eventually be possible to be able to map
braille display commands to orca commands as is possible in brltty? Does
brlapi support passing raw commands through? The ability to use display
commands to quickly move around the screen real-estate would be a grand
thing. :)

Cheers,
S.M.