Re: [orca-list] keys in conflict with XUL application keys

[Joanmarie Diggs <joanmarie diggs gmail com>]

Milan Zamazal wrote:

> OTOH, when Orca controls the caret application arrow keys don't work.
> [...]
> only in input fields.  But if a key binding is bound to another UI
> element (such as a button) 

Ah, gotcha.  I was under the impression that the alphanumeric keys would 
not be bound to UI elements without being combined with some other 
modifier.  For instance, I assumed the possibility of Alt+B or Control+B 
but not just B (or for that matter Shift+B).  Although I guess 
Thunderbird does stuff like that -- and each time I accidentally do 
something to trigger it, I find it disturbing/bad design. ;-)  But 
that's not the point I suppose.  Now I get what you're saying.  Thanks!

Which brings me to:

> So I'd suggest to disable structural navigation and Orca caret handling
> in XUL applications by default.  

I'm not so sure I like this idea.  As it stands right now, the user is 
in control of these settings:  They're on by default, they can be 
toggled by the user, they can be set by the user via the Orca 
Preferences for Minefield/Firefox (Control+Orca+Space).  Regardless, 
when a user presses Orca+Z or Orca+F12, they expect to toggle the 
setting to the opposite of what they chose.  If we go in and toggle 
things on their behalf without telling them, and then they toggle a 
setting, they will find that they're putting things back to what they 
expected them to be in the first place.  That might be confusing:  "I 
thought Orca WAS controlling the caret.  Did I accidentally change a 
setting?  No...."  I would not be surprised at that point to see a bug 
in bugzilla along the lines of "Orca randomly toggles structural 
navigation and caret handling."  (No, it's not actually random, but it 
certain might seem so.  Non-visually, it is far less obvious that you're 
viewing a XUL app rather than a traditional web page).  I suppose we 
could tell them when we're switching things on their behalf, but that's 
quite a bit of "chatter", plus what if the user doesn't want them 
switched?  I'm not sure it's safe to assume that they do.

Personally I think the best user experience is to keep the users in 
charge of their settings rather than switching them on their behalf. 
But I will let other users, our UI lead (Mike Pedersen), and our project 
lead (Will Walker) chime in on this one.

> allow switching the structural navigation and caret handling modes not
> only globally, but also for a particular window or so?  What do you
> think?

I think this would (could) be part of the per-URL script implementation. 
 There could be per-URL preferences.  I'm not sure about 
per-window-within-a-URL

Thanks for the explanation and your thoughts.  Let's see what others 
have to say and go from there.

Take care.
Joanie