[Kde-accessibility] my crazy thoughts

[Bill Haneman]

Hi all:

Thanks Phillippe for your thoughtful message.  I think you have a good
grasp of the issues we/KDE are facing (I suppose by "we" I mean Linux
accessibility folks generally).

> > The best corba implementation seems to depend on Gnome, so, using at-spi
> corba 
> > direct won't save me from depending on Gnome.
> 
> Is it Gnome, or just Orbit + GObject ? That's different.

ORBit2, which uses glib (which includes gobject).  You could use any
CORBA ORB that works, but ORBit2 is probably the winner for free
desktops.

> > I've found that ATK uses GObjects which I am still trying to understand (I
> 
> > asked for help in #gnome and #gtk+ on irc.gnome.org, but I didn't get any
> help :| )

yes; could be a timezone thing too.

 
> Read the developer.gnome.org tutorials. Helps a bit.
> 
> > But what really surprised me is that AT-SPI is developed in Gnome by Gnome
> 
> > developers too. It is not the generic way I thought it was.
> 
> I would say that ATK was introduced in Gnome by Sun, which is very
> different. Accessibility is supported by Sun.

Yes; there was no standard (and virtually no prior work) for
accessibility on Linux or Unix prior to ATK; there was Java
Accessibility (which Peter Korn has been a major part of), but Java
Accessibility didn't at that time export itself outside the Java VM
except on Windows, so even Java was without a suitable *nix
accessibility API.
 
> > Then I thought why is everybody else using AT-SPI when it is a Gnome
> thing. 

Well, it lives in GNOME CVS but from the outset it was designed to work
with multiple toolkits and platforms.

...
> I do not agree. Sun has interests in Java and in Gnome, true. It does not
> make Java related to Gnome, though. OpenOffice is developed by Sun too. So
> it seems that AT-SPI and ATK has indeed been brought not by Gnome but by Sun
> to us. And that they have chosen Gtk and Orbit as their toolkit to bring
> that.

Well, ATK and CORBA, anyhow.  We implemented the APIs for GTK+ and Java
first, since that is Sun's target accessibility platform, along with
Mozilla and OpenOffice.org.  Also, note that one of the driving factors
in the accessibility work Sun and other companies have been doing is the
US "section 508" regulation, which is being adapted and adopted in
ever-increasing areas, and which will serve as a major influence on
expected regulations around the world.  These requirements are specific,
detailed, and rigorous, and are one reason why we sometimes speak of a
particular accessibility API or capability as being "required" rather
than just "helpful" or "useful". 

> I don't know about this one. Mozilla uses a generic toolkit portable to many
> platforms (XUL engine). They are certainly not using Gtk in the way Gnome
> does. In fact, there even was once a Qt port of Mozilla.
> 
> If Mozilla has done things properly and I imagine they did, mozilla
> interfaces with ATK not at the level of their Gtk widgets but at a higher
> GUI level. Mozilla is supposed to have a very versatile GUI which you can
> script in many ways. I hope they have put the ATK accessbility at the
> generic GUI level.

This is correct, they are only touching the GTK+ "ATK" code at a very
trivial level.  In this respect Mozilla is doing something very similar
to what KDE would need to do in order to 'bridge' to ATK.

...
> You are wrong. DCOP has been designed not to depend much on KDE. It depends
> on Qt and X11 only. And some people thought about removing this dependancy
> to make it more reusable. Bindings for C and python were developed, to
> ensure that other projects could use it.

Similarly we have Python bindings for ATK, thanks to James Henstridge. 
I believe Murray Cummings has done C++ bindings for ATK too, for those
who prefer them ;-)

. 
> There are things you need to take into account:
> 
> - standard:
> How standard is AT-SPI ? And ATK ? Two gnome programs use it already and
> they will enable access to Mozilla, OpenOffice and every Gnome application.
> Does this apply to any Gtk application ? Are there other accessibility
> toolkit apart from ATK ?

All GTK+ applications that use GTK+-2 work with ATK and AT-SPI "out of
the box", that is, without any additional coding.  As far as I know the
only other accessibility toolkit or API-set available for Linux/Unix is
the Java Accessibility API, whose implementation is not LGPL and which
isn't available outside of a Java VM.  We have written a "java bridge"
which bridges/exports the Java interface to AT-SPI, and this is how
ATK/AT-SPI/etc. works for Java applications.

