KDE Commit-Digest
Hello dear KDE Commit Digest reader,
I was asked to talk a bit about what's happening when it comes to KDE and accessibility at the moment, something I'm happy to do. For me KDE is about inclusiveness and enabling people to use technology. Don't think this doesn't affect you, it's a broad subject and everyone benefits in some way.
Accessibility is a broad term. In the context of computer technology, it generally means giving as many people the ability to use the technology as possible. Because people are so different, there is of course not one solution for all. We aim therefore to cover a broad spectrum of use cases. Many issues that severely impact computer usage are, of course, visual or motorical difficulties. Hearing problems can be another barrier. For KDE this means following the human interface guidelines, which ensure for example that users can adjust font sizes or the contrast of color schemes. Sometimes more advanced solutions are needed, such as using a screen reader for blind users.
And hey, this is the commit digest, I bet you're itching to get your hands onto some code, right? Join us and dive into a fun community effort, what's stopping you? We have a growing and ever more active team now, meeting in #kde-accessibility on irc (freenode). The mailing list is of course another good point of contact: kde-accessibility
For developers to get started, I wrote a few points that you can check in order to make your application usable by as many people as possible: checklist
Since this is the first post about accessibility here, I'd like to mention what's currently going on. There are several areas where we're improving, one great newcomer is of course Simon, an application that lets you control your computer via speech. I'll for now refer you to the Simon blog for the latest news.
The other big thing going on is that qt-at-spi has seen many improvements. Now I don't expect everyone to know what qt-at-spi is... and that's the way it should be. Qt-at-spi is a plugin for Qt, that exposes information about what is on screen via the AT-SPI api that the Gnome accessibility tools use. After some research and help from the great Gnome accessibility team, I spent some time during the last year to get this plugin into shape. It exposes semantics about applications so that Assistive Technologies (ATs) use the information to support the user. One classical example is a screen reader. Screen readers are programs that "read" the user interface so that people that are blind can use applications.
Orca from Gnome now works to some degree with KDE applications thanks to the plugin. Now we reached a phase where more and more feedback from users benefiting from this comes in and we can start polishing the experience. As you can imagine, the mouse is not all that helpful when you cannot see where the pointer is, therefor having a working keyboard interface to our applications is important.
Let's just imagine a dialog with an OK and Cancel button. With the accessibility tools, the screen reader "knows" that there is a button with label "OK" at this position. It can check the state and find out that it's currently focused. When you press the tab key, the focus moves over to the "Cancel" button. Now the screen reader gets a notification on focus changes and will read "Cancel - Button" for example. If you want to see how that is done, you can of course read the Qt sources and the qt-at-spi plugin sources. There's lots to do, for an easy starter, adding more unit tests would be a good idea. Get the code here: qtsami, there are still many low hanging fruits as well as tricky issues to be tackled.
But that's not all that's happening in accessibility land currently: we have summer of code projects for Simon and one to improve KMag. Let me talk about KMag in this context. When using a magnifier, it's still important to know where the focus is. Since we don't have focus follows mind (link) yet, we need to figure out where the focus is at. Guess what - we're using AT- SPI to do that. Amandeep Singh is working with Sebastian Sauer to make the pieces fit together. In order to let not only KMag benefit from the work, the changes are actually done in a client side AT-SPI library for Qt/KDE applications. You can follow the progress here: libkdeaccessibilityclient and in KMag of course.
Now if you're as excited about this all and want to read more (you know you do!), here are some more helpful links:
Cheers Frederik