[Kde-accessibility] Information about orca
blinux.list at thechases.com
Sat Jun 3 14:02:46 UTC 2006
>>In theory, it might be possible to create an X server that
>>intercepted the calls and made an internal representation of them
>>that was more accessible and navigable.
> But with your strategy, you need an OCR for getting the text that is
Like JAWS (and WindowEyes?), it would be intercepting the calls
to things like XDrawText where the actual text is being passed in
to the X server, before it has been rendered to the "screen".
However, as you pointed out (and I didn't know before you
mentioned it) UltraSonix's difficulty with applications bypassing
standard X calls, rendering to an image, and then just having X
render the image. It looks like such a solution would need to
patch not only X, but the Cairo rendering library, as well as the
GTK and KDE libraries, and possibly other rendering libraries
(such as xcompmgr, stuff from the Enlightenment window manager,
and possibly others).
> I don't know for sure, but I thought JAWS was using microsoft's MSAA,
> which is just what at-spi is.
They might be using both. My understanding (feable as it may be)
was that they started by intercepting GDI calls with their own
device-context/display-driver, catching various instructions for
rendering text to build an internal model of the screen. After
MS added their accessibility framework, they may have made use of
it (in addition, or instead).
Intercepting GUI stuff, unless designed from the ground-up to
support it and enforce it, is an ugly proposition. Unless
developers are forced to use it by way of API requirements, a
far-too-large percentage of developers will not take
accessibility into consideration when developing an application.
Thus, we end up with this ugly dichotomy of "accessible
applications" and "not so accessible applications". It's also
one of the beauties of console applications: because they all
write to a grid of text cells, everything is exposed as text
(okay, it takes going out of one's way to attempt to draw images
on a text-cell console) and that text can be navigated fairly
easily. As evidenced by yasr, screader, speakup, emacspeak, etc.
Thanks for the info about toolkits bypassing the X APIs for
drawing text. It's only 9:00am and I've already learned my
something new for the day. I guess I can go back to bed now. :)
More information about the Blinux-list