[Kde-accessibility] Releasing qt-at-spi

[Alex Midence]

Good morning,

I thought I'd let people know about some communities from which to
draw a possible testing group.  Many of us have been eager to try KDE
over the years and quite frustrated at our inability to do so because
of the accessibility hurdles which qt-at-spi so wonderfully addresses.

Orca list:   orca-list at gnome.org
Casual to heavy users of Orca and software made accessible through it.
 Multiple  distributions are represented and multiple levels of Linux
profficiency and expertise as well.

Vinux support group:  vinux-support @googlegroups.com
Vinux is a Ubuntu-based distribution aimed largely at visually
impaired users (hence VI nux).  Community is lively and contains quite
a few people who are newcomers to Linux as well as people who have
been using it for a long time.  There is even a testing and
documentation group for the distribution.  One of the primary goals of
the distro is to provide more recent versions of accessible tools to
its community more quickly than the upstream distro can and, also, to
eventually get people  up to where they start branching out and
experimenting with other distributions.  Recently, there has been
considerable interest in using other desktops besides Gnome such as
Unity, XFCE and, of course KDE which has been seen as something of a
holy grail for many of us.

There are other communities that have a concentrated group of
potential testers for these special needs enhancements up to and
including a blind programmers list but, I don't know how many of them
would be Linux users.

I've taken the liberty of cc'ing the folks on the Orca list and the
Vinux development team in hopes of bringing the need for testers to
their attention and to do something to bring everyone together.  I for
one am very excited at the prospect of using this desktop and can't
wait to begin taking it for a spin!  My heartfelt thanks to each and
every one of you who has participated in this effort.  I am glad to
know that, should I ever walk into a job site that uses KDE as the
primary desktop, the day is drawing near in which I wouldn't have to
worry about not getting the position because of the technology as
opposed to my abilities.

Best regards,
Alex M

> Date: Thu, 05 Jan 2012 16:41:23 +0100
> From: Frederik Gladhorn <frederik.gladhorn at nokia.com>
> To: kde-devel at kde.org
> Cc: kde-accessibility at kde.org, ext Christoph Feck
> 	<christoph at maxiom.de>
> Subject: Re: [Kde-accessibility] Releasing qt-at-spi
> Message-ID: <2475195.phJNBiV3YY at varney>
> Content-Type: text/plain; charset="us-ascii"
>
> 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