Accessibility/Checklist: Difference between revisions

From KDE Community Wiki
*>Frederik.gladhorn
(Created page with "= 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 su...")
 
(Move page into the HIG)
 
(9 intermediate revisions by 3 users not shown)
Line 1: Line 1:
= Introduction =
Moved to https://hig.kde.org/accessibility/index.html
 
== 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.

Latest revision as of 08:15, 6 June 2019