> 
> It seem to me that ATK/AT-SPI is an accepted standard, even if it is new. If
> some application already use it, it would be a pity that they don't work
> with KDE. Or are you going to develop similar applications in KDE ? And if
> those helper applications are develop, they must be able to access Mozilla,
> OpenOffice and Gnome. So whatever happens, an AT-SPI access is needed.

Yes; and to meet 508 requirements, to actually make complex programs
like web browsers, email clients, and GUI-based spreadsheets usable by
blind and physically challenged people requires a lot of code.  The
existing GOK and Gnopernicus projects, nearing their first "complete"
release, are quite complex pieces of code.  I do not forsee independent
KDE equivalents being feasible with the current level of resources, even
if we put aside the question of whether that would be the most effective
solution for end-users.

> - relationship to Gnome:
> How is accessibility development related to Gnome ? Moving it to a more
> neutral place like freedesktop might help to loosen things a bit. I suppose
> the license is the LGPL.

License is LGPL on all of this code.  Moving it doesn't make sense at
this time, but as I have already discussed there was broad support for a
rename.  We just haven't done the formalities to change the name to "GNU
Accessibility Project", though RMS has indicated interest in our work
before.
 
> - technical:
> I suppose AT-SPI is very generic. Is it true for ATK too ? Qt has a
> promising architecture, which might be easier to use than ATK.

I think that ATK is relatively easy to use, and am not sure that any
architecture that provides equivalent functionality could be made much
simpler.  Thus I question whether duplicating the code and effort makes
sense.  Also, if one uses something other than ATK, an entirely new
bridge to AT-SPI would be needed, which would re-introduce the need to
do difficult CORBA coding.

> You are facing a decision that KDE has faced a few times: do we use existing
> technologies or do we develop our own ? Many times, KDE has chosen its own
> technology: dcop and KPart vs Corba and Bonobo, KOffice vs OpenOffice, khtml
> vs Mozilla/Gecko.
> 
> However, accessibility is not as simple as these other decisions. Whether
> KDE uses dcop or Corba only concerns KDE because this is internal to KDE.
> Accessibility is opening KDE to external applications. There seem to be
> existing applications that use AT-SPI to provide accessibility and there are
> projects that use AT-SPI to be accessible. 

Yes, absolutely.
 
> We probably don't want the author of accessibility applications to write
> their applications twice, once for AT-SPI, and once for a KDE or Qt
> framework.

It's unlikely that the authors would do so, even if it were practical.
 
> From the information I have gathered so far, I would say that AT-SPI is
> unavoidable. You need it. And you don't have many choice to access it. It is
> either Corba or ATK, both having some drawbacks.
> 
> Bill, could you clarify on the relationship between ATK and Gnome ? What are
> the applications using ATK/AT-SPI today and were they already using Gnome ?

ATK is now used by GNOME applications, GTK+ applications (including
those that don't use any other parts of GNOME), and Mozilla; there may
be others of which I am not aware.  The Java accessibility API is used
by OpenOffice.org, which is then bridged to AT-SPI; this was done to
provide a cross-platform solution since OO.o runs on Windows as well as
*nix, but Qt need not do this since it already has a Windows
accessibility solution and I am sure you don't want to require a Java VM
for each KDE application ;-)  Mozilla used GTK+ already, but only in a
trivial way (as you point out Phillippe, the Mozilla widgets use XUL,
not GTK+).  There is interest in eventually providing a direct-to-AT-SPI
bridge for OO.o, bypassing the JA-API for efficiency reasons.

There have been suggestions about using ATK in other toolkits as well
but I am not at liberty to say much about them and in fact don't know
the current status.  I would say that the main reason that other
non-GTK+ applications don't do this yet is lack of developer resource to
do the work.   ATK was designed from the outset to be
non-GNOME-specific; we did accept a dependency on glib as an acceptable
tradeoff since the alternative would have required ATK to invent its own
object model, which would have been wasteful of resources and of course
would have appeared silly to GNOME.  Likewise, we designed AT-SPI to be
CORBA based since CORBA is in our opinion the only truly
platform/language/OS-independent IPC mechanism with sufficient richness
to express the needed APIs.  Thus AT-SPI works with Java, C, C++, and
Python, potentially on non-Unix and non-Posix operating systems as well
as on Linux and Solaris, and is potentially network-transparent as well.
 
best regards,

Bill

> 	regards,
> 
> 	Philippe