Development/Tutorials/Accessibility/Checklist

Introduction

Fonts and Colors

Many users have some deficiencies when it comes to seeing. This doesn't always mean that they are blind. For some people it is enough when fonts are clear and the color scheme can be adjusted. This is something every application should do in any case, so here is the list:

• Follow the user interface guidelines! This will get you quite far.
• Check that color scheme changes apply
  • Try switching to a dark color scheme and see that your application is still usable
• Test changing the font size
  • Switch to different fonts and see that they apply
  • Increase the font size and make sure that the application layout still works

Keyboard

When you have problems seeing, the mouse is quite hard to use. The keyboard is a lot more reliable. Therefor it is important that applications can be used with the keyboard. For some users, using a mouse is difficult because of motor skill issues. Making applications keyboard accessible benefits everyone, since it allows us to use shortcuts to use the applications more efficiently.

• Try to operate your application with the TAB key
  • Make sure that the tab order is correct (or fix it in Qt Designer or the code)
• Start your application and do a common task without using the mouse
  • Note where you had trouble and think about possible improvements in the UI or keyboard shortcuts that are missing

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.