KDE Accessibility Cooperation

Recent weeks have seen a lot of cooperative activity between the KDE Accessibility Team and various other Free Software accessibility teams. The Free Standards Group Accessibility Workgroup, KDE Accessibility and GNOME Accessibility teams have now released a joint statement describing some of this cooperation. "We believe users who are persons with disabilities should be empowered to choose technologies from any and all environments which provide accessibility just as other desktop users today routinely use a mix of technologies from different desktop environments. Our goal is seamless interoperability."

In addition to participation in the accessibility workgroup of the Free Standards Group, KDE Accessibility also closely cooperates with a number of other accessibility teams. During the KDE Conference, for example, we worked together with the Brailcom to make KDE Accessibility interoperate well with applications for the console.

Other areas of activity and cooperation include:

  • Participation in the Google Summer of Code to support Leo Spalteholz in developing a new application for eye trackers (project NoKey)
  • Development of a new X.Org based screen magnifier
  • Foundation of the Freedesktop.org Accessibility Initiative
  • Foundation of the Unix Accessibility Forum during last years KDE Conference, and cooperation with the German accessibility user group Linaccess to organise it again during LinuxTag this year
  • Cooperation with OpenUsability.org to develop accessibility guidelines for KDE developers

All of this will contribute to making Unix in general and KDE in particular the software of choice for disabled users.

Dot Categories: 

Comments

by Leo S (not verified)

With respect to Nokey, I greatly appreciated the chance to develop it as part of the Google Summer of Code. Thank you to Gary Cramblitt and Olaf Jan Schmidt for helping me out with this!
At the moment, Nokey may not be suitable for real use yet, because of problems with transparency and accessibility interfaces in Qt3. But I'm really excited about continuing work in this area. If you look at alternative onscreen text generation interfaces available today, they are mostly boring and uninspired (Dasher being the notable exception). This is not a problem unique to *nix platforms, even for Windows there are tons of on-screen keyboards, none of which represent an ideal solution.
I've used a lot of different interfaces with an eye tracker, and have found that the key criteria for an effective interface are:
1. Simplicity - less than 10 areas of interest on the screen
2. Inobtrusivity (is that a word?) - the interface shouldn't obscure the user's work.

Reproducing a qwerty keyboard on the screen is a terrible solution, and yet there are tons of applications doing exactly that. Why would qwerty, which isn't even optimal for an able-bodied typist, be even close to optimal for a user with an alternative input device? The only advantage that gives you is familiarity, and even that is only valid if your users have typed on a regular keyboard before. The whole concept is silly.

I think the Nokey interface isn't quite there yet, but it will be much better by the time I've ported it to Qt4, and when AT-SPI is more widespread.

Right now I'm working for UVATT (http://web.uvic.ca/uvatt/). Our vision right now is to develop an interface that is not only for text input, but for complete computer control. That is, that a disabled person using an eye tracker (or head tracker or Intellikeys device) could have complete control of the computer as soon as it is turned on. Too much assistive software doesn't go that last step and think about how a disabled user would start the software, or navigate their system. That's what we hope to accomplish. We target Windows, but we are evaluating Qt at the moment to replace MFC. In that case we leave the option of porting to other platforms open.

Whew. Longest comment ever. Anyway, I am very excited about this stuff. :)

by cph (not verified)

> Inobtrusivity (is that a word?) -
"Unobtrusive" is the work you are looking for :)

by jameth (not verified)

> > Inobtrusivity (is that a word?) -
> "Unobtrusive" is the work you are looking for :)

Well, to maintain parallelism, "inobtrusivity" or "unobtrusivity" are both quite good invented words. For a less awkward word, my top recommendations would be "innocuousness" or "inconspicuosness". Of course, changing "simplicity" to "simple" and going with "unobtrusive" is possibly the best option open.

by Robert (not verified)

Unobtrusiveness.

by fast_rizwaan (not verified)

> Reproducing a qwerty keyboard on the screen is a terrible solution

You're right Leo, it is very difficult for non-typist to find "Alphabets" on the *onscreen keyboard*, causing more problem than solving the problem of typing with keyboard.

my opinion: why not arrange things in Columns like this: (this can be improved considerably); logically arranging for faster typing using mouse

