Re: Dialog buttons
- From: Marc Mulcahy <marc mulcahy sun com>
- To: colin z robertson <c z robertson ndirect co uk>, gnome-accessibility-list gnome org
- Subject: Re: Dialog buttons
- Date: Mon, 04 Jun 2001 12:48:05 -0600
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
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
Sorry for any confusion my last or current message caused.
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
> > 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
> 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
> 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
> 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
> 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
> that signifies to the screen reader that the default button has changed
> be trivially coalesced into the focus change signal (and it probably
> 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
> opposed to other buttons), expecting them to "know" this behavior won't
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
> will have a similar familiarity with Windows-based layout as their
> 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 http://rational.cjb.net c z robertson ndirect co uk
] [Thread Prev