[Kde-accessibility] Releasing qt-at-spi

Frederik Gladhorn frederik.gladhorn at nokia.com
Thu Jan 5 15:41:23 UTC 2012


Hi,

Onsdag 4. januar 2012 17.37.50 skrev ext Christoph Feck:
> On Wednesday 04 January 2012 16:23:10 Frederik Gladhorn wrote:
> > I would like to announce the availability of the Qt AT-SPI bridge
> > 0.1.1. Since I think this is a nice number and I don't know of any
> > major bugs in there at the moment, I consider it released.
> 
> Thanks, accessibility is a requirement for many agencies, and getting
> KDE in the boat is a nice addition.
> 
> > Feedback what works is appreciated. I know most KDE applications
> > don't work "good enough" but now everyone can start testing and
> > improving things :)
> 
> Is there a list/guide what KDE application developers can do to
> improve accessibility-awareness? How can the KDE quality team test
> which applications fail to work "good enough" and suggest
> improvements?

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.


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.

Greetings
Frederik

(I put kde-accessibility into cc so the info goes there as well.)


> 
> Christoph Feck (kdepepo)
> KDE Quality Team


More information about the kde-accessibility mailing list