Development/Tutorials/Accessibility/Checklist - Revision history

Frederik.gladhorn: /* Complex Widgets */

2012-01-21T00:34:52Z

‎Complex Widgets

Frederik.gladhorn: /* Fixing Accessible Name and Description */

2012-01-21T00:32:41Z

‎Fixing Accessible Name and Description

Frederik.gladhorn: /* Screen Reader */

2012-01-21T00:29:31Z

‎Screen Reader

Frederik.gladhorn: /* Screen Reader */

2012-01-21T00:11:49Z

‎Screen Reader

Frederik.gladhorn: /* Fonts and Colors */

2012-01-21T00:07:26Z

‎Fonts and Colors

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..."

2012-01-20T23:55:05Z

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..."

New page

= 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.

← Older revision		Revision as of 00:34, 21 January 2012
Line 70:		Line 70:
	Sometimes you need to inherit QAccessibleTextInterface or QAccessibleValueInterface in order to make the widgets properly accessible.		Sometimes you need to inherit QAccessibleTextInterface or QAccessibleValueInterface in order to make the widgets properly accessible.
	Refer to the Qt documentation how to do this.		Refer to the Qt documentation how to do this.
		+
		+	==== QGraphicsView ====
		+	Currently there is no support for accessibility in QGraphicsView.
		+
		+	==== Qt Quick (QML) ====
		+	For Qt Quick with Qt 4.x there is no solution for accessibility.
		+	For Qt 5, refer to the documentation on how to create accessible QML applications. The concepts are generally the same as for QWidget based applications.

← Older revision		Revision as of 00:32, 21 January 2012
Line 64:		Line 64:

	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.		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.
		+
		+	==== Complex Widgets ====
		+	For some widgets the above is not enough. You will have to create QAccessibleInterfaces for widgets that you create yourself.
		+	For example Kate has an interface for its text editing area.
		+	Sometimes you need to inherit QAccessibleTextInterface or QAccessibleValueInterface in order to make the widgets properly accessible.
		+	Refer to the Qt documentation how to do this.

@@ Line 21: / Line 21: @@
 == Screen Reader ==
 ;[[Development/Tutorials/Accessibility/Screen_Reader_Setup|Setup Screen Readers with KDE]]
 :Gives detailed setup instructions for screen readers.
-More advanced would be the usage of assistive technology. I think we need to
+=== Testing ===
-learn from people with actual need of these technologies in order to get a
+This section gives a quick intro what to look for when testing an application with a screen reader.
-good grasp of the issues. I can try to write down some issues I know about.
 Once you have an application running with the screen reader:
@@ Line 50: / Line 40: @@
 bridge still.
-Apart from the bridge probably still lacking features and having a few bugs, I
+=== Fixing missing information ===
-think now it's mostly time to fix up the small missing bits.
+Once you found a bug it's usually quite easy to fix. This section explains how to go about improving applications.
-Fixing stuff: the good news is that it's really easy usually, no heavy C++
+There are two important properties that every QWidget has: an "Accessible Name" and an "Accessible Description".
-skills required.
+The name is short, for example the label on a button. It should always
-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".
+does foo and then bar". Qt will try hard to return something for the name. In case of a button, usually the text on the button is returned. But if your button has text that makes only sense when seeing the arrangement of buttons, or only has an image as label, you need to help the AT read the button.
-Fire up Qt designer if the app uses .ui files, you'll find the properties and
+If you don't, it will only say the type of the widget, "Button" is not a very helpful information.
-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
+==== Fixing Accessible Name and Description ====
-test apps was the calculator example from Qt. It has a memory recall button
+Fire up Qt designer if the app uses .ui files. You'll find the properties and
-labelled "MR". Orca will insist on this being the "Mister" button, unless told
+can type the name/description right in. After saving the file, rebuild and install the application. You are done, submit a patch to fix the ui file.
-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
+If the widget is created in the code, just need to find where.
-build up a bit of a community that starts using these applications on a
+Once you found the widget, usually where it's created, add some code to it:
-regular basis.
+ button->setAccessibleName(i18n("Open"));
-Should we gather these and extend them on some wiki? I'd love to have some
+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.
-accessibility testing going on some time in the future.

@@ Line 2: / Line 2: @@
 == Fonts and Colors ==
-There are some general points that I'll rehash without thinking about it too
+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.
-much, these should be known:
+This is something every application should do in any case, so here is the list:
-- The usual HIG apply: make sure that the application is keyboard accessible
+* Follow the user interface guidelines! This will get you quite far.
-(try seeing if the tab key gets you through all widgets in a sensible order)
+* Check that '''color scheme''' changes apply
-is quite important.
+** Try switching to a dark color scheme and see that your application is still usable
-(Using a mouse is more troublesome when you can't see where you're pointing
+* Test changing the '''font''' size
-than moving a focus for example, different kinds of motorical issues etc...)
+** Switch to different fonts and see that they apply
-- Check for color scheme compliance and font settings taking effect.
+== Keyboard ==
 == Screen Reader ==