Re: [Fwd: Accessibility aspects of Close buttons on dialogs?]

[Peter Korn <korn sun com>]

Hi Gregory,

Gregory Merchan wrote:
>
> The ways to access a close command for a document window via the keyboard
> are by the window keybinding to close, the window keybinding to a window 
> menu and then arrow keys to the close item or the close item access key, or
> perhaps the keybinding to open the File menu and then the arrow keys
> or the access key.
> 
> Are there no blind users of Macs? Until MacOS X the dialog command buttons
> were not in the tab sequence. Still for the Mac a "Modeless Dialog Box"
> does not have a closing button except for that one provided by the window
> frame. As far as I know, the Mac window frame is not part of the tab 
> sequence either.

When it comes to desktop navigation in screen readers, the vast majority of
blind users expect to use the standard keyboard mechanisms for things.  This
comes in part because of a legacy of transitioning from DOS to Windows (and
Windows having most things keyboard accessible), and because most blind
computer users are Windows users.

The first graphical screen reader was outSPOKEN for the Macintosh (in 1989),
and as you point out the Mac had no way of doing a great many things from the
keyboard until recently (and then again, it's not 100%).  The outSPOKEN screen
reader navigation philosophy is very different from that of all other screen
readers, and when outSPOKEN was ported to Windows, a large number of users
argued strenuously for better support of "the standard Windows tabbing
mechanism" for navigation (which went in to the next release of outSPOKEN).

Now, a good point to ask is if there is a programatic way of doing everything
(e.g. AccessibleAction), why should we push to put something in the TAB order
(e.g. static text)?  Why not have the screen access product and user get used
to a different paradigm?

I'll yield to the blind users and screen reader developers on this list when
it comes to the kind of user interface they prefer, but we have to remember
that there are a lot of other users with a lot of other needs arising from
their disability besides blind users with screen reaeders.  Putting things in
the TAB sequence makes any number of things easier for any number of folks.  

I encourage anyone who is thinking about "what is the best way for a blind
person/screen reader to do <foo>" to actually spend some time with a screen
reader and their monitor turned off (assuming you aren't already a screen
reader user!).  If you have a Windows box (or a Mac), you can download a demo
version of any of several to play with.  Figuring out what options are
available in any given situation via text-to-speech output is a pain.  Using
the TAB key almost exclusively simplifies this process; if you have to use a
bunch of different key sequences to discover whether or not various options
exist (by having them spoken to you), you will be much less likely to explore,
and much more likely to get frustrated with the *&@! box in front of you.


Whether having to remember that you close window via a standard keystroke in a
standard, accessible window manager (as compared to having a <CLOSE> button in
the TAB order) is too much of an additional cognitive strain or not is a
specific question to give to screen reader users and other users with other
disabilities.  But in general, the more special keys there are for special
things (which have to be remembered rather than simply found by "looking" at
the screen), the tougher things will be for our users with disabilities.


Regards,

Peter Korn
Sun Accessibility team