-------------------------------------------------------------
Numbers and : [1] [2] [3] [4] [5] [6] [7] [8] [9] [0] [,] [.] [!] [?] | [+] [-] [*] [/] [=]
punctuations
-------------------------------------------------------------
Alphabets : [a] [b] [c] [d] [e] [f] [g] [h] [i] [j] [k] [l] [m]| [spacebar on the right side]
Lower case : [n] [o] [p] [q] [r] [s] [t] [u] [v] [w] [x] [y] [z]| [for easy]
----------------------------------------------------------------------------| [access]
Alphabets : [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M]|
Uppper case: [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]|
----------------------------------------------------------------|
Symbols : [`] [~] [!] [@] [#] [$] [%] [^] [&] [*] [(] [)] [_]|
[+] [|] [[] []] [;] [:] ['] ["] [/]
----------------------------------------------------------------|

I'm missing function keys, HOME, INSERT, PAGEUP, etc., keys, you can fit it nicely. Also other languages can also be put like English keys, or as people have learnt the alphabet sequence.

The onscreen keyboard is meant for user's convenience, easy to work with one mouse button only. (because one of the user's hands could be injured or not present). thanks.

by Sebastian (not verified)

The idea of the default keyboard layout is to cluster important letters in a center region. Just an alphabetical order is a bad idea. Just conisider, i.e. in the German language the letters ERNSTL are contained in most words. I want to have them close to each other avoiding long distance mouse moves.

by Soul (not verified)

I use WinXP on-screen keyboard and I think its very good - it looks almost like standard qwerty keyboard and works fine for me. The only thing i miss is a possibilty to change layout the way i need (i.e. to make it shorter by getting rid of numeric section). I think it would be hard to get used to unusual layout. qwerty is the best.

by fast_rizwaan (not verified)

The Screen space is precious, so to save screen space we can use Left mouse button to enter these keys (small/lower case)

Alphabets : [a] [b] [c] [d] [e] [f] [g] [h] [i] [j] [k] [l] [m]| [Enter]
Lower case : [n] [o] [p] [q] [r] [s] [t] [u] [v] [w] [x] [y] [z]| [Shift]

and using "Right Mouse Button" or Right-Click to "Enter Capital/Upper case"

Alphabets : [A] [B] [C] [D] [E] [F] [G] [H] [I] [J] [K] [L] [M]|
Uppper case: [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [X] [Y] [Z]|

this will save much screen space, and the onscreen keyboard can be used as a small bar (toolbar or something similar.)

by Brandybuck (not verified)

"Development of a new X.Org based screen magnifier"

There will still be an vanilla-X11-based screen magnifier available as well, right? Or at least have this magnifier support vanilla-X11 but with reduced eyecandy? Not every KDE platform has X.org by default, and not every user has the authorization to change it. It seems to me more productive to keep the old magnifier than to lock people out from this functionality.

by Olaf Jan Schmidt (not verified)

There will still be an vanilla-X11-based screen magnifier available as well, right?

Yes, of course.

Or at least have this magnifier support vanilla-X11 but with reduced eyecandy?

This is not about eyecandy. The X.Org Composite extention is needed to implement some important features for partially sighted people which are simply impossible using vanilla-X11.

Olaf

by PC Squad (not verified)

> partially sighted people

"partially sighted"? This is not a corporate website. Let's call things what they are. "partially sighted" sounds as if you have trouble taking aim at them.

by Henrique Pinto (not verified)

What exactly is the term you'd like to use?

As it is, your message seems very offensive to me, but I might be just misunderstanding you.

by D.A. (not verified)

I realize many people in the 'nix world view keyboards differently than people using Windows and Macs, but one KDE accessibility tool I have yet to find that has existed in Windows for 15 years is a simple audio beep when toggling Caps Lock, Num Lock, and Scroll Lock. Some people debate the usability of those keys, but many people still find them useful.

I think GNOME has this tool and I wonder why KDE does not. Additionally, the Insert Key needs the same toggle beep. That key often is used to toggle between Insert and Overwrite mode. Yes, I realize that with 'nix users Shift-Insert is still popular for pasting text, and the audio beep should sound only when the Insert key is toggled without a modifier key.

Slowly the past couple of years I have been migrating to GNU/Linux and I especially enjoy KDE, but the lack of this audio feedback often frustrates me. Seems if the code already exists in GNOME that adapting that code to KDE should be straightforward for the heady KDE developers. I hope. I wish. With each release I keep waiting for this accessibility tool. Will version 3.5 finally be the one or will I continue to wait?

I think your chances of getting that wish fulfilled would increase if you headed over to http://bugs.kde.org/ and entered it as wishlist entry.

Just register and report it as bug with severity "wishlist" (or vote for the already existing entry, if any).

by Olaf Jan Schmidt (not verified)

The feature is already part of kdeaccessibility 3.4. It shows the modifier state in panel, and it can be configured to beep when the state changes. Or it can open a passive popup and read out a message via text-to-speech.

Just add the Keyboard status applet to the panel. Then you can enable the beeps or passive popups in KControl (Sound & Multimedia / System notifications). Text-to-speech can then be configured under Regional & Accessibility / Speech Synthesis.

Olaf