Re: Dialog buttons

[Bill Haneman <bill haneman sun com>]

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.

One important issue regarding dialog box behavior is consistency with
focus and activation behavior of buttons in other types of
containers/canvases.  The standard behavior for buttons seems to be
that "Enter" activates a button that has focus, and tab (and arrow)
keys allow focus traversal within a container of GtkButtons.

The consistency problem arises when "Enter" activates a button that
does not have "focus", which would seem to be that case for "default
actions".  I am concerned that this would be very broken from the
point of view of a blind user, who will have come to expect that
"Enter" activates a focussed GtkButton.

In that sense I think I would argue for "changing default", but the
only consistent way of doing this without introducing lots of noise
(as Peter noted) would be by making the default button have initial
focus.  This would mean that "default" button really just means
"initially focussed", thus no additional information must be conveyed
to the blind user.

Of course this introduces difficulties for dialogs which expect some
user action (such as text entry) prior to taking "dialog button
action"; one approach would be to make the most commonly used result
"default?" the next item in the focus traversal list after the
GtkEntry.  Thus the usual case:

enter text; tab (to OK); Enter

and to cancel instead:

enter text; tab (to OK); tab (to Cancel); Enter

-Bill

> > 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
> 
>   ----------------------------------------------------------------------
>    Part 1.2Type: application/pgp-signature

-- 
--------------
Bill Haneman
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland