Re: Close buttons in dialogs



Hi Calum.

I don't have a strong opinion one way or the other. What's going through
my mind, however, is:

1. While a user who has never used a gui before might not be aware that
Escape exits out of dialog boxes, I suspect most users who are blind are
aware of this.

2. There are a lot of fundamental commands that a user who is blind must
know, well beyond how to get out of a dialog box, in order to access
his/her computer independently. (Alt+F1 to get into the Applications
menu, Control+Alt+Tab to move amongst the gnome-panels, Control+Alt+D to
move focus to the Desktop, Alt+F6 to move focus to an unfocused dialog,
etc., etc., etc.) If we expect users to be able to locate/figure out
these sorts of commands, I think it is reasonable to expect them to be
able to locate/figure out the fact that Escape gets you out of a dialog
box.

3. As others have suggested, developers of the offensive button in
question really need to make sure that the button is indeed redundant.
It's only redundant if users have a predictable, reliable means to
accomplish the same function. This might be a nice opportunity to
improve usability by stressing the need for consistent/across-the-board
behavior: If it looks like a dialog box and it acts like a dialog box,
it shouldn't matter if it's not technically a dialog box (main window,
custom widget): Escape should get you out of it.

4. In that same vein.... If the way a user identifies that he/she is
"done" with a given dialog box is by Tabbing until he/she comes across a
Close button, removing the Close button should not result in any more
keypresses. Instead, such a user would observe that he/she has circled
around to the top and, having seen all there was to see, can press
Escape. The ability of the user to make this observation assumes that
the creator of the dialog box (or "dialog box") has ensured that all
objects which should be Tab focusable are indeed Tab focusable, that the
Tab order is logical and predictable, and ideally that the object at the
bottom isn't one of those entries that you cannot Tab out of, but must
Control+Tab out of (e.g. the Location entry in the traditional Open
dialog). :-)

5. Things might be a tad more difficult for a user who:

   a. is highly visual, and
   b. has an extremely limited field of vision or requires a high
      degree of magnification, and
   c. Tabs to the Close button rather than using the mouse + visual
      scanning to identify that the full dialog box contents have been
      viewed.

Such a user might not pay attention to the speech output of his/her
screen reader -- or might not even be using a screen reader. At, say,
10x and using the Tab key to get around, can he/she easily identify that
he/she has "circled around" to the top? In a well-designed dialog box,
probably; in a poorly-designed one, perhaps not.

6. Are we talking one or two developers wanting to drop (what they see
as) an extraneous widget, or are we looking at a GNOME-community-wide
loathing of a unspeakably reprehensible widget? ;-)

Take care.
--joanie

On Thu, 2009-07-23 at 17:13 +0100, Calum Benson wrote:
> Hi all,
> 
> One question I was asked at GUADEC this year was regarding the old  
> chestnut of Close buttons in the bottom corner of instant-apply  
> dialogs, which some designers (including Apple's, if you look at their  
> OS X system preference dialogs) consider to be an unpleasantly- 
> redundant feature.
> 
> One of the main areas of resistance to the removal of such buttons the  
> last time it was considered was feedback from assistive technology  
> users, who (albeit in an unscientific straw poll) expressed an overall  
> preference for retaining the explicit Close button, in addition to the  
> window manager Close button and associated keyboard shortcut.
> 
> With GNOME 3.0 now just a couple of blocks away, if not quite around  
> the corner just yet, I was wondering if this is still the consensus?   
> Or have AT improvements or any other factors now reduced the need for  
> explicit Close buttons in instant-apply dialogs?
> 
> Thanks,
> Calum.
> 



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