Re: Dialog buttons

[Peter Korn <peter korn sun com>]

Hi Colin,

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

> Here are the issues we've been discussing:
> 
> 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.

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

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


Regards,

Peter Korn
Sun Accessibility team