Re: Dialog buttons

[Calum Benson <calum benson ireland sun com>]

Marc Mulcahy (marc mulcahy sun com) wrote:

> I think there may be some confusion about my last post, so I'd like to 
> attempt to clarify.  From a blind person's perspective, it is crucial that 
> there be a consistant means by which to activate a focused button with the 
> keyboard.

Just to add more fuel to the fire, it's worth re-iterating what the
current draft proposal for GTK 2.0 keyboard navigation (drawn up by the
GNOME Accessibility Team) has to say on this matter-- it's still
incomplete so it's not set in stone, but it's been through a couple of
reviews on gnome-accessibility-list and gtk-devel-list, and nobody's
complained too much so far... I expect this to change right about now 
:o)

http://developer.gnome.org/projects/gap/keyboardnav.html

The suggestion in the proposal is that:

- Enter always activates the default GtkButton in the current context
(unless the focused control happens to override Enter, e.g. a multi-line
text field);

- If any GtkButton has focus, Space activates it (whether it's the
default button or not);

- The default button never changes as you're tabbing through a
window/dialog.  

This is basically the same as Marc's suggestion #2, which I've
re-iterated below.

This method was proposed over the others that have been discussed so far
on the lists because of its simplicity and (relative) consistency-- if
the window you're in has a default button, pressing Enter will activate
it, and if it has no default button, nothing too untoward should happen
instead.  The counter-intuitiveness Marc describes in his example below
is potentially an issue, however, as is the unpleasantness caused by the
fact that some widgets would override Enter for their own purposes when
focused (e.g. a multi-line text field), and some wouldn't.

This is the same default button activation scheme that Java employs, so
the guys who worked on that are probably better placed to explain if/why
they found this method to be superior to the others, or any
implementation issues that may have forced their hand-- Earl, Peter, any
(further) comments on this?

Cheeri,
Calum.


> Consider a dialog where the buttons on the bottom are "ok" "cancel" and 
> "help".  In the top of the dialog box, there is a label displaying the text 
> "enter file name", a single line entry field in which the user can type the 
> file name, and a "browse..." button which can be clicked to bring up a list 
> of files.  For the sake of discussion, the default button when entering the 
> dialog box is the "ok" button.
>
> What happens when the user tabs to the "browse..." button and presses
> enter.  Under the strict definition of a default button being that button
> which is activated when the user presses enter, no matter what widget has
> focus, the "ok" button would be activated.  This seems counter-intuitive
> when the focus is actually on the "browse" button".  Under the current
> model, how would the user activate the browse button?
> 
> I propose two possible solutions.
> 
> 1. WE define the default button as that which is activated when the enter
> key is pressed when a widget other than a button has the focus.  Under this
> definition, the behavior in the above case is predictable-- pressing enter
> when the keyboard focus is on the "browse..." button activates that
> button.  Typing a filename and pressing enter while the focus is on the
> entry field also has the intuitive result of activating the "ok" button
> when enter is pressed.  the problem with this approach as I see it is that
> the behavior of the enter key is not strictly predictable.  Also, under
> this solution, what is the defined behavior of the enter key when the focus
> is on a checkbutton?
> 
> 2. Define the spacebar to always click the focused button or checkbutton
> regardless of the existence of a default button.  This could work in
> containers other than dialogs, and gives a certain amount of consistancy as
> to how keyboard access works for buttons in GTK as a whole.  But in the
> above example, this approach exhibits the seemingly counter-intuitive
> behavior of activating the "ok" button when the enter key is pressed while
> the focus is on the "browse..." button.

-- 
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