Click here for new and improved Digest layout. Same information but organized differently. Suggestions welcome.

What can we expect from KDE on the Accessibility front? Harald Fernengel gave a presentation at aKademy titled Making Qt KDE Applications Accessible (Slides, Audio, Video).

As mentioned in the other accessibility talks, API based accessibility function is the best way. And as we review the plans for Qt accessibility, we see why.

The goals of Qt Accessibility Module is to make applications accessible by default, with no or little impact on existing code. There will be no performance penalties where accessibility function is not required. Harald gave an example of an application where if accessibility was enabled, but it took considerably longer to load. Hence the administrators would disable the accessibility function.

The accessibility features are on by default. All widgets are supposed to be accessible. Subclasses would inherit accessibility function from super classes. The interface can be plugins which permit on the fly loading. An accessiblility bridge will bridge to other api's, MSAA, at-spi, etc.

Hence, custom widgets are accessible. There is no need for an independant patch for accessiblility. If special accessibility interface is required for your custom widget, all you need to do is ship a plugin. The accessible bridges are plugins.

Here is the class reference for QAccessible.

The difference between Qt and AT-SPI is there isn't necessarily one interface per widget. For example, all the children of a combobox can have the same accessiblility data.

Qt also defines relations, ie Label -> linedit, and linedit -> label.

Permits navigation to next child, above, below, left or right. Tab order is not enough for rapid navigation.

QAccessible has a generic action interface. You can define how many custom actions the widget supports, Action text, in short and long format and Do action which executes.

For example, buttons have the predefined actions such as click, but a custom widget can implement it's special actions.

Advantages:

1. Low memory, just a pointer to the widget.
2. Children don't need accessibility object.
3. Generic: no special interfaces to specific assistive technologies. Binary compatible, reimpoiment functions, ship a plugin.
4. New widgets can be accessible without modifying assistive technology.
5. Accessible interface knows when it is needed, loads on demand.

In Qt Designer, accessible texts can be set by non technical people, and localized.

Question: How would a mixed language environment work? AT-SPI doesn't implement this. Generic texts methods return text with meta information, provider must provide meta info.

Peter Korn added that some shouldn't be translated, for example the state, since the assistive technology, ie. a screen reader depends on a text string to determine state.

All widgets and backend classes are accessible ready. Document-View class is ready.

Slides then showed the bridging strategies to either AT-SPI, which needs 15-20 packages from Gnome. The Qt bridge is open to new backends, for example dbus. The bridge tranlates Qt to at-spi or whatever is necessary. That already works. There are issues with Qt metadata since AT-SPI doesn't support metadata, For example an email reader, there is metadata such as block, level 1, level 2. How to tell Screen reader? Rich text is another example.

Harald then demonstrated the Qt->AT-SPI bridge, using a Qt demonstration application and Gnopernicus. He then showed the beginnings of a Qt->D-BUS bridge, where instead of using the Corba backend to communicate between the applications, D-BUS will be used for message passing. This would allow a Qt or KDE application to be accessible to someone using the Gnome accessibility tools.

In my opinion, these bridges have the potential of consuming unreasonable computer resources. Peter Korn mentioned during his presentation that the screen reader wasn't responsive enough, presumably due to the resource heavy inter process communication backend. Of course it would be preferable for KDE and Qt users to have available the necessary accessibility tools, which would take advantage of the inherent inter process communications, but that may not be a reasonable expectation at least in the near term. So the advantages of a light weight cross desktop communications bus are clear. We shall see if D-BUS fills that role adequately.

Mark Kretschmann announced version 1.1-beta2 of the amaroK audio player

Jeroen Wijnhout announced the first public beta release of Kile, an Integrated LaTeX Environment for KDE