The state of free accessibility

Hello all. As some of you may have read at osswatch, or in Jeanie's open letter to Oracle, or even from mark doffman of codethink (or experienced yourself in some cases) the state of free accessibility technology is somewhat lacking as of late. I've spent some time investigating the various players, testing solutions, discovering what's out there, etc. and would like to give an account of how things are from my perspective as a KDE developer and as one who would like to see desktop accessibility on Linux and our other platforms flourish.

First maybe an introduction of the key pieces of this puzzle would help.

The first piece of the puzzle from a KDE developer's perspective is Qt's Accessibility classes here. As part of QtGui module most (maybe all) Qt widgets are accessible as far as they can be. They all provide description, state, role, and actions in Qt's way that allows them to be "seen" via accessibility on Windows, should allow them to be "seen" on linux/unix via at-spi2 (will discuss this piece a bit later) and allows them to be "seen" with carbon builds on Mac also (accessibility for cocoa is a feature request that has not been scheduled at the moment). So as far as gui developers are concerned, as long as existing Qt gui widgets (or derivatives) are used, we should be in good shape. Unfortunately, the next piece falls a bit short.

The next piece of the puzzle is the qt-atspi2 bridge. This is in the works and can be found here. This takes the form of a qt plugin backend for qaccessible. It bridges the gap between qaccessible classes and at-spi2 dbus interface. Though Mark Doffman at codethink has done amazing work here. The latest version is not quite ready to work with at-spi2 because of recent changes in at-spi2 itself.

The final piece of the puzzle for kde/Qt apps is at-spi2 itself. This has been developed quite a bit by various members of the gnome-accessibility community. I know Mark Doffman spent some time optimizing some things and fixing issues in there. Gnome is going to be switching from corba to this new dbus-based at-spi2 for gnome 3.0 (and possibly sooner, depending), so desktop accessibility will at last be unified on linux platforms. Unfortunately for Qt apps, the api recently changed quite a bit in january of this year, so the qt-atspi2 bridge needs to be updated to work with these changes. I have a description from Mark of what needs doing, but need to wrap my head around it before being able to help with the effort here, come join irc.gnome.org #a11y if you'd like to lend a hand. This really probably needs to become a community effort in the long run.

As can be seen above there is lots to do to make kde accessible, lots to do to make linux desktop accessible and lots to do to make sure everything is in place for everything to work nicely. So... come join the effort! join #kde-accessibility (I was often alone in there until recently Luke Yelavich of speech-dispatcher fame joined). join irc.gnome.org #a11y. get on some mailinglists, come to akademy (I hope to have a talk there, we'll see).

Kttsd 0.5.0

Ktts is finally getting a version bump since 4.0. What can you expect in this release (that will come out with KDE SC 4.4 as part of kde-accessibility)? Well, a lot of things have changed, but more is still a work in progress. The most significant change is that ktts now talks directly to speech-dispatcher, which is a daemon that handles all speech from kde, gnome, console, etc. Speech-dispatcher itself supports many synthesizers like espeak, festival and so on. The plan was to make ktts expose all of the capabilities of speech-dispatcher, but it didn't quite get to that point yet.

The first new thing you should note is that if speech-dispatcher is set up, ktts doesn't need any voices configured at all. speech-dispatcher uses whichever synthesizer it can find and plays a dummy wav file if it can't find any. (The talkers tab in kttsmgr doesn't really affect anything inside speech-dispatcher yet anyway...) You can play with the different voices from the jobs tab though, setting different pitch, volume and speed, hitting apply, then clicking speak clipboard contents (I'll add a test button for 4.5, or possibly 4.4.1 if the translators let me).

One thing that didn't make it in to this release was the gui for setting up speech-dispatcher. It has a command-line configuration tool called spd-conf which works fine. But I would like to get a gui for it in the next release if time permits.

I'd also like to join kttsd and kttsmgr into one process/app, kttsd doesn't do job management anymore because speech-dispatcher does all that now (yes I know the jobs tab will be renamed at some point, since it doesn't deal with jobs at all). So joining kttsmgr and kttsd makes sense I believe. Alternatively making speech-dispatcher have its own dbus access would remove the need for kttsd completely, kttsmgr could then just be a gui for configuring and controlling speech-dispatcher itself. We'll see which direction things go as this progresses.

Anyway, junt wanted to give a short update. Enjoy the wonder that KDE SC 4.4 will bring =)