Need to allow for radiogroup inside toolbar

[carmacleod]

In #847 (comment) @mcking65 said:

The only real barrier to using the existing radio group pattern in a toolbar is that the checked state cannot follow focus like in normal radio groups because the arrow keys are needed to navigate to other elements in the toolbar. That means requiring the user to press space to check the radio. Maybe that is OK.

Personally, I think that is absolutely ok. As a bonus, it's the way the old Windows desktop toolbars work. The arrow keys move the focus without changing the selection, and then space or enter selects the currently focused radio tool. Arrow keys do not wrap within the radiogroup - they simply move focus into the next part of the toolbar.

Testing google docs toolbars, I see that they behave the same as the old Windows desktop toolbars (except that they bogusly don't activate on space - only on enter. I've opened a Google Docs issue for that).

So I'm splitting this out of #218 because I think the specific issue of radiogroups in toolbars needs to be addressed right away so that the Toolbar example for simple text editor can be released containing a more correctly semantic "radiogroup" with "radio" children instead of the workaround of a "menu" with "menuitemradio" children.

I think this is not a difficult update to the radiogroup pattern, and there's already well established precedent for the behavior, so perhaps it is as simple as splitting the Keyboard Interaction section into 2 subsections, one with "For a radiogroup that is not inside a toolbar: (bulleted list here)", and the other with "For a radiogroup that is in a toolbar: (other bulleted list here)".

[mcking65]

@carmacleod, thank you thank you for the examples of precedence. I was not aware of them.

I personally wanted to make the toolbar radios the way you suggest, but the rest of the task force thought that would be confusing because of the conflict with the radio pattern. But, if we specifically adjust the radio pattern for toolbars, as suggested by this issue, and if we have precedence to justify it, then I am 1000% on board. I would love to get rid of the menuitemradios in the toolbar; they were the only workaround I could dream up that is consistent with all other patterns.

This is going on tomorrow's agenda. Thanks!

[jongund]

If the working group agrees to the use of radiogroup, the code for the toolbar example would be simple to change. The radio group role makes more sense to me than menu too in this case. It seems this issue raises of consideration of a toolbar radio roles in the ARIA spec, but that would not be something the practices could provide guidance on for a long time (if ever).

[mcking65]

We spent most of today's meeting discussing this issue. We are going to move forward with modifying the radio group pattern and adjusting the implementation of the toolbar example.

[mcking65]

My proposal for a resolution to this issue is available for review in the issue949-radios-in-toolbars feature branch in section 3.16 Radio Group.

[charmarkk]

I wonder if the descriptions might be a bit wordy? That is, I worry the “Or”s might trip some folks up. Is it possible to condense/should we condense?

Maybe at the very least we have “if...,” “or if...,” and “otherwise if...?”

[mcking65]

Thank you @charmarkk. I agree that it was too much to put all the conditional behaviors for left and right into a single list item. I used the type of language and formatting we employed in the tree pattern where we have a similar situation; there is a single key with three different conditional behaviors.

@jongund, thank you for the feedback on the list about enter, up, and down keys. I have added them as optional per our Monday discussion. I toyed with the idea of explaining why enter is optional and decided not to do so primarily because we generally do not explain why specific keys are optional. However, this situation feels atypical. A reason that was equally important; after a decent chunk of time playing with words, I didn't find anything short enough that I thought would be helpful.

You can now see commit 4b131ae rendered in the feature branch.

[mcking65]

@carmacleod, thank you for raising this issue. It led to several improvements. It is now resolved in commit 211301f.