Need to allow for radiogroup inside toolbar #949
Comments
|
@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! |
mcking65
added
enhancement
|
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). |
|
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. |
For issue #949, modified the radio group pattern section aria-practices.html: * Divided the keyboard interaction subsection into two subsections: not in toolbar and in toolbar. * Added interactions for the special case of radios contained in toolbars.
|
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. |
|
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...?” |
Per feedback from @charmarkk in issue #949, revise left and right arrow descriptions for clarity. Changed to bulleted list of behaviors for each key. Per feedback from @jongund on the aria-practices list serve, added guidance for enter, up, and down keys.
|
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. |
…ars (pull #952) For issue #949, modified the radio group pattern section aria-practices.html: * Divided the keyboard interaction subsection into two subsections: not in toolbar and in toolbar. * Added interactions for the special case of radios contained in toolbars. * In toolbars, checked state does not follow focus and left/right can move focus outside radio group.
…d with updated radio group pattern The radio group pattern update made for issue #949 allows nesting a radio group in a toolbar. The toolbar pattern description previously included guidance that said to avoid including radio groups in horizontal toolbars. This change revises the description to clarify options for arrow key implementation, describing how one pair can be reserved for control operation. The reserved pair depends on toolbar orientation.
|
@carmacleod, thank you for raising this issue. It led to several improvements. It is now resolved in commit 211301f. |
In #847 (comment) @mcking65 said:
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)".
The text was updated successfully, but these errors were encountered: