Re: Dialog buttons

On Sat, Jun 02, 2001 at 11:23:32AM -0700, Peter Korn wrote:
> > In the usability mailing list and in the #usability channel on
> > 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

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

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

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


  _____________________________                            ____
  rtnl     c z robertson ndirect co uk
                                                   icq 13294163

Attachment: pgpASsi5eZADi.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]