Re: Dialog buttons

Hi All,

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

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

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

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