[Kde-accessibility] Information about orca

[Tim Chase]

>>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
> displayed.

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).

Yuk.

> 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. :)

-tim