Re: [Kde-accessibility] KDE Accessibility - sorry, off topic.

[Bill Haneman <Bill Haneman Sun COM>]

On Thu, 2006-08-17 at 12:05, Olaf Jan Schmidt wrote:
> [ Bill Haneman ]
> > Actually, my point is that this affects ALL use cases of on-screen
> > keyboards.
> 
> I don't see why this should be the case.
> 
> Imagine a case where an on-screen keyboard is used for entering text in 
> another language - not as a keyboard replacement, and without need to work 
> within menus.

The case above, if you're really talking _only_ about entering text in
an alternate language, is technically an "input method".  Input methods
have their own architecture and requirements.  Normally one would not
use an onscreen keyboard to do this, though there are probably
exceptions (and in fact GOK has such an experimental keyboard for
Mandarin).

If on the other hand the user expects the onscreen keyboard to be used
as if it were an alternate keyboard (with a different language/layout),
the menu problem cannot be ignored.

Most onscreen keyboard users will complain if they are expected to
switch back and forth between the virtual and "real" keyboards, and in
some situations the physical keyboard is unavailable or cannot be used. 
Thus, the OSK needs some basic modifier keys like "Alt".  But if that is
the case, you would have to tell the OSK user that "the onscreen
keyboard cannot be used for keyboard navigation", or "the TAB and arrow
keys will work in many situations, except when menus are posted..."
etc.  See the problem?

Here's an example:  your simple OSK doesn't provide modifier keys
(because it's for text entry).  Users complain, because some things
really require 'Alt' even if you don't use keyboard navigation much.  So
you add 'Alt'.  The user presses "Alt-f", a file menu posts, but then
the "o" key on the OSK doesn't do anything.  How do you explain to the
user that this is "normal" ?

> Or a case where the on-screen keyboard simulates neither key presses nor mouse 
> events, but is only used for starting applications or scripts.

Such an OSK would look to the user like a launcher or button-box, and
not a keyboard at all.

I think the 'simple' or 'common' cases you are thinking about are mostly
text entry.  For text entry you are right that the 'normal' use of the
pointer (plus focus rejection logic) would work, but it would not work
"correctly" from the user's point of view for any keyboard navigation
features.  These inconsistencies are always going to be viewed as bugs
from the user's perspective, no matter how you explain them...

Bill

> Olaf
> 
> -- 
> Olaf Jan Schmidt, KDE Accessibility co-maintainer, open standards 
> accessibility networker, Protestant theology student and webmaster of 
> http://accessibility.kde.org/ and http://www.amen-online.de/
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list