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

of course, jaws currently does just the opposite, if you are not in forms 
mode, you have to tab through the radio buttons, if you are, you can tab pas 
them with one keystroke with the top most one being selected.

----- Original Message ----- 
From: "Gregory J. Rosmaita" <oedipus@hicom.net>
To: "Jon Gunderson" <jongund@uiuc.edu>; <wai-xtech@w3.org>
Sent: Friday, August 24, 2007 11:11 PM
Subject: Re: argument for only ONE set of radio button navigation keys



aloha, jon!

i think you've alleviated my fears -- i thought that
programmatically it would be possible for speech output and
braille, and your scenario does make sense -- give the group
focus and let the user decide if it is pertinent without
having to navigate the entire group, as a matter of fact,
i would like a user-override of pre-selected boxes in favor
of tab navigation giving the grouping focus, and the user
the choice of navigating the form -- especially if it is
a long form, which the user wants to inspect before filling
out, so YES i would support tab and shift-tab to move foucus
to a group, and user-initiated descent into the group or
tabbing to the next grouping, receiving information about
each group: it's LEGEND -- either explicit or ersatz -- the
number of items in the group, and whether or not one is
preselected, and if so, the contents of the label (again
either explicit or ersatz) associated with that item

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 16:08:01 -0500 (CDT)
Subject: Re: argument for only ONE set of radio button navigation keys

> 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/
------- End of Original Message -------

Received on Saturday, 25 August 2007 12:44:50 UTC