One year ago, some people from linaccess, barrierefrei kommunizieren, KDE Accessibility and Usability (including myself) passed a weekend on testing the usability of FLOSS accessibility solutions - you might remember our reports from the Accessibility meets Usability weekend. Among others, the Gnopernicus screen reader was usability tested by two blind users. Short after the test, the development of Gnopernicus was (at least partly) stopped for the benefit of Orca which relies on AT-SPI technology.

As preparation for a workshop about German screen readers for Linux I'll attend next week, we now did a first evaluation of the Orca screen reader with Gnome. In cooperation with barrierefrei kommunizieren, I had the opportunity to test Orca with Sebastian, a blind student of computer science. Our focus was mostly set on functioning, but also usability and German localisation.

All in all, we were amazed by the current state of Orca and its integration with the Gnome desktop. Application whose integration was problematic with Gnopernicus, e.g. OpenOffice.org, can be widely operated with Orca.

You can download the full report (PDF, 719 KB).

In a small poll (or sorta), Albert asks what kind of values are better in the zoom combobox for oKular.

IMO, zoom is best represented by either:
- a slider with major ticks in almost logarithmic scale, going from 10% to (wishful thinking) 10000%, with a spinbox or constrained textedit next to it to show the slider value and allow manual editing
- a zoom out button and a zoom in button (with the classical icons and obeying bidirectional gui guidelines) with a constrained textedit inbetween. Once again, zoom buttons should increase/decrease zoom value almost logarithmically (1, 2, 5, 10, 20, 50, 100, 200, 500, 1000% etc.)

IN order for these widgets to take lesser space on toolbars, they can be actually hidden and popped up from an unique zoom button ("lens" icon). AmiPro was doing this stuff perfectly 15 years ago.

BTW, such a zoom widget should go in kdelibs and be strongly recommended by the programming guidelines.

Comboboxes are a poor choice (aesthetically and usability wise) for zoom widgets.

I get so seldom to blog about such an important topic as Accessibility, but I think this is worth noting:

Gunnar's IRC client is reading incoming messages alound using kttsd and it's puzzling the first time you hear it, but after some time you notice how much fun is related to it. Just see here (slightly edited)

[16:52] <[ervin]> hahahahahahahahahahah
[16:52] <pmax> muahahaha
[16:52] <[ervin]> OH OH OH OH OH OH OH
[16:52] <boemann> well i've been maintaining it
[16:52] <[ervin]> OH OH OH OH OH OH OH
[16:52] <pmax> OH OH OH YES YES MORE
[16:52] <harryF> YYYYYYYAAAAAAAAAAAIIIIIIIIIIIIII
[16:52] <[ervin]> OH YEAH OH YEAH OH YEAH AGAIN!
[16:53] <[ervin]> tak tak tak tak tak tak
[16:53] <pmax> SLAP IT!  HARDER!
[16:53] <Bille> shoo bee doo bee doo wop
[16:53] <aseigo> do my hard baby
[16:53] <[ervin]> OH OH OH OH OH OH OH
[... possibly offensive content removed :]
[16:54] <icefox> 
[16:54] * [ervin] want's his toy back
[16:54] <Schmi-Dt> I have temporarily turned text-to-speech off now.

As Roberto blogged about how he converted his blog into a blog/podcast hybrid using Talkr, I thought I should tell you about a well-hidden, half-finished feature in Akregator: Basic Text-to-Speech support.

To use it, you need kttsd installed and set up, which does all the heavy lifting for Akregator.

After you have got it running, start Akregator and enable the speech toolbar (Settings->Toolbars->Speech Toolbar in the menu):

Now, just select the articles you want to have spoken and click the parrot to enqueue and play them.

Isn't that great? All the people on PlanetKDE are podcasting to you now!

** Sebastian, one of the blind participants of the Accessibility-Meets-Usability weekend, just told me that the development of Gnopernicus, a screen reader and magnifier for Gnome, has been stopped. I hope these are just rumours? It would be a pity. Instead, the development of Orca will be reinforced which is actually good news (thanks henrik for the clarification!).

** Aaron pointed me to this article about usability in Linux projects on tomshardware.com. It's great to read our work is getting such positive attention =)

** Together with Bjoern from OpenUsability I'll attend the tOSSad Workshop in Como on Saturday, a workshop on Governmental, Educational, Usability, and Legal Issues towards Open Source Software Adoption in an enlarged Europe. I'm looking forward to meet Gorkem there who is very active translating KDE and works on the Turkish Linux distribution Pardus.

As announced I summarised the results of our Accessibility meets Usability weekend in a (long but interesting) report available on OpenUsability (PDF). We did usability tests with several KDE features for partially sighted people and the Gnopernicus screen reader for Gnome. The goal of the usability tests was not to achieve statistical data, but to gain an understanding of the needs of the represented user types.

As a general conclusion we found that while both KDE and Gnome provide very good tools to make the Linux desktop usable for partially sighted and blind users, they are lacking consistent support among the major desktop applications. In KDE, key applications like the text editor Kate or the shell Konsole did not apply high contrast colour schemes; in Gnome, the contents of crucial tools like the software installation (Ubuntu) could not be read by Gnopernicus and were therefore "invisible" for the blind users.

Many of the described problems could be avoided if you try to keep the following guidelines in mind while developing:

• Use scroll panels -
  with extremely high font sizes, a panel's height may exceed the screen height. If you do not provide scrollbars, the panels are likely to be "cut off" and a user will not be able to reach all contents without resizing.
• Make dialogs resizable -
  if a dialog is not resizable and has no scrollbars, users may be unable to reach contents at the bottom. Make dialogs resizable anyway to allow every user to reach the confirmation buttons.
• Make scrollbars exclude the tabs -
  to keep the tabs as navigational device visible on the screen, set the scrollbar below the tab navigation.
• Avoid complex and visually cluttered user interfaces -
  for example double-nested group boxes, checkbox and button deserts, or overcrowded toolbars. Otherwise it is especially hard for partially sighted users to keep track of related items.
• Avoid fixed background colours or images -
  make them adjust to the overall colour scheme (except there are compelling reasons not to do so).
• Allow your contents to adjust to the overall colour scheme -
  you do not need to default the contents to the overall colour scheme, but allow the user to manually do so in an easy way.
• Make all interface elements accessible via the keyboard -
  fancy html widgets are cool, but make sure they are accessible.
• Use the standard interfaces and widgets -
  to make sure your application is and will be accessible later, use standard interfaces and widgets.

Olaf, Gunnar, Gary or the Gnome accessibility guys sure have some more guidelines to add! Maybe they want to write a follow-up blog? =)

Accessibility meets Usability Weekend - February 2006, Berlin

Accessibility meets Usability Weekend - February 2006, Berlin

Accessibility meets Usability Weekend - February 2006, Berlin

Accessibility meets Usability Weekend - February 2006, Berlin.