Re: Dialog buttons

[Marc Mulcahy <marc mulcahy sun com>]

Hi All,

The way which Windows does it, and which is arguably inconsistant, is that 
enter activates the default button if a non-button control has focus, 
otherwise it activates the currently focused button.  This works for me.

Being a blind user, I have to say I agree with Peter that allowing the 
default button to change would be incredibly confusing for blind screen 
reader users.  In order to provide all the relevant information, the screen 
reader would have to be extremely verbose as Peter pointed out, and I think 
this would be confusing.

Just my $.02

Marc

At 02:43 PM 6/4/2001 +0100, Bill Haneman wrote:
> 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
>
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list