10479 2010-08-28 13:01:19 +0000 add role=radiogroup to details element 2010-12-15 14:37:13 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified PC All RESOLVED FIXED a11y P1 major --- 10066 1 faulkner.steve faulkner.steve annevk ian jackalmage laura.lee.carlson mike mjs public-html-a11y public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 38108 0 faulkner.steve 2010-08-28 13:01:19 +0000 Currently the details element has a default ARIA role =group and overrides allowed: Role must be either form, group, navigation, note, or search consider also allowing role=radiogroup 38359 1 jackalmage 2010-09-01 00:12:12 +0000 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. 38360 2 ian 2010-09-01 00:14:40 +0000 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 38362 3 faulkner.steve 2010-09-01 06:42:16 +0000 (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> 38363 4 mjs 2010-09-01 07:52:41 +0000 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. 38364 5 faulkner.steve 2010-09-01 07:55:41 +0000 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) 38525 6 ian 2010-09-07 16:55:23 +0000 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. 38557 7 faulkner.steve 2010-09-07 20:04:46 +0000 (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. 38634 8 annevk 2010-09-08 08:34:56 +0000 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? 38637 9 annevk 2010-09-08 08:36:14 +0000 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>. 38644 10 ian 2010-09-08 08:47:50 +0000 Ah, yeah, allowing that is a bug. I'll fix that. 39479 11 ian 2010-09-26 16:37:44 +0000 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. 39480 12 contributor 2010-09-26 16:38:17 +0000 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 43384 13 cooper 2010-12-15 14:37:13 +0000 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.