Accessibility Series

[Roger Pixley]

Hello all,

Sorry for being so silent so long but I've not had net and have been
country jumping (again). To get back in the saddle I've been speaking with
the KDE accessibilty team and they have a lot of work going on. So we are
working on a mini series of articles with the last set being on Simon since
that project has had a lot of exposure recently. The main dev was gracious
enough to let everyone else on the A11y team get a chance to speak. Fredrik
will probably be doing most of the writeups so that it can be managed
unless one of the other devs really wants to do their own writeup.

I'll put the first in the series here with two edits of my own. One for
grammar and the other with a link to clarify the focus follows mind quip :)
The only change that I would suggest is to put the contact the mailing list
paragraph further to the bottom but that may just be my personality being
imposed on the writing. Any comments? I'd like to have it cleared for the
digest by tomorrow.
As an aside if anyone reads through this and then on the readmore links at
the end expected to see information which is missing let me know so we can
get that up on the wiki pages.


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.

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: https://mail.kde.org/mailman/listinfo/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.
http://techbase.kde.org/Development/Tutorials/Accessibility/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 http://simon-listens.blogspot.com/
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
benefitting 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: http://projects.kde.org/qtatspi 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<http://blogs.kde.org/node/1860>
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:
http://projects.kde.org/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:
http://userbase.kde.org/Accessibility
http://techbase.kde.org/Development/Tutorials/Accessibility

Cheers
Frederik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digest/attachments/20120509/8c90cee1/attachment.html>