Re: [g-a-devel]gnopernicus command keys

[Bill Haneman <Bill Haneman Sun COM>]

Peter Korn wrote:
> 
> Hi Bill,
> 
> > Peter: I know you are talking about the numberpad, but the reality is that not all X servers and
> > keyboard drivers distinguish between the numpad and arrow keys in some configurations.  So in fact,
> > anything that grabs the numberpad has a very high clash potential for the arrow keys.  I suspect that
> > the situation gets worse for non-English keyboards.
> 
> Are you saying that it is more likely that an arrow-key NumPad assumption
> clash is *more* likely when used with modifiers (e.g. Ctrl-NumPad-8 for
> Ctrl-Up-Arrow vs. NumPad-8 for Up-Arrow)?

I am saying that numberpad-based commands have a high conflict potential,
regardless of whether modifiers are used (as long as those modifiers are
the 'common' ones Alt, Ctrl, Shift.

> I think there are two issues here, and I think it would be helpful if we
> discussed each separately, rather than potentially confusing them.
> 
>   1. From the user's point of view, what is the best interface?  Do users
>      generally prefer the existing "layering" keypad approach, do they prefer
>      to use modifier keys with the keypad, do they prefer to use the main
>      keyboard (presumably with modifier keys or a similar layering), or
>      is there no clear "center" of preference?

Sure, we need to know this in order to evaluate suggestions.  We also need to 
know about technical issues (below).

>   2. How do we best deal with keyboard conflicts?  If we can agree that
>      "the screen reader always wins" (and it is up to the user to choose
>      command mappings that don't clash, and the screen reader vendor to
>      choose intelligent defaults that have few known clashes), then the
>      issue is whether and how we can achieve this.  I believe a low-level
>      interception of the keyboard will be the only guarenteed way of doing
>      this, hence our work in that area.

"Screen reader always wins" sounds good but in practice it may not work out
so well for the user, at least without the low-level keyboard interception.
Even with it, there are significant difficulties if the keyboard doesn't include
KP_* keysyms in its current keymap (i.e. laptops and some non-English keyboards), 
or if the server has problems distinguishing these keysyms correctly.
Identifying numberpad keys by keycode is "relatively" easy for "standard"
English keyboards, but the general case can be messy.
 
> Fundamentally, the more keyboard commands we have, the more likely we'll
> have conflicts.  So long as we can guarentee that the screen reader always
> wins (e.g. with an X extension), why doesn't the conversation simply become
> a discussion of item #1 above?  

The screenreader "winning" can mean loss of keyboard navigation features.
If there's a conflict with keyboard navigation features (and that is indeed where
conflict is most likely), then the screenreader commands "winning" would mean that
the user would be unable to issue those keyboard navigation commands to applications.
Not a good solution.

> Do we really want to put a lot of effort
> long-term into a world without such an extension?  #

The extension does not solve our problems alone.  The conflicts will remain no matter
whether we have such an extension or not, since the conflicts are more fundamental than
just our ability to grab keys that are already being monitored.  Those conflicts are
indeed important, but the ones I am most worried about are the ones that bite 
regardless of our key interception capability.

> And, is there really a
> significant case in which we'll find clashes with modified NumPad keys but
> not with the unmodified NumPad keys?  I mean, I'm sure there exist legacy
> specialized apps that use such key sequences (e.g. a Motif image
> manipulation program), but in reality is this something a blind user is
> likely to encounter on a GNOME desktop (and if so, won't that app otherwise
> be inaccessible anyway)?

Yes, we have documented problems with this already.  And for instance we have
problems with XSun not distinguishing the correct NumPad keysyms for some 
keys, which "cannot be fixed" for reasons of backwards compatibility.

So yes, the short answer is "this is a real problem, which needs 
consideration regardless of our underlying technical approach".

- Bill

> Regards,
> 
> Peter Korn
> Sun Accessibility team
> 
-- 
------
Bill Haneman x19279
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland