[Kde-accessibility] [Accessibility-atspi] Accessible objects without Atk dependencies

Olaf Jan Schmidt ojschmidt at kde.org
Wed Mar 29 15:17:23 CEST 2006


I agree with Richard and Bill that we need more people working on AT-SPI.

One of the reasons KDE developers did not contribute to AT-SPI so far is that 
we have very few people knowing CORBA, which makes contributing to AT-SPI 
very difficult for us - and seemingly for most IBM and Sun developers (apart 
from Bill and Peter) alike.

I know people who would love to use AT-SPI for KDE4-based assistive 
technologies, but currently there are no Qt/KDE bindings that allow us to do 

We have several options to create these bindings:

1. Write code that bridges the gobject-based AT-SPI bindings to QObject-based 
bindings, which probably involves solving the problem of having two event 
loops. This approach is a lot of work, and it is no fun, which means that 
volunteers are unlikely to work on it.

2. Write an IDL compiler that creates both gobject-based and QObject-based 
bindings for AT-SPI. This approach is more work than option 1 or 3, but it 
fits our agreed long term strategy. I don't know whether there are KDE 
developers who want to work on this, and it seems none of the GNOME 
developers are willing to contribute in the forseeable future.

3. Implement the AT-SPI API on top of DBUS, in addition to the CORBA version. 
Qt4/KDE4 applications will be able to talk to both versions, so the existing 
assistive technologies will not suffer. This is more work than option 1, but 
we could start with a subset of AT-SPI to quickly have workable results. Once 
the bindings are tested and stable, we can write the necessary bridges to 
make sure that application using the glib-based bindings can also talk to the 
KDE4-based assistive technologies (using option 1, option 2 or an external 
CORBA-DBUS bridge). It seems most likely to me that people would be willing 
to work on this.

Whenever I tried to convince KDE people to work on option 2 or 3, Bill 
objected saying that we should not work on a DBUS-version of AT-SPI at the 
current point of time. This gave me the impression that Bill favours option 
1, and this is why I asked when the number of dependencies on the existing 
AT-SPI implementation will be reduced.

I fully understand that Bill does not want to spend time on reducing 
dependencies if we are planning to move to DBUS anyway at some point in the 
future. What I don't agree with is discouraging KDE people (who would not be 
able contribute to a CORBA-based version anyway) to work on the DBUS port of 
AT-SPI, or calling this "NIH".

I know that Bill will be away for two months soon. Harald (who writes the 
AT-SPI bridges for Qt) will also be on holiday for some weeks. When both of 
you are back, then we will hopefully have DBUS support in the KDE4 
development versions, which will put us in the position to start implementing 
option 2 or 3.

[ Richard Schwerdtfeger ]
> Given the enormous task of managing the ATK/AT-SPI code base I believe Bill
> has done an incredible job.

I fully agree.

> Bill is an overwhelmed one-man band and we need to put more resources on to
> help rather than setting off a grenade.

Yes, we need more people contributing, and to achieve this, we must make sure 
that AT-SPI is as easy to use as possible. For KDE developers, means DBUS. 
Otherwise AT-SPI contributitions will stay limited to a very small number of 
full-time paid experts.

Please remember that accessibility is not only about blind people or severely 
impaired users. There is a huge number of needs - both for people with 
disability and for people without disabilities. Some of these needs can 
easily be met with small, modular tools. And some of these smaller tools can 
benefit a lot from AT-SPI if using it is not too complicated.

A good example for this is GOK. GOK is a very sophisticated assistive 
technology that works really great for people with severe mobility 
impairments. But at the same time, there are people with other disabilities 
that need an easier solution that can be used with the standard mouse. If we 
only look at the big assistive technologies, then we forget the need to make 
usage of AT-SPI simple enough for the authors of smaller tools.

[Bill Haneman]
> It also seems to be to be putting the "cart before the horse" to insist on a
> gnome-library-free accessibility stack before KDE application developers are
> willing to start testing their own applications' accessibility, or to start
> writing some AT-SPI based technologies.

I fully agree with you that it would be foolish not to test the accessibiilty 
of KDE applications because the tools are not native. At the same time, 
please keep in mind that most KDE developers are volunteers. Accessibility 
testing is not exactly fun, and this is why I want to make it as easy for 
them as possble. Every additional library and application that needs to be 
installed might prevent some developers from doing these accessibility tests 
- not because of bad intention or because of "NIH".  It would simply mean 
extra work to install the additional tools, and people would say "I'll do it 
later" and forget about it.

> For instance, I have taken another look at the libbonobo/bonobo
> dependency issues in the atk-bridge today (presumably this is one of the
> areas where KDE would most like to reduce the number of GNOME libraries
> linked in).  The dependencies do seem of a manageable size and sort, but
> on the other hand, libbonobo is not huge (about 1 MB), and you'd have to
> replace it with something (e.g. new code) if you removed it.  It's the
> sort of thing that a patch could be reasonably created for.
> Frankly I think a patch to remove the bonobo-activation dependency
> (replacing it with DBUS activation, presumably) would make a lot more
> sense at this time, in terms of cost/benefit.  That would be a nice
> opportunity for someone to fix the 'activation of remotely-displayed
> apps' problem as well, and to allow one AT-SPI registry per display -
> presuming DBUS can currently support that use case (i.e. per-display,
> user-agnostic activation and query).

Thanks for spending the time to come up with a specific suggestion where 
people might be able to contribute.


Olaf Jan Schmidt, KDE Accessibility co-maintainer, open standards 
accessibility networker, Protestant theology student and webmaster of 
http://accessibility.kde.org/ and http://www.amen-online.de/

More information about the kde-accessibility mailing list