Re: Non-standard behaviour in radio-group keyboard interaction [Was: Slides of my WAI-ARIA presentation at SpainJS event]

Hi, Brendan and all.

Brendan McKeon wrote:

 > Just one quick note on the slide deck & code; meant to send this
 > sooner but got caught up in the topic of input instead! -
 > The 'custom' radio buttons in your example use a different
 > keyboard model than the standard one (or, at least the behavior
 > I'm seeing on IE/Chrome/FF on Windows). With standard radio
 > buttons, tabbing into the group gives the selected on focus
 > - as is the case with yours. But from that point, as you
 > move with the arrow keys, standard radio buttons also change
 > selection and focus together, so there's no need to move focus
 > and activate vis enter separately.
 >
 > This could confuse a user who is expecting the standard behavior,
 > who tabs to the set, arrows around, tabs out, and is then confused
 > why their attempt to change selection didn't have any effect.
 > Generally speaking, when writing a custom version of a control,
 > you want to follow the interaction model of the original/standard
 > control as closely as possible.
 >
 > There's an example HTML radio button set on this page:
 > http://www.quackit.com/html/codes/html_radio_button.cfm
 > ...and a custom ARIA-enabled one here:
 > http://test.cita.illinois.edu/aria/radio/radio1.php


Indeed, the behaviour that I implemented is exactly how a radio-group 
works... When JAWS is active. Unfortunately, the "normal" behaviour you 
described changes if JAWS is active (you can test it with a normal 
radio-group and see the difference). I used FF 13 + JAWS 13 for the 
demos, so it worked "as expected" (when JAWS is active).

This is a big issue that I admit don't know how to solve, so I opted for 
the (IMO) best bad solution. Most users will use a mouse/finger, so they 
won't even notice the different behaviour. Sightet keyboard users will 
see the focus changing, but the radio buttons not changing their states, 
so I assume they will use space bar to activate them (typical behaviour 
in checkboxes). I'm conscious this is not the standard behaviour, but I 
think it causes minor impact (although it can still be a bit confusing, 
of course).

Does anyone have a better solution?

Chaals: this is one of those problems I wanted to arise. Tabindex 
doesn't help much when you have radio-groups or other complex UI 
components that must gain the focus as a group, not as single elements. 
In these cases, tabindex is not enough, and it is absolutely necessary 
to provide explicit keyboard interaction; indeed, focus must be moved 
through scripting and tabindex dynamically changed to provide the proper 
behaviour.

More examples:

- Slider: focus moves to the slider object and then we need to provide 
keyboard events for the arrow keys to increase/decrease its value; 
tabindex does nothing here.

- Tab panel: focus goes first to the active tab in the tab list, and 
next to the contents of the active tabpanel (not to the next tab); we 
have to dynamically move focus to other tabs and set their tabindexes 
when the user presses left/right arrow or Control+Tab/Control+Shift+Tab 
(at least in Windows).

- Tree panel: focus goes to the active tree node; pressing 
Tab/Control+Tab moves away from the tree panel to the next focusable 
element. We need to provide specific keyboard events for the arrow keys 
and plus/minus keys to move the focus to other tree nodes and also to 
open/close nodes (this is a truly complicated one, we need to check 
open/closed nodes to precisely control focus).

If we attach to one platform (Windows, for example), the above examples 
can be relatively easy to solve (behaviour doesn't change when the 
screen reader is active), but I know that some of these behaviours 
change also between different OS's. How should we solve these cases 
then? I guess that browser detection is the only way, but I don't like 
it very much. Will Indie UI solve theseproblems? I hope so...

And, of course, non-standard components or custom interfaces will 
probably require specific keyboard interaction that we cannot solve with 
a simple tabindex.

Regards,
Ramón.

PS: The ICITA radio-group is still more confusing, if you change from a 
radio button to another and then press Tab / shift+Tab, it changes the 
selected option without notifying it to the screenreader. I suppose this 
is an old ARIA test, but in JAWS 13 + FF 13 it doesn't work as expected.

Received on Saturday, 21 July 2012 09:33:39 UTC