The 'radiogroup' role is nonsensical for a <details> element.  The <details> element can't represent "a type of select list that can only have a single entry checked at any one time" without serious hackery.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: see comment 1

(In reply to comment #1)
> The 'radiogroup' role is nonsensical for a <details> element.  The <details>
> element can't represent "a type of select list that can only have a single
> entry checked at any one time" without serious hackery.

where is the serious hackery here:

<details>
<summary> choose one</summary>
<input type="radio">choice 1
<input type="radio"> choice 2
<input type="radio"> choice 3
</details>

Full definition of radiogroup role is here:
http://www.w3.org/WAI/PF/aria/roles#radiogroup

The initial sentence is "A group of radio buttons," which I think is more relevant than the later elaboration.

I am not sure offhand if it is good UI to have a bunch of radio buttons (and no other controls?) in a <details>, but if one is checked by default, it could be a plausible way to hide an expert setting that most users would not want to mess with. It certainly is mechanically possible to do, as Steve's example demonstrates.

working example: http://www.paciellogroup.com/blog/misc/HTML5/radio.html
note: only hackery used is to simulate the behaviour of details/summary as it is not yet supported in any browser (that I know of)

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: If you changed the role of a <details> element, the user could no longer expand the <details> element to get to its contents. That would be a net loss of accessibility. If you have a group of radio buttons inside a <details> and you need to wrap them with role=radiogroup, then you should use an element for that group; <details> is not it.

(In reply to comment #6)
> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, please change the state of this bug to CLOSED. If
> you have additional information and would like the editor to reconsider, please
> reopen this bug. If you would like to escalate the issue to the full HTML
> Working Group, please add the TrackerRequest keyword to this bug, and suggest
> title and text for the tracker issue; or you may create a tracker issue
> yourself, if you are able to do so. For more details, see this document:
>    http://dev.w3.org/html5/decision-policy/decision-policy.html
> 
> Status: Rejected
> Change Description: no spec change
> Rationale: If you changed the role of a <details> element, the user could no
> longer expand the <details> element to get to its contents. That would be a net
> loss of accessibility. If you have a group of radio buttons inside a <details>
> and you need to wrap them with role=radiogroup, then you should use an element
> for that group; <details> is not it.

The following does not make sense, please explain why:

> If you changed the role of a <details> element, the user could no
> longer expand the <details> element to get to its contents.

I think Ian's point is that setting the role attribute overrides the default semantics of the <details> element. The default semantics allow you to expand the <details> element.

So maybe the right answer here is to not allow the role="" attribute on the <details> element as it would no longer function correctly?

I.e. if you did <details role=search> the AT-client would get it back as a "search" entity rather than a <details> entity and would not offer the user the ability to expand the element. The same for <details role=radiogroup>.

Ah, yeah, allowing that is a bug. I'll fix that.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: So I went to make sure that "search" didn't support aria-expanded, but it does. So then I checked what did, and I realised that I'd made a mistake and not just direct "group" descendants support aria-expanded, but a whole bunch of roles do. So I changed the spec to allow any of the roles that support aria-expanded, including role=radiogroup.

Checked in as WHATWG revision r5511.
Check-in comment: For <details>, allow any of the roles that support aria-expanded.
http://html5.org/tools/web-apps-tracker?from=5510&to=5511

Big triage sub-team thinks the ARIA mapping team should review and update this bug as the mappings are prepared, but no need for entire HTML A11Y TF to review. Assigning to Steve Faulkner to track.