Accessibility Series

[Marta Rybczynska]

Hello Roger,
Thanks for the work on the text. What do you think about moving paragraph 2 & 
3 at the end? And maybe adding a paragraph that describes what is *exactly*
the acessibility project for.

Thanks,
Marta

Roger Pixley wrote:
> 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