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

If it's helpful, I've recently written a LinkedIn article at
http://lnkd.in/jYnkZq
Which illustrates the fundamental differences between keyboard and screen 
reader accessibility.

This also has a link to a page with precise coding guidance for creating 
ARIA radio buttons.

 All the best,
Bryan

----- Original Message ----- 
From: "Ramón Corominas" <listas@ramoncorominas.com>
To: "WAI Interest Group" <w3c-wai-ig@w3.org>
Sent: Saturday, July 21, 2012 2:28 AM
Subject: 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 19:10:29 UTC