KDE Accessibility • Inform • Home

Ideas For A KDE Accessibility Framework

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

Requirements For A KDE Accessibility Framework

The KDE accessibility framework pursued by the KDE Accessibility Project has to meet the following requirements:

  • Native KDE/Qt APIs for both assistive technologies and accessible applications
  • No extra work for developers that use standard GUI elements and widgets
  • Only a little extra work for developers writing custom widgets
  • Reasonable amount of work for the people implementing the accessibility interfaces
  • A Qt based solution rather than one working only with KDE
  • Interoperability with other toolkits
  • Support for assistive technologies on Mac OS X and Windows once applications are ported to run natively on these platforms (via Qt)
  • No extra dependencies for KDE or Qt itself
  • Reasonable dependencies for the accessibility libraries

Accessible Applications (AT servers)

On the side of the accessible applications, a new API is not needed, as we can use QAccessibleInterface once it has been extended by Trolltech to contain all the functionality needed to make GUI elements fully accessible. Once the next Qt version has been released, KDE can start to write QAccessibleInterface objects for those KDE GUI elements that need customized accessibility implementations.

In its current state, the Qt Accessibility Framework requires applications to provide a plug-in if they need to provide accessibility implementations of custom GUI elements. An easier API for applications providing only one or two custom widgets would be a method in each KWidget (or better QObject itself) that can be overloaded to return a subclass of QAccessibleInterface:

public *QAccessibleInterface QObject::accessibleInterface(); virtual;

The default implementation could search for an appropriate QAccessibleInterface in the loaded accessibility plug-ins.

Further information:

Assistive Technologies (AT clients)

For assistive technologies, we can define an API that provides all needed functionality using Qt and KDE objects. While Trolltech is working on extending the accessibility features in Qt, and while bridges to AT-SPI are still in development, the easier, more basic parts of the API can be implemented using direct DCOP communication to a Qt plug-in. Once the server side bridge to AT-SPI has been implemented and all Qt applications can be reached via AT-SPI, the client side library can be fully implemented by bridging to AT-SPI.

The API can be either written to match AT-SPI closely, or to match QAccessibleInterface closely. While using QAccessibleInterface looks like a nicer and cleaner solution at first glance, it has two important drawbacks: Not only that client side bridging is far more difficult, it would also mean that the definition of the API cannot be started before Trolltech has released the updated version of their accessibility framework.

Matching the API to AT-SPI would also leave the opportunity open to move AT-SPI onto D-BUS or DCOP if this should find the support by the GNOME Accessibility Project.

Further information:

Possible Roadmap

    • Define an assistive technology library API similar to AT-SPI
    • Maybe write a prove-of-concept implemention using DCOP
      (Assistive technologies using the API can now offer some functionality, but for Qt applications only)
    • Start to implement the assistive technology library
    • Trolltech releases the updated QAccessibleInterface
    • Implement the bridge from QAccessibleInterface to AT-SPI
      (Non-KDE Assistive technologies are now fully functional with Qt applications)
    • Finish the assistive technology library
      (Assistive technologies using the API are now fully functional with AT-SPI aware applications)

Global navigation links