radiogroup and radio role discrepancy

[scottaohara]

radiogroup allows for the aria-readonly attribute.

radio does not list aria-readonly as a supported or inherited state/property.

i say that radiogroup allowing aria-readonly is incorrect... but i know opinions may be divided on that.

regardless, if the intent is the group can be set to readonly, thus meaning the radios within should be exposed as readonly, then radios should support this state.

[jnurthen]

I disagree - I have no issue with all the buttons in the group mapping the property in coreaam if this is how it needs to be implemented - but I do not think authors should be able to set read-only on a single radio button. It would be nonsensical for a group to consist of a mix of read-only and non read-only buttons.
I don't think this is any different than aria-required where we set this at a different level than HTML. If HTML were to support read-only then I think they would do it in the same way and map the attribute to all the buttons in the group.

[scottaohara]

Hmm. ok? Does that need to be called out then? that radios only support aria-readonly if inherited from a radiogroup?

it just read to me as a mismatch, since the attribute was supported at the group level, but not indicated as supported on the individual controls. Per the comparison to aria-disabled, it can be set at the group level, and on the individual controls, which is why i thought this was inconsistent.

[jnurthen]

but that makes sense for aria-disabled though right? An entire group can be unavailable, or a single option can be unavailable. The same doesn't logically apply for read-only or required.

[scottaohara]

Ha, I entirely missed the fact this is being done for aria-required as well with radios.

eh, ok. this is just another divergence from what HTML allows then i guess.