Re: Dialog buttons

[Marc Mulcahy <marc mulcahy sun com>]

Hi All,

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.

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.

I'm not sure what the correct solution is, but I think we should be 
explicit in what we mean by the default button, and the rules by which GTK 
decides when it gets activated vs. another control when the enter key is 
pressed.

Sorry for any confusion my last or current message caused.

Marc

At 12:33 PM 6/4/2001 +0100, colin z robertson wrote:
> On Sat, Jun 02, 2001 at 11:23:32AM -0700, Peter Korn wrote:
> > > In the usability mailing list and in the #usability channel on
> > > irc.gnome.org we've been discussing dialogs in GNOME and GTK+, and
> > > dialog buttons in particular. However, for the most part we are not
> > > accessibility experts and we'd like to know if anyone here can give us
> > > any input from an accessibility perspective.
> >
> > Thanks for raising these issues!
>
> Don't thank me. Thank Calum. He suggested that you guys might be
> interested.
>
>
> > > Default buttons:
> > > The default button is that which is activated when the enter key is
> > > pressed, regardless of which widget has the focus. The contentious
> > > issue is whether developers should avoid setting a destructive action
> > > as the default or whether they should choose the action the user is
> > > most likely to want to perform regardless of how destructive it may
> > > be. As we've discussed it so far, it's largely a matter of finding a
> > > good trade-off between safety and convenience.
> >
> > My opinion is that this is a case-by-case decision that the 
> developers/usability
> > folks closest to the application need to make.  If deleting stuff is very
> > common, I don't want to have to go through lots of layers to get the 
> darn thing
> > deleted.  People with disabilities will feel the same way.
>
> Noted.
>
>
> > > Default button movement:
> > > Currently, when any button on the bottom row of a dialog has the focus
> > > it will also become the default. When another widget is selected the
> > > default will revert to the original default. Is this behaviour
> > > desirable? Should the default ever change?
> >
> > I personally think this is sub-optimal and potentially 
> confusing.  Changing what
> > button is the default may work reasonably well when the user has visual
> > feedback.  For a blind user, having stuff change out from underneath 
> them is not
> > friendly.  Though this information could be conveyed, it raises the 
> noise floor
> > for in the audio stream.
>
> Ah. This is interesting.
>
> > For example, let's say we have a dialog with the three
> > buttons on the bottom row of a dialog: "Yes", "No", and "Cancel".  Without
> > default changability, the audio stream from a screen reader might go 
> something
> > like this:
> >
> >   "Tab - Button Yes"; "Tab - Default Button No"; "Tab - Button Cancel"
> >
> > (and then additional tabs take the user up into the rest of the 
> dialog).  But if
> > the default were changing, it would probably be something like this:
> >
> >   "Tab - Button Yes - Button Yes now Default";
> >   "Tab - button No - Button No now Default";
> >    ...
> >
> > You would need to tell the user each time the default changed.  And the 
> signal
> > that signifies to the screen reader that the default button has changed 
> may not
> > be trivially coalesced into the focus change signal (and it probably 
> comes after
> > the focus change signal), making the shortening:
> >
> >     "Tab - Button Yes - now Default"; "Tab - button No - now Default"; ...
> >
> > somewhat tricky to do 100% correctly.  But since a blind user would 
> have to go
> > to some length to discover that these three buttons are on the bottom 
> row (as
> > opposed to other buttons), expecting them to "know" this behavior won't 
> work.
>
> hmm. Ignoring the issue of defaults for a moment, would it be possible
> and/or desirable to let them know that these buttons where on the
> bottom row? (Or, to put it semantically, that they were buttons that
> applied to the dialog as a whole.) You see, I've been thinking, for a
> number of reasons, that it would be useful to have some sort of API or
> component to say that a set of buttons were specifically dialog
> buttons.
>
>
> > > Button layout:
> > > Should button layout follow the Windows style of having the action
> > > buttons on the left or a more Mac-like style of having action buttons
> > > on the right? The former is more consistent with other platforms, the
> > > latter generally thought to be more comfortable.
> >
> > Users with disabilities mostly live in Windows, just like everyone 
> else.  They
> > will have a similar familiarity with Windows-based layout as their 
> mainstream
> > colleagues.  And I expect they will have a similar adjustment period to the
> > change as well.  So, I would not use accessibility as an argument to keep
> > something that is generally felt to be sub-optimal.
>
> If blind users are using a screen reader as you describe above, and
> tabbing through a set of buttons, am I right in thinking that with
> Windows-style layout they'd get to the action buttons first, but if
> the action buttons were on the right they'd encounter Cancel first?
> Would this be a bad thing?
>
> colin
>
>   _____________________________                            ____
>   rtnl  http://rational.cjb.net     c z robertson ndirect co uk
>                                                    icq 13294163