Re: Comment on the DTHML Style Guide for the button widget.

At 11:34 AM -0500 10 12 2007, Joseph Scheuhammer wrote:
>All,
>
>Reviewing the DHTML Style Guide word document from last week, I 
>recalled an idiom that may affect the recommendations regarding key 
>strokes for the button widget.
>
>The idiom is the "default button" or "default action" scenario.  It 
>is exemplified by a dialog that has a number of buttons, one of 
>which is designated as the default button.  For example, the dialog 
>may say "Do you want to save before quitting?", and the buttons are 
>"Yes", "No", and "Cancel", where "Yes" is the default action.  In 
>this case, pressing enter on the keyboard causes the document to be 
>saved, and the quit action to proceed.  Also, there may be a 
>specific key press connected to the cancel button, say the escape 
>key, such that one can cancel without tabbing to the cancel button, 
>and then hitting space.
>
>In general, for this idiom, the enter key stroke causes the default 
>button to fire, regardless of where keyboard focus is.  If DTHML is 
>to support this idiom, then activating a focused button with either 
>spacebar or enter will not work.  Or, rather, the context that the 
>button is embedded in determines whether enter will activate the 
>button when it has focus.

And those are problems.

Also, if the 'activate' a.k.a. default-action of the dialog-container
is the same action as the 'activate' action of a button in the
container, so far as I understand it (which is fuzzy) that is a bug.
How does the eyes-free user learn what the default action is if the
focus doesn't move to the control with that action and hence its
label gets announced?

So, again with the disclaimer that I don't really understand all of
this and would somebody please check me on this, but I believe our
Best Practice here would be to, on entering this dialog, move the
focus to the button that has the desired default action. If the focus
is then moved by arrow keys to another button, spacebar or enter
would be targeted to that object which has a handler for that event
and the container never sees it. Or at least the most
immediately-containing context handles it, which is the 'cancel'
button for example.

If you want to have 'escape' bind to 'cancel the dialog' regardless
of the focus being on another button, that works in that there is no
'escape key event' handler on that other button so that the event
bubbles up in the DOM to the dialog container and the handler there
cancels the whole dialog.

This leaves the problem of how does the eyes-free user learn about
this cancel keystroke.

Basically in two ways:

One is that the scripts build the help to explain the global (across
some context) keystrokes. The AOL WebMail interface is our leading
reference implementation of this sort of approach.

The other way the user learns is that this convention is present in
the platform OS and its GUI, and the browser is integrated with the
OS help system. The trick then is for there to be a neutral API
interface for a script to make a platform-neutral binding to the
platform-specific help. Don't think we are there yet. I think we need
to work on an approach to the layering and/or integration of help
services across OS, browser, script code, and AT.

I speak whereof I half know.  We're all learning, here.

>By the way, is this the correct place to submit comments on that 
>DHTML Style Guide?  Or, should I be adding these points to the DHTML 
>wiki?  Or somewhere else?

This is the number one place to discuss comments on the behavior and 
key bindings of these widgets.

Al

>
>Thanks.
>
>--
>;;;;joseph
>
>          '???'
>- "Bob", W. A. Yankovic -
>http://www.youtube.com/watch?v=RCG2E6AtNfc

Received on Tuesday, 11 December 2007 16:41:45 UTC