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

[Tim hobbs]

On orca:  I tried orca the day that I sent that email.  However I did
so on an ubuntu box which I hardly ever use and have not updated for
about a quarter.

On the squished behavior, I had anticipated that response.  I would
imagine that since the Sugar Activity will already be providing text
to the screen reader software, that the magnifier could use this text
as well, and instead of doing bitmap magnification, show the text as
say
size 12
size 9
size 22
size 9
size 12

Also, if one is to wish to magnify icons, and or images, and thus
bitmap magnification is necessary, than for the purposes of context
and not an eye candy smooth squish, bit map squishing can be done
along side quite as easily as the bit map magnification:

1.0
0.5
2.0
0.5
1.0

If the XO is capable of computing the magnification to 2.0 than I
can't imagine that there would be that much extra strain put on it by
squishing two other rectangles to 0.5...

Thank you
Timothy

On Feb 11, 2008 10:13 PM, Peter Korn <Peter.Korn at sun.com> wrote:
> 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.
>
>
> _______________________________________________
> accessibility mailing list
> accessibility at lists.laptop.org
> http://lists.laptop.org/listinfo/accessibility
>



-- 
-
Tim
tim.thelion at gmail.com