Consider a mechanism to associate controls without an explicit grouping

[scottaohara]

This is semi-related to my previous issue #1442 as the impetus for this issue is the fact that HTML allows for radio buttons to be associated with each other without the need of a parent grouping element (e.g., via the name attribute having the same value).

The reason this is related to the previously mentioned issue is that with ARIA, the only way to indicate that choosing a radio button is required in a set of radio buttons is for that to be declared on the radio group parent.

However, consider the following markup:

<label><input type=radio name=c required>Choice 1</label>
content / additional form fields that are related to choice 1
...
<label><input type=radio name=c>Choice 2</label>
content / additional form fields that are related to choice 2
...
<label><input type=radio name=c>Choice 3</label>
content / additional form fields that are related to choice 3

The above wouldn't neatly fit into a radiogroup, as the layout requires additional content and controls that don't make sense (? or at least not to me/it isn't clear per the spec that they'd make sense either) to be children of a group that is specifically defined as being for radios. The suggestion that ARIA makes to use aria-owns to revise the DOM hierarchy to force-include radio buttons within a radiogroup would be problematic here as the programmatic reading order of the above markup is important, and if that were altered then it'd be exposed as if it was marked up as:

<fieldset role=radiogroup aria-label=foo aria-required=true>
  <label><input type=radio name=c>Choice 1</label>
  <label><input type=radio name=c>Choice 2</label>
  <label><input type=radio name=c>Choice 3</label>
</fieldste>

content / additional form fields that are related to choice 1
...
content / additional form fields that are related to choice 2
...
content / additional form fields that are related to choice 3

where now the radio buttons are all programmatically exposed in a single grouping (for the browsers that support aria-owns), but now the content that previously relied on the radio buttons being in the programmatic reading order prior to the content they introduced is lost. Additional remediation efforts would be needed to re-introduced to delineate the boundaries of each choice's content/further controls.

---

Sure, we could just not use ARIA radios / radiogroup here and rely on HTML alone... but this seems like something that ARIA should have a mechanism for (attribute parity), and arguably it could be useful in other situations too. E.g., identifying that a series of radio buttons or standard buttons part of an implicit group by announcing an x of y numeration to them.

[JAWS-test]

Maybe a solution would be that group and radiogroup can be used synonymously in the future? Like none and presentation. In HTML there is also only <fieldset>.

In HTML AAM, <fieldset> refers only to group and not to radiogroup.

Then only the mapping in Core AAM would have to be changed for UIA and AX API, because there the two differ (The mapping for UIA is possibly even wrong, because it is once Group and once List - this does not seem to make sense to me). For MSAA and ATK/AT-SPI there are no differences between group and radiogroup.

[scottaohara]

@cookiecrook just CC'ing you here per the concept of associating elements without needing to group them that came up in our deep dive today

[brennanyoung]

Radio buttons with additional related fields (particularly fallback text input for "none of the above" radio buttons) are not unusual. It's not clear how to associate a "none of the above" radio button with a text input that allows the user to specify an alternative.

See https://github.com/w3c/aria-practices/issues/2576

And if we interpret the spec to say that radiogroup should only contain operable elements of role radio (as deque/aXe certainly do), then the spec throws a log in the road for no good reason.

At the very least, the spec should be clearer about which other roles (if any) are permitted inside radiogroup. More importantly (and fully in line with the OP here) how the value of one ui control/widget might be further specified by another.

[jnurthen]

where now the radio buttons are all programmatically exposed in a single grouping (for the browsers that support aria-owns), but now the content that previously relied on the radio buttons being in the programmatic reading order prior to the content they introduced is lost. Additional remediation efforts would be needed to re-introduced to delineate the boundaries of each choice's content/further controls.

@scottaohara wouldn't this be a good place to use aria-controls (if it actually did anything useful) to indicate the relationship between the button and the controlled element

<fieldset role=radiogroup aria-label=foo aria-required=true>
  <label><input type=radio name=c aria-controls=1>Choice 1</label>
  <label><input type=radio name=c aria-controls=2>Choice 2</label>
  <label><input type=radio name=c aria-controls=3>Choice 3</label>
</fieldste>

<div id="1">content / additional form fields that are related to choice 1</div>
...
<div id="2">content / additional form fields that are related to choice 2</div>
...
<div id="3">content / additional form fields that are related to choice 3</div>

[JAWS-test]

Variant 2 of @scottaohara (no matter if with or without aria-controls) would be a violation of WCAG 1.3.2: Meaningful Sequence in my opinion

[spectranaut]

Discussed briefly in today's meeting: https://www.w3.org/2023/12/07-aria-minutes.html#t05

[spectranaut]

We talked about whether or aria-posinset was calculated and exposed automatically via the accessibility API on chromium, and you can see for this html with treeitems it is:

• HTML: https://source.chromium.org/chromium/chromium/src/+/main:content/test/data/accessibility/aria/aria-tree.html
• Linux ATSPI tree: https://source.chromium.org/chromium/chromium/src/+/main:content/test/data/accessibility/aria/aria-tree-expected-auralinux.txt

[spectranaut]

Discussed in the 12/14 meeting: https://www.w3.org/2023/12/14-aria-minutes#t04

There is an interested in posinset in toolbars.

[MarioBatusic]

A trial of a suggestion

1. radiogroup role should not limit the "allowed child roles" to radio - as is currently: The spec 1.3 has not yet an entry for "allowed child roles".
2. If there is no existing parent radiogroup the browser creates one in the accessibility tree
3. the author sets the name for the virtual radiogroup by setting aria-describedby or aria-description to one of radio buttons in the group.
4. browser copies this value as aria-labelledby or aria-label to the virtual radiogroup in the accessibility tree.
5. Browser copies the possibly set required or aria-required=tru to the aria-required=true on the virtual radiogroup in the accessibility tree. Only a possibility. I'm not sure if it is real to hope that the browsers will implement it, but it would solve the ARIA mappings and semantics.

[scottaohara]

i don't think it makes sense for the browser to just create a radio group parent. how could it possibly handle two instances of what are meant to be separate radio groups?

using a description to force a name for this browser created radiogroup would have the potential to create groups with unwanted names (e.g., an error message, or actual descriptions for a single radio that are not applicable to other radio choices).

It'd be a lot safer to not have the browser guess at groupings, or modify existing attributes into new unexpected behaviors.

Thinking about this more, it probably would be best to even just work on your first point - make it clear that a radiogroup can contain elements other than radios (which is not exactly disallowed now, but the spec could be more overt that it is allowed). A note/author guidance could then also be added to be like "hey, you can do this to reach parity with HTML, but maybe also don't because it'll likely result in some awkward UX"

Then if someone does need to have some zany layout with radio buttons intermixed with other content, they would need to wrap all of that into a radiogroup container that encompasses all the radio buttons.