Steps to reproduce:

1. Open attached code reproduction on Windows.
2. Enable NVDA.
3. Tab to focus the first radio in "Native Radios in List Items". Observe that NVDA announces the radio is "1 of 3".
4. Tab to focus the first radio in "role='radio' in List Items". Observe that NVDA announces the radio is "1 of 1".

Actual results:

NVDA announced that the first radio with "radio" role is "1 of 1" in the radio group.

Expected results:

I expect that NVDA announces the first radio with "radio" role is "1 of 3" in the radio group.

The Bugbug bot thinks this bug should belong to the 'Core::Disability Access APIs' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

If I'm understanding the spec correctly, Firefox is not wrong here:

Otherwise, if the role supports aria-posinset and aria-setsize, process the parent (DOM parent or parent defined by aria-owns), counting items that have the same role.

Putting aside the fact that it explicitly says "parent" (which doesn't exclude generics, though the ARIA spec does define "accessibility parent" to exclude generics), it says we should process the children of the parent. A listitem is not a generic, so it counts as a parent. There is only one child of that parent: a single radio.

Thanks for the reply and explanation. Given that the parent can be a DOM parent or defined by "aria-owns", does this mean that using "aria-owns" on the "radiogroup" element should yield the expected results?

I attached a "Code repro with aria-owns" file to show this behavior. I also checked Firefox + VoiceOver on macOS, and that yields the expected results even without using aria-owns.

(In reply to ldebeasi from comment #3)

does this mean that using "aria-owns" on the "radiogroup" element should yield the expected results?

Yes, although I agree it's kinda ugly.

I also checked Firefox + VoiceOver on macOS, and that yields the expected results even without using aria-owns.

For radio buttons, the Mac API wants us to expose the "linked UI elements"; i.e. all other radio buttons in the group. I guess VoiceOver calculates the position information from that. Other APIs don't have this concept.

All of this said, it seems that Chromium behaves differently on Windows, so I do think we should probably get this behaviour clarified in the spec.

does this mean that using "aria-owns" on the "radiogroup" element should yield the expected results?

Yes, although I agree it's kinda ugly.

It sounds like that might be a Firefox bug. The demo I posted above still reads "1 of 1" when using "aria-owns".

For more context on what I am trying to do:

I am trying to build a radio group in a list. The list itself contains the radio group, and each listitem contains a radio. In this case, would it not be correct to put each radio in a listitem? Maybe the listitem should have a "presentation" role instead since the radio/radiogroup relationship is more important?

Thanks again for all the help so far.

(In reply to ldebeasi from comment #5)

I am trying to build a radio group in a list. The list itself contains the radio group, and each listitem contains a radio. In this case, would it not be correct to put each radio in a listitem? Maybe the listitem should have a "presentation" role instead since the radio/radiogroup relationship is more important?

Thanks again for all the help so far.

Yeah, I think "presentation" role for the list item is a good solution. It allows you to align both the DOM's idea of the set (list items) and the accessibility's concept (radio buttons). For this to be done properly I would also override the role of the ul/ol.

edit: I didn't look at the examples above and only now realized that these are aria lists, not HTML lists.

As for the aria-owns example above, yeah that is a legitimate bug.

I can't reproduce the aria-owns issue:

<div role="radiogroup" aria-owns="a b">
  <div role="listitem">
    <div role="radio" id="a">a</div>
  </div>
  <div role="listitem">
    <div role="radio" id="b">b</div>
  </div>
</div>

The radio buttons report as "1 of 2" and "2 of 2" respectively.

Oh, I see the problem. Your test case does aria-owns="first,second,third". It should be aria-owns="first second third". With that fixed, it works as expected. So, I'm closing this as worksforme.

role=presentation is much cleaner though.

Thanks for catching the aria-owns mistake! Between that and role="presentation", everything seems to be resolved on my end.