[laptop-accessibility] Screen reader software -- any progress?

[Peter Korn]

Hi Timothy,

> Though I had not used orca before I had used the gnome accessibility
> tools.  Now, I'm not sure, I've either used both, or they are the same
> thing.  For me, orca is useless.  Magnification alone does not help me
> at all and tracking is infact harder for me with the weird "the screen
> is the minimap".  My grandfather, who has macular degeneration(and
> thus needs magnification) found that setting the dpi to be extra high
> was the least confusing.  I have used speech dispatcher quite a bit
> for my own personal scripts and with emacs' speechd.el In these
> scenarios, speech dispatcher-application communication was direct and
> no locational information was sent.  Given the nature of orca's
> magnifier utility, I assume that while locational information is sent,
> geometric information is not.  This actually leads to a bug when using
> orca with only the keyboard: text boxes are often focused by keyboard
> without the magnifier moving to show their labels.  

Have you filed a bug or RFE against Orca for this feature (including 
labels in the magnified field of view when Orca magnification is 
tracking focus changes)?  Also, when was the last time you played with 
Orca magnification?  In the last few weeks there have been significant 
changes in how Orca drives the GNOME magnifier (gnome-mag), and I 
believe Joanie Diggs is still actively soliciting feedback to her 
magnification updates to Orca.

> What I envision in
> my line based interface is that the screen would be in regions:
>
> empty | Normal   | empty
> empty | squished | empty
>         magnified
> empty | squished | empty
> empty | normal   |
>
> So the current line would be magnified IN PLACE, a small area above
> and below it would be squished, and the rest would be normal in size.
> This requires that we know the height of the current line as well as
> it's location.  The reason why I suggest squishing is simply that I do
> not believe it technically feasible to 'cut' the window in two and move
> the bottom half downwards to make way for the in place magnification.
> The reason I propose this be line based is that in place magnification
> would be weird if there was squishing on the sides as well.  The way I
> imagine things, the window manager could tell the window to be a
> certain amount less wide to make way for the wider magnified bar.
> Line based thinking also works well when we look at keyboard
> accessibility, especially navigating with the keypads on either side
> of the screen.  I do not think that these things will work out, though
> if we don't mandate line based navigation from the start.

Without question, a magnification system built into the window manager 
would have the ability to make some of these changes.  For the 
squished/magnified lens that you are suggestion, we probably will want 
the kind of functionality that we have in OpenGL (and to which the 
Compiz window manager is taking advantage of) - at least if we want such 
functionality to be performant.  If I'm not mistaken, that is not 
underlying graphics functionality we have on the OLPC XO.


Regards,

Peter Korn
Accessibility Architect,
Sun Microsystems, Inc.