- From: Chris Blouch <cblouch@aol.com>
- Date: Mon, 27 Aug 2007 13:01:29 -0400
- To: Jon Gunderson <jongund@uiuc.edu>
- CC: "Gregory J. Rosmaita" <oedipus@hicom.net>, wai-xtech@w3.org
- Message-ID: <46D30369.1060101@aol.com>
While it may be bad UI design I have seen behavior in the wild, usually in the form of protecting users from themselves, where selection of a radio button triggers a confirmation. So if you have two radio buttons, say a choice of good and evil, selecting evil pops up a confirm box warning you that you must be over 18 to choose it. If reading a radio button also causes selection a user might trigger confirmation boxes or other disruptive behaviors without intending to. This type of quantum behavior, where mere inspection changes the object of interest, seems like an unforgiving model. I was unclear from today's call whether our recommendation on keyboard controls for radio button navigation enables this unfriendly behavior. CB Jon Gunderson wrote: > Gregory, > > In providing focus to the radio group the label for the group could be read along with the number of buttons, this would provide information about the grouping of buttons. > > For low vision users as soon as they press down arrow key the first radio button in the group would be selected. If the first button gets focus on tab, pressing down arrow would select the second radio button. > > Jon > > ---- Original message ---- > >> Date: Fri, 24 Aug 2007 16:16:30 -0400 >> From: "Gregory J. Rosmaita" <oedipus@hicom.net> >> Subject: Re: argument for only ONE set of radio button navigation keys >> To: Jon Gunderson <jongund@uiuc.edu>, wai-xtech@w3.org >> >> >> 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 ------- >> >> >> > 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/ > > > >
Received on Monday, 27 August 2007 17:02:32 UTC