Development/Tutorials/Accessibility/Checklist: Difference between revisions

From KDE TechBase
(Moved to Community Wiki)
 
(5 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 ==
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.

Latest revision as of 10:44, 16 May 2019