W3C home > Mailing lists > Public > wai-xtech@w3.org > August 2007

Re: argument for only ONE set of radio button navigation keys

From: Gregory J. Rosmaita <oedipus@hicom.net>
Date: Fri, 24 Aug 2007 16:16:30 -0400
To: Jon Gunderson <jongund@uiuc.edu>, wai-xtech@w3.org
Message-Id: <20070824200041.M78661@hicom.net>

aloha, jon!

thanks for pointing out something that i meant to address in 
my proposal -- if no preselected button is pre-selected, when
a user tab-navigates, or uses a LABEL plus an accesskey to 
enter the radiogroup, focus should be placed on the first 
button in the group -- if the radiogroup is "optional" and 
not required, then i can see simply giving the grouping 
focus, but for low vision users, i'm not sure that would be 
a particularly useful method, unless they have a setting to 
indicate focus (and/or announce focus) through a user-defined
border, as one can do with firefox, but i can't remember offhand
whether this is a native feature, a FAE feature, or an Accessibar
feature, and it would have to have at least 2 states -- this object
has focus and this object has focus and is checked/selected...

i'm uncomfortable with the idea of giving the grouping itself focus, 
although that could be programmatically expressed (this group contains 
X radio buttons), due to the fact that forms support is such a fickle 
proposition when using assistive technology, and, although i can only 
go by my own experience, i think that's precisely why dave and victor 
replied so quickly and enthusiastically -- ATs loose focus in forms 
constantly, and often for no apparent reason (without user interaction) 
and switching from a form to a document which contains one's credit card 
info when making a purchase, back to a form, the user often finds himself 
outside of the form or on a completely different form control -- or,
worse yet, in the address bar...  this is a particular problem with 
audio CAPTCHA -- if the audio isn't rendered natively by the UA,
one finds oneself in a mediaplayer instance, and has to simultaneously
listen to distorted sounds and pick out the meaningful ones, while 
switching back to the form and ensuring that he or she is in the 
CAPTCHA challange's answer box, which can be quite a juggleing 
act...

let me know if i completely missed the point of your question,
gregory.

----------------------------------------------------------------
CONSERVATIVE, n.  A statesman who is enamored of existing evils,
as distinguished from the Liberal, who wishes to replace them 
with others.         -- Ambrose Bierce, _The Devil's Dictionary_
----------------------------------------------------------------
             Gregory J. Rosmaita, oedipus@hicom.net
  Camera Obscura: http://www.hicom.net/~oedipus/index.html
----------------------------------------------------------------


---------- Original Message -----------
From: Jon Gunderson <jongund@uiuc.edu>
To: "Gregory J. Rosmaita" <oedipus@hicom.net>, wai-xtech@w3.org
Sent: Fri, 24 Aug 2007 14:50:30 -0500 (CDT)
Subject: Re: argument for only ONE set of radio button navigation keys

> Gregory,
> 
> If no button is selected what do you think about giving focus to 
> the radiogroup element?
> 
> Jon
> 
> ---- Original message ----
> >Date: Fri, 24 Aug 2007 13:48:30 -0400
> >From: "Gregory J. Rosmaita" <oedipus@hicom.net>  
> >Subject: argument for only ONE set of radio button navigation keys  
> >To: wai-xtech@w3.org
> >
> >
> >aloha, all!
> >
> >in a recent update to the ARIA Best Practices wiki, the following 
> >was added
> >
> ><quote cite="http://esw.w3.org/topic/RadioButton">
> >  * Pressing the arrow keys moves focus and selection.
> >  * Up or Left Arrow key press moves focus forward between buttons 
> >    in the group.
> >  * Down or Right Arrow key press moves focus backward between 
> >    buttons in the group
> ><unquote>
> >
> >i would like to register a vote of strong disagreement of such a 
> >keybinding -- there should be only ONE standardized mechanism for 
> >cycling through radio button groups/fieldsets regardless of how the 
> >grouping is visually presented: 
> >
> >GJR's PROPOSED CHANGE TO TEXT
> >
> >1) establish focus on a radio button group through TAB navigation or 
> >   activation of LABEL or ACCESSKEY (or equivalent) 
> >
> >2) cycle through radio button group using EITHER the up/down arrows 
> >   or the left/right arrows; i would prefer up/down, to accomodate 
> >   vertically aligned languages, as well as keeping the left/right 
> >   arrows for expand/collapse; 
> >
> >3) when focus is given to the radio button group, the focus should 
> >   start with the first radio button in the group, unless there is 
> >   a pre-defined default "on/checked" state, in which case the up/down 
> >   arrows go backwards and forwards from the default radio button 
> >   respectively 
> >
> >      * UpArrow = move backwards through radio button group; 
> >        user should have option to be informed that the upper 
> >        boundary has been reached, or the ability to loop in 
> >        both directions. 
> >
> >      * DownArrow = move forewards through radio button group; 
> >        user should have option to be informed that the upper 
> >        boundary has been reached, or the ability to loop in 
> >        both directions. 
> >
> >4) user can move out of radio button fieldset using TAB to go to next 
> >  form control or SHIFT + TAB to place focus on the previous form 
> >  control 
> >
> >END GJR's PROPOSED TEXT
> >
> >the thought of using left and right arrows is troubling because 
> >that is a general gesture for expanding and collapsing tree views,
> >while a radio button grouping should be covered by up and down 
> >arrows, regardless of the presentational layout of the radio 
> >button grouping, and the less users have to use the same buttons
> >for different widgets, the better the user experience...
> >
> >gregory.
> >
> Jon Gunderson, Ph.D.
> Coordinator of Assistive Communication and Information 
> Technology (DRES)
> 
> WWW: http://www.cita.uiuc.edu/
> WWW: https://netfiles.uiuc.edu/jongund/www/
------- End of Original Message -------
Received on Friday, 24 August 2007 20:16:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 13:15:43 GMT