This post is about dijit/form/Checkbox.js and the implementation of (grouped) radios.

There are at least 5 approaches to fully implementing radio group keyboard, mouse, and aria behavior:

1. Smart dojo radio buttons that can interact with the sibling radio buttons in the same group with respect to checked status as well as aria states "setsize" and "posinset". Note that each time a radio button is created or destroyed we must iterate over all elements in the same group to make sure the tab index, and the aria states are correct. We don't know in the context of a widget if it is the last in the group or if there are more coming (perhaps during initial creation, or perhaps coming programmatically at any time).
2. Use a real "html radio button" for keyboard navigation and operation that is higher in the z-order, but is transparent (opacity:0). This would interact with the dojo "view" that sits underneath.
3. Create a dojo radio group widget.
4. Have the dojo radio widget pass all events on to the inner inputNode (html radio widget that has "display: none" style), and have the dojo radio widget react only to onchange events from the html widget. This didn't work. I include it only so we don't redo the work.
5. Try the former but instead of keeping the current "display: none" style, hide it in some other way. Feels kludgey?.

My first attempt was #1. In case you want to play with radio groups with my changes you can try my sandbox test. You can try tabbing around and once you get to a radio group you can try selecting a radio button (spacebar), or if one is already selected the tab should only take you to that radio and then arrowing should provide the ability to change the selected (checked) radio. Related trac ticket is: Ticket #2420 (updated radio a11y support). It is felt that the radio button widget might be becoming too heavy as we implement group behavior to mimic the browser implementation and as we implement aria states that are based on grouping. I feel we may have to live with allowing users the option of these smart radios or using the regular html ones.

My second attempt was #2. After chatting with Bill Keese, we decided it is worthwhile for me (David Bolter) to investigate this approach. To reduce the problem space an investigation was conducted using vanilla JavaScript (with no dojo core). The CSS might not be right and any help is welcome. Here are the first pass efforts for approach #2:

• divs
• spans

The first attempt is a little less embarrassing. It only seems to work in FF, and even there the labels are not lined up properly. The user interacts with the transparent (html) radio overlays, and the onchange handler updates the views underneath. If you want to see details please view the source, and also consider using the Firebug inspect tool (on FF) which will let you "see" the overlay. The second attempt doesn't seem to provide the user with the ability interact with the radio overlays.

I haven't attempted #3. It moves away from the current way web developers implement radio groups (which is grouping by common name attribute values).

#4 is a no go.

I haven't tried #5 yet.

I think that if we want to stay as close to possible to the way existing radios work and have consistency and stability across browsers we should continue with approach #1 but I am very new to Dojo and would be interested to hear from others.

Thoughts?