Introduction

Fonts and Colors

There are some general points that I'll rehash without thinking about it too much, these should be known: - The usual HIG apply: make sure that the application is keyboard accessible (try seeing if the tab key gets you through all widgets in a sensible order) is quite important. (Using a mouse is more troublesome when you can't see where you're pointing than moving a focus for example, different kinds of motorical issues etc...)

- Check for color scheme compliance and font settings taking effect.

Screen Reader

More advanced would be the usage of assistive technology. I think we need to learn from people with actual need of these technologies in order to get a good grasp of the issues. I can try to write down some issues I know about.

1 Get Orca to work in general - just grab the gnome-orca package that should be in pretty much any distro and try it with some gtk app. Test that it reacts to focus changes. 2 Make sure it's using dbus. That means having libatspi 2.0 (package name may vary, see also the settings here: http://labs.qt.nokia.com/2011/08/23/accessibility-on-linux/) 3 Have Qt 4.8 and the qt-at-spi bridge. 4 export QT_ACCESSIBILITY=1 (this is needed for Qt 4, fixed in Qt 5) 5 Run the KDE/Qt application you want to test with the Qt version for which you have the bridge installed. (This works even with Qt built separately in the home directory and the bridge installed there.)

Once you have an application running with the screen reader: Make sure Orca says something intelligible for all elements. When it reads a gui element it should say the label and type, eg: "File, Menu" or "OK, Button". When you have a button that does not have a label, maybe because it shows a picture only, that's something to fix. Try navigating the more troublesome elements - comboboxes and lists and such. Trees need a bit of love in the bridge still.

Apart from the bridge probably still lacking features and having a few bugs, I think now it's mostly time to fix up the small missing bits.

Fixing stuff: the good news is that it's really easy usually, no heavy C++ skills required. There are two important properties that every QWidget has: AccessibleName and AccessibleDescription. The name is a short label, for example the label on a button. It should always be short. The description on the other hand is the more verbose "this button does foo and then bar". Fire up Qt designer if the app uses .ui files, you'll find the properties and can type the name/description right in. If the widget is managed in code, just find the right place and set them: button->setAccessibleName(i18n("Open")); button->setAccessibleDescription(i18n("Opens a file dialog to select a new foo"));

Sometimes you also want to override the label for a different reason. One of my test apps was the calculator example from Qt. It has a memory recall button labelled "MR". Orca will insist on this being the "Mister" button, unless told otherwise. Of course I couldn't fix that one since it made me smile every single time ;)

I bet there's more, but this is a beginning. In the end it would be great to build up a bit of a community that starts using these applications on a regular basis.

Should we gather these and extend them on some wiki? I'd love to have some accessibility testing going on some time in the future.