Keyboard navigation- outstanding issues

[Calum Benson <calum benson sun com>]

Usability and accessibility folks,

Now that we are (well, Padraig is) finally getting around to
implementing the long-standing keyboard navigation proposals, for gtk at
least, the two biggest issues we never really resolved are kind of
rearing their ugly heads again.

I reiterate them both here in the forwarded email below, along with some
potential solutions-- it would be great if we could reach some consensus
ASAP, because the discussion just tended to peter out any time we tried
before... and if that happens this time, we'll probably just implement
what I think is best, and you wouldn't want that  :o)

Padraig O'Briain wrote:
> 
> By default, when a GtkEntry field has focus, Tab should insert a Tab
> character, and Ctrl+Tab (or Shift+Ctrl+Tab) should navigate focus away from
> that control.
> 
> <POB> This is not implemented. Is this a nice to have or a mandatory? </POB>

This is one of the two biggest points of contention left that we need
some agreement on.  The options (as I see it) are either:

1) Always have Tab insert a tab character, and Ctrl+Tab navigate out. 
This is the current proposal, but it makes tab key navigation through
dialogs rather irritating.

2) Always have Ctrl+Tab insert a tab character, and Tab navigate out. 
This makes navigation nicer, but breaks our usual meaning of Ctrl+Tab,
and makes it non-obvious how to insert a Tab character if you don't know
the trick.

3) Don't allow tab characters to be inserted in single line text fields,
as they're rarely needed.  (But still need to pick 1 or 2 above for
multiline text fields).

4) Allow the programmer to set a flag on the text field that specifies
whether it allows the entry of Tab characters or not.  If it does, Tab
should enter the character, and Ctrl+Tab should navigate out. 
Otherwise, Tab should navigate, and Ctrl+Tab should do nothing.

We picked (1) for the proposal after discussion with Earl, because they
found it worked best for them when they working on Java accessibility.

> <POB> The behavior here depends on whether the function
> gtk_entry_activates_default() has been called. It seems that the default
> behavior is for Enter to insert a newline character. It seems that what you
> are requesting is that the default behavior be changed. An application
> can easily change the behavior of Enter. </POB>

This is the other big contentious issue we need resolution on.... should
Enter always activate the default button in the dialog, or should some
other key combination do this instead (e.g. Ctrl+Enter)?

The most common objection to the current proposal is that people often
instinctively hit Enter after typing into a single-line text field, only
for the dialog to disappear before they'd finished with it.  What they'd
prefer, therefore, is for Enter to move focus on to the next control
instead.  

Similarly, because Enter is regarded as an "action button", people might
well try to use it to change the state of the currently-focused checkbox
or radio button in a dialog, resulting in the window closing instead. 
(Spacebar is the proposed shortcut for changing the state of such a
control).

Also, assuming that we stick with the concept of never changing which
button is the default once the window is open, this means that when a
non-default button has focus, pressing Space will activate that button,
and pressing Enter will activate a different button.  This is guaranteed
to catch people out.
 
So, possible solutions:

1) Stick to the proposal: Enter always activates the default button,
unless the widget with focus uses Enter for something itself. 
(Multi-line text widget, list control etc.).   Maintains reasonable (but
not complete) consistency, but easy to dismiss dialog by mistake.

2) Pick a different shortcut for "Activate the default button" that you
wouldn't hit in error, such as Ctrl+Enter.  Enter can then effectively
be used to duplicate Tab as a navigation key, except in cases where the
currently-focused widget uses Enter for something itself.  (Multi-line
text widget, list control etc.).  Gives complete consistency whichever
control has focus, hard to dismiss dialog by mistake, but not as
convenient or obvious as just pressing Enter, and could be annoying in
simple dialogs where the confusion wouldn't arise in the first place.

3) Ensure none of the other widgets use Enter for their own purposes. 
This is a bit of a non-starter, really.

Again, we picked (1) for the proposal because this is what Java
accessibility folks came up with when they had to figure out what to do
for Swing.  However, I know a fair few GNOME users who would like to see
something more like (2).

Cheeri,
Calum.
 
-- 
CALUM BENSON, Usability Engineer       Sun Microsystems Ireland
mailto:calum benson ireland sun com    Desktop Engineering Group
http://www.sun.ie                      +353 1 819 9771

Any opinions are personal and not necessarily those of Sun Microsystems