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

Al,

Al Gliman wrote:
> 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? 

This could be a question directed at a screen reader functionaliy, or 
DHTML, or user interfaces in general.  Regardless, if one were to 
re-phrase it from the point of view of a sighted user, then the answer 
is apparent.  So:

How does the sighted 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?

Because the default button is rendered differently -- the default button 
has, say, a darker border around it.  I would hope (but I'm bound to be 
disappointed) that an analogous audio and/or braille rendering is given 
for the eyes-free user.  That implies (and this is the root of my 
disappointment) that the default action/button is published such that an 
AT can inform the user of same, and that there is some way for the user 
to ask, "what is the default action?"  In the case of rich internet 
applications, this sounds like something ARIA would support.  I don't 
believe it does, though.

> ... on entering this dialog, move the
> focus to the button that has the desired default action.

That is a good idea.

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

That is tantamount to saying that the default action/button idiom will 
not be supported, which is certainly an option.  Personally, I like the 
idiom.  I like the fact that I don't have to navigate to the default 
button in order to activate it if focus happens to be elsewhere.  I can 
simply dismiss the dialog with a single keystroke at any time.  I find 
that convenient.  But, I am but one user.

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

If 'escape' is can be handled, why not the default action?  Yes, I 
understand that there are issues regarding capture and bubbling, but 
those are implementation details, hopefully.  What I think it comes down 
to:  is there a single keystroke that can be applied to "accept" the 
dialog, and another to "reject" it, regardless of where focus is.  
Perhaps "enter" is not the correct keystroke for acceptance.  Perhaps 
one could use "cntl-enter" or "alt-enter", implying a concept of a 
higher level enter that supercedes the button with focus.

-- 
;;;;joseph

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

Received on Monday, 17 December 2007 20:38:20 UTC