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.

@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

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 w3c/aria-practices#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.

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>

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

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

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

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

There is an interested in posinset in toolbars.

###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.

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.