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

At 1:48 PM -0400 24 08 2007, Gregory J. Rosmaita wrote: 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:

[snip - original post+discussion at
http://lists.w3.org/Archives/Public/wai-xtech/2007Aug/thread.html#msg122 ]

In a joint session with CSS WG and others on two-dimensional
navigation (Member-only link)
http://lists.w3.org/Archives/Member/w3c-html-cg/2006JanMar/0115

It came out that CSS has been assuming that arrow keys would be bound
so as to be consistent with the layout for use in a Television device
context. The emerging Mobile market has similar needs; there is a
four-way or eight-way navigation rosette that is generally used in a
way that reflects the compass points within the layout.

At that meeting, although this was a fact-finding caucus and not a
consensus decision, it was generally understood that both "graphical"
binding of arrow keys (as in tables and the Television precedents)
and "logical" binding (as in DAISY and the tree widget) would
co-exist in Web content, with the one firm accessibility requirement
that the user must know what is in effect and strong accessibility
preference that the user be able to control this binding. [errors in
this synopsis are mine].

Binding left/right arrows to radio buttons that are displayed in a
left-right row is consistent with the user's learning of table
navigation and mobile applications.

Disabling left-right navigation among radio button groups in Web
pages while installed applications enable them will adversely affect
the Web access of persons with vision and some cognitive conditions.

On the other hand, enabling left-right navigation among radio button
groups in Web pages may lead to increased blunder rates for people
without layout cues and especially for those with haptic-affecting
neuropathy as well.

My basic point is that this is an issue that has people with
disabilities on both sides of it.

Remembering large vocabularies of key bindings is a cognitive
challenge that many visually impaired users surmount because there is
major benefit to their doing so. But this is not 'everyone.'

On balance, I am afraid that I think that "the precedent set by the
cliches of installed software interaction" is a safe haven for
WAI-ARIA 1.0. There are lots of ways that we can contemplate making
the interface better for someone or other; but we stand a not too
good chance of making this a widespread habit. Where we are trying to
unify the widespread habits between installed Applications and Web
Applications, it is easier to believe that our proposals will gain
uptake.

For the most part (personal opinion), WAI-ARIA 1.0 should stick to
porting existing good access practice from the installed application
world to the Web application world. In selected cases we will go
beyond that such as where there is an outright function failure
unless we do.

But unless we keep a tight rein on those few exceptions from features
with prior art in installed applications, we will take a long time
arguing the better against the good, and fail to get the good
deployed soon.

Al

Received on Sunday, 26 August 2007 22:08:37 UTC