|
|
| (6 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| = Introduction =
| | This is now found at https://community.kde.org/Accessibility/Checklist |
| | |
| == 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.
| |
