KDE Accessibility • Inform • Home

KDE And Assistive Technologies

This introduction was written by Olaf Jan Schmidt as part of our development efforts for interoperable accessibility solutions.

About Assistive Technologies

Most applications are written for users capable of seeing the screen, and of using both a keyboard and a mouse in normal speed. For a number of people, this expectation creates huge obstacles, and in the last years, a lot of specialized assistive technologies have been written to allow a user to access the computer using braille devices, screen readers, on-screen keyboards, eye tracking devices, head pointing devices, two and three button devices, etc.

Why Special Interfaces Are Needed

A typical problem when developing these assistive technologies was that it is often very difficult to convert the graphical information on a screen into something that can be read out by a screen reader or spelled out on a braille display. And while specialized input devices can simulate a mouse or a keyboard, graphical user elements often behave in ways that make it tricky to find emulation techniques that work in all situations without problems.

As a result of these problems, special interfaces for assisitive technologies have been created on different platforms. All GUI elements of an application can be accessed via these interfaces, so that all assistive technologies work with all applications and vice versa. This way, assisitive technologies need not try to emulate keyboards and mice or guess how a screen representation can be converted to pure text, but can rather directly access all GUI elements of an application and show them to the users in other, more accessible forms.

Existing Solutions

The Windows version of Qt has support for an accessibility interface through the Qt Accessibility Framework, which is currently being extended by Trolltech to also include all functionality required by Mac and Unix solutions. This would allow Qt to forward all necessary information about GUI elements to the different accessibility solutions on Windows, Mac and Unix.

On Unix, the cross-toolkit AT-SPI (Assistive Technologies Service Provider Interface) interprocess communication protocol is being used by GTK2, Java and OpenOffice. It was developed by the GNOME Accessibility Project as a way to connect GNOME's accessibility solutions with other toolkits. AT-SPI is very powerful and is the only existing solution for communication between accessibility aware applications and assistive technologies on Unix. Based on CORBA, it allows assistive technologies to access all of the graphical user interfaces of an application, abstracting from toolkit dependent GUI objects.

Further information:

Obstacles And Advantages of a Bridging Solution

From a KDE perspective, a bridge between Qt and AT-SPI has two problems and one huge benefit. The first problem are dependencies, as the AT-SPI registry currently requires GTK2+. It should be possible to reduce these dependencies to glib and ORBIT2, but this might perhaps require rewriting large parts of it. These would not be dependencies for KDE itself, but only for running assistive technologies.

A second problem is the need to use CORBA in assistive technologies. This requirement could be avoided by offering a native KDE API through an accessibility library speaking CORBA, so assistive technology developers do not have to learn CORBA. Another solution that has been suggested is to move AT-SPI to a different IPC like D-BUS, but this still needs to be evaluated.

The benefit of a bridging solution would be interoperability between assistive technologies, which we believe to be a crucial element of any interface for assistive technologies.

Interfaces for assistive technologies only make sense if they are widely supported by several toolkits, so you can use one assistive technology to access all the applications you use. Otherwise you would end up with the need to install several braille device drivers in parallel, and to constantly switch between them, if that is technically possible at all. Or you would have to run several on-screen keyboards at the same time for accessing several applications written with different toolkits. Or the application you need won't run at all with the assistive technology you also need.

For similar reasons, it is necessary that the interface contains all the functionality needed by different assistive technologies.

Further information:

Why Native APIs Are Needed

Support for our accessibility effords is far more likely if the APIs used are not felt to be alien to KDE. This does not mean that we have to refuse neat cooperation and AT-SPI support for KDE, but it means that an API for assistive technologies needs to be created using Qt and KDE objects.

The KDE Accessibility Project cannot implement a full accessibility solution without the help of the general KDE community. These documents aim at providing the necessary information to find an architecture that is accepted by the KDE core developers, Trolltech and those who have already implemented AT-SPI support. If any crucial ideas or arguments have been left out, please send a mail to the KDE accessibility mailing list so this website can be updated.

We (as KDEAP) will only participate in effords that allow for bridging to AT-SPI. At the same time, we are aware that writing the necessary bridges might take a long time. It would be wrong to discourage direct use of the Qt Accessibility Architecture until the bridges are finished. But if future cooperation with other toolkits is not to be ruled out, a possible migration path to a later bridging solution must be possible. This can be accomplished by defining KDE APIs for assistive technologies that are close enough to AT-SPI to make later bridging as easy as possible.

Further information:

Global navigation links