Per spec the summary element itself is not a control, it has an anonymous widget that is the control.

(In reply to steve faulkner from comment #0)
> Are there any use cases for allowing interactive descendants?

https://discussions.apple.com/servlet/JiveServlet/showImage/2-23821765-332751/Screen+Shot+2013-11-17+at+1.40.08+PM.png
http://www.crsp.com/files/images/scan_options.jpg
http://i.msdn.microsoft.com/dynimg/IC115703.png
http://www.lennonbus.org/images/blog/post_images/Screen_shot_2010-05-27_at_1.59_.42_PM_.png
http://www.oreillynet.com/digitalmedia/blog/images/bwaperture.jpg

(In reply to Simon Pieters from comment #2)
> (In reply to steve faulkner from comment #0)
> > Are there any use cases for allowing interactive descendants?
> 
> https://discussions.apple.com/servlet/JiveServlet/showImage/2-23821765-
> 332751/Screen+Shot+2013-11-17+at+1.40.08+PM.png
> http://www.crsp.com/files/images/scan_options.jpg
> http://i.msdn.microsoft.com/dynimg/IC115703.png
> http://www.lennonbus.org/images/blog/post_images/Screen_shot_2010-05-27_at_1.
> 59_.42_PM_.png
> http://www.oreillynet.com/digitalmedia/blog/images/bwaperture.jpg

thanks, its difficult to tell from the screenshots alone whether the usage represent reasonable use cases or not. One thing I noted was in the example http://i.msdn.microsoft.com/dynimg/IC115703.png there is a focus rectangle around the auto updating 'summary'. I had a look at the interface in 8.1 and found that the whole 'summary' is clickable and exposed as a button in acc APIs.

Currently I think the control aspect of details/summary is underspecified as there is no method to provide an accessible name (LABEL)for the 'anonymous control' that allows operation of the widget. whereas the accessibility implementation example provided in the HTML acc API spec [1] does provide  clear advice.

Also from an accessibility/usability perspective having the summary element as the actionable control provides a large activation area, as does the current (seemingly) broken implementations. 

thus the suggestion in this bug to restrict the content allowed in summary.

Do you see a way the specification of the summary/details element can be improved to both allow nested controls and provide a clear method to associate a visible label, with a large enough click area to accommodate accessibility/usability requriements?


[1] http://rawgithub.com/w3c/html-api-map/master/index.html#accessible-feature-implementation-examples

(In reply to steve faulkner from comment #3)
> thanks, its difficult to tell from the screenshots alone whether the usage
> represent reasonable use cases or not.

Yeah, I picked things from a Google Image search for 'form disclosure triangle' (or some such), I'm not confident all of them are valid.

> One thing I noted was in the example
> http://i.msdn.microsoft.com/dynimg/IC115703.png there is a focus rectangle
> around the auto updating 'summary'. I had a look at the interface in 8.1 and
> found that the whole 'summary' is clickable and exposed as a button in acc
> APIs.

OK.

> Currently I think the control aspect of details/summary is underspecified as
> there is no method to provide an accessible name (LABEL)for the 'anonymous
> control' that allows operation of the widget. whereas the accessibility
> implementation example provided in the HTML acc API spec [1] does provide 
> clear advice.

If the triangle needs an accessible name, can't it get the accessible name from the summary element?

> Also from an accessibility/usability perspective having the summary element
> as the actionable control provides a large activation area, as does the
> current (seemingly) broken implementations. 
> 
> thus the suggestion in this bug to restrict the content allowed in summary.
> 
> Do you see a way the specification of the summary/details element can be
> improved to both allow nested controls and provide a clear method to
> associate a visible label, with a large enough click area to accommodate
> accessibility/usability requriements?

How does e.g. OS X solve the large click area requirement?

The triangle's click area doesn't need to be small, per spec, AFAICT.

(In reply to Simon Pieters from comment #4)
> (In reply to steve faulkner from comment #3)
> > thanks, its difficult to tell from the screenshots alone whether the usage
> > represent reasonable use cases or not.
> 
> Yeah, I picked things from a Google Image search for 'form disclosure
> triangle' (or some such), I'm not confident all of them are valid.
> 
> > One thing I noted was in the example
> > http://i.msdn.microsoft.com/dynimg/IC115703.png there is a focus rectangle
> > around the auto updating 'summary'. I had a look at the interface in 8.1 and
> > found that the whole 'summary' is clickable and exposed as a button in acc
> > APIs.
> 
> OK.
> 
> > Currently I think the control aspect of details/summary is underspecified as
> > there is no method to provide an accessible name (LABEL)for the 'anonymous
> > control' that allows operation of the widget. whereas the accessibility
> > implementation example provided in the HTML acc API spec [1] does provide 
> > clear advice.
> 
> If the triangle needs an accessible name, can't it get the accessible name
> from the summary element?

problems include:

unclear how accessible name from <summary> is bound to anonymous control in shadow dom?

If the summary element continues to be allowed to include controls how is a useful accessible name to be calculated?
e.g.

<summary> major pain <input type=checkbox> also show minor pain (max number of minor pains <input type=number>) </summary> 



> 
> > Also from an accessibility/usability perspective having the summary element
> > as the actionable control provides a large activation area, as does the
> > current (seemingly) broken implementations. 
> > 
> > thus the suggestion in this bug to restrict the content allowed in summary.
> > 
> > Do you see a way the specification of the summary/details element can be
> > improved to both allow nested controls and provide a clear method to
> > associate a visible label, with a large enough click area to accommodate
> > accessibility/usability requriements?
> 
> How does e.g. OS X solve the large click area requirement?

they don't, but that does not mean we should replicate OS X poor ui.

> 
> The triangle's click area doesn't need to be small, per spec, AFAICT.

sure, asking to increase the size so it is a usable for people with fine motor skill impairments is an ask that will often not be met. having the summary element represent the click area by default = built in  usability/accessibility.

(In reply to steve faulkner from comment #5)
> problems include:
> 
> unclear how accessible name from <summary> is bound to anonymous control in
> shadow dom?

I'm not entirely familiar with either the accessibility stuff or shadow DOM, but I don't see why it would be problematic to define in the spec that the anonymous control gets its accessible name from the <summary>. The UA knows how to get from one to the other since it's needed for open/close to work.

> If the summary element continues to be allowed to include controls how is a
> useful accessible name to be calculated?
> e.g.
> 
> <summary> major pain <input type=checkbox> also show minor pain (max number
> of minor pains <input type=number>) </summary> 

Just calculate the accessible name using the generic rules to calculate an accessible name for an element. In the case above IIRC the accessible name would be the text, but the author can override it with aria-label or so.

> they don't, but that does not mean we should replicate OS X poor ui.

> sure, asking to increase the size so it is a usable for people with fine
> motor skill impairments is an ask that will often not be met.

I think it's a bad idea to work around accessibility failures in OS X (and others) when designing new HTML features. It would be better for OS X (and others) to fix their accessibility failures so that all disclosure triangles are usable by people with motor disabilities, not just Web apps that use <dialog>.

> having the
> summary element represent the click area by default = built in 
> usability/accessibility.

Unfortunately it makes it *not* usable when it includes interactive content.

s/dialog/details/

(In reply to Simon Pieters from comment #6)
> (In reply to steve faulkner from comment #5)
> > problems include:
> > 
> > unclear how accessible name from <summary> is bound to anonymous control in
> > shadow dom?
> 
> I'm not entirely familiar with either the accessibility stuff or shadow DOM,
> but I don't see why it would be problematic to define in the spec that the
> anonymous control gets its accessible name from the <summary>. The UA knows
> how to get from one to the other since it's needed for open/close to work.
> 
> > If the summary element continues to be allowed to include controls how is a
> > useful accessible name to be calculated?
> > e.g.
> > 
> > <summary> major pain <input type=checkbox> also show minor pain (max number
> > of minor pains <input type=number>) </summary> 
> 
> Just calculate the accessible name using the generic rules to calculate an
> accessible name for an element. In the case above IIRC the accessible name
> would be the text, but the author can override it with aria-label or so.

there in lies the issue, the acc name for the above example would be:

" major pain also show minor pain (max number of minor pains)"
 
nonsensical

> 
> > they don't, but that does not mean we should replicate OS X poor ui.
> 
> > sure, asking to increase the size so it is a usable for people with fine
> > motor skill impairments is an ask that will often not be met.
> 
> I think it's a bad idea to work around accessibility failures in OS X (and
> others) when designing new HTML features. It would be better for OS X (and
> others) to fix their accessibility failures so that all disclosure triangles
> are usable by people with motor disabilities, not just Web apps that use
> <dialog>.

how are we working around OSX issues? why replicate a poor UI?

> 
> > having the
> > summary element represent the click area by default = built in 
> > usability/accessibility.
> 
> Unfortunately it makes it *not* usable when it includes interactive content.

right and that's why i have suggested restricting, as from an adhoc review the majority of uses don't require the addition of other controls, But as a compromise being able to define a label area for summary that acts like a label on a labelled control would cover both cases. providing both usability/accessibility benfifits and the flexibility of allowing additional controls

(In reply to steve faulkner from comment #8)
> there in lies the issue, the acc name for the above example would be:
> 
> " major pain also show minor pain (max number of minor pains)"
>  
> nonsensical

As I said, you can use aria-label to override it if it gets nonsensical. That's what aria-label is for.

However the example is hypothetical, I'm not convinced it's an issue in practice. Looking at the examples in comment 2 they would all be fine.

> how are we working around OSX issues? why replicate a poor UI?

My understanding from your earlier comment was that one motivation for the default action was to get usability for people with motor disabilities for <details> also on platforms that normally have poor usability for the disclosure triangles. That seems like a workaround to me.

I don't agree that it's poor UI. I can buy that the click area is small, but one possible solution to that is to make it bigger...

Usually HTML features that are also available natively in the platform follow platform conventions (e.g. focus behavior).

> right and that's why i have suggested restricting, as from an adhoc review
> the majority of uses don't require the addition of other controls,

Right. But being a minority use case doesn't mean it shouldn't be addressed.

> But as a
> compromise being able to define a label area for summary that acts like a
> label on a labelled control would cover both cases. providing both
> usability/accessibility benfifits and the flexibility of allowing additional
> controls

Can you elaborate on this? I don't understand what you're proposing here.

(In reply to Simon Pieters from comment #9)
> (In reply to steve faulkner from comment #8)

> > But as a
> > compromise being able to define a label area for summary that acts like a
> > label on a labelled control would cover both cases. providing both
> > usability/accessibility benfifits and the flexibility of allowing additional
> > controls
> 
> Can you elaborate on this? I don't understand what you're proposing here.

anonymous control is labelled via id of summary

<details>
  <input id="anonymous-control"><summary id="summary-anonymous-control"><label for="summary-anonymous-control">label text</label> </summary>
Some content 
</details>

or 

anonymous control is labelled via id of details

<details id="details-anonymous-control">
  <input id="anonymous-control"><summary><label for="details-anonymous-control">label text</label> </summary>
Some content 
</details>

(In reply to Simon Pieters from comment #9)
> (In reply to steve faulkner from comment #8)
> > there in lies the issue, the acc name for the above example would be:
> > 
> > " major pain also show minor pain (max number of minor pains)"
> >  
> > nonsensical
> 
> As I said, you can use aria-label to override it if it gets nonsensical.
> That's what aria-label is for.

I haven't encountered any anonymous controls (in shadow DOM) that can be labelled by an author, from the DOM. I thought that the inability to reference stuff in the shadow DOM from the DOM was a feature (i.e. encapsulation) it is for author shadow DOM - see http://blog.paciellogroup.com/2014/03/stuff-doesnt-work-dom-shadow-dom/

> 
> However the example is hypothetical, I'm not convinced it's an issue in
> practice. Looking at the examples in comment 2 they would all be fine.
> 
> > how are we working around OSX issues? why replicate a poor UI?
> 
> My understanding from your earlier comment was that one motivation for the
> default action was to get usability for people with motor disabilities for
> <details> also on platforms that normally have poor usability for the
> disclosure triangles. That seems like a workaround to me.
> 
> I don't agree that it's poor UI. I can buy that the click area is small, but
> one possible solution to that is to make it bigger...
> 
> Usually HTML features that are also available natively in the platform
> follow platform conventions (e.g. focus behavior).

platform conventions for disclosure type widgets vary (on windows as noted previously the whole 'summary' is clickable.


> 
> > right and that's why i have suggested restricting, as from an adhoc review
> > the majority of uses don't require the addition of other controls,
> 
> Right. But being a minority use case doesn't mean it shouldn't be addressed.

the minority use case can be addressed via scripting see http://codepen.io/stevef/pen/jiCBE as an example.

(In reply to steve faulkner from comment #11)
> I haven't encountered any anonymous controls (in shadow DOM) that can be
> labelled by an author, from the DOM. I thought that the inability to
> reference stuff in the shadow DOM from the DOM was a feature (i.e.
> encapsulation) it is for author shadow DOM - see
> http://blog.paciellogroup.com/2014/03/stuff-doesnt-work-dom-shadow-dom/

The author doesn't cross the boundary here. I'm suggesting

<details>
 <summary>Foo</summary>
</details>

<details>
 <summary aria-label="Foo">Bar</summary>
</details>

or

<details>
 <summary aria-labelledby=x><span id=x>Foo</span> Bar</summary>
</details>

and then the UA is responsible of getting the accessible name from the summary element for the anonymous widget.

> platform conventions for disclosure type widgets vary (on windows as noted
> previously the whole 'summary' is clickable.

Oh, I didn't realize that was a platform convention on Windows rather than just something that app was doing.

> the minority use case can be addressed via scripting see
> http://codepen.io/stevef/pen/jiCBE as an example.

I have less faith in all authors getting this right than UAs/OSes getting their accessibility act together. :-P

(In reply to steve faulkner from comment #10)
> anonymous control is labelled via id of summary
> 
> <details>
>   <input id="anonymous-control"><summary
> id="summary-anonymous-control"><label for="summary-anonymous-control">label
> text</label> </summary>
> Some content 
> </details>
> 
> or 
> 
> anonymous control is labelled via id of details
> 
> <details id="details-anonymous-control">
>   <input id="anonymous-control"><summary><label
> for="details-anonymous-control">label text</label> </summary>
> Some content 
> </details>

In this proposal, the summary element has no default action? (Also "<input id="anonymous-control">" is not something that would appear in the markup?)

(In reply to Simon Pieters from comment #13)
> (In reply to steve faulkner from comment #10)
> > anonymous control is labelled via id of summary
> > 
> > <details>
> >   <input id="anonymous-control"><summary
> > id="summary-anonymous-control"><label for="summary-anonymous-control">label
> > text</label> </summary>
> > Some content 
> > </details>
> > 
> > or 
> > 
> > anonymous control is labelled via id of details
> > 
> > <details id="details-anonymous-control">
> >   <input id="anonymous-control"><summary><label
> > for="details-anonymous-control">label text</label> </summary>
> > Some content 
> > </details>
> 
> In this proposal, the summary element has no default action? (Also "<input
> id="anonymous-control">" is not something that would appear in the markup?)

right, it's an attempt to find a way to work with what the spec currently says while providing a method to have a larger click area (via the label element) and provide a method to explicitly label the anon control using native HTML rather than ARIA (which also does not provide the click region). 

the anon control represents the anon control in shadow DOM (more likely to be <div id=anon control>...</div>

it makes the anon control a labelable element (http://www.w3.org/html/wg/drafts/html/master/forms.html#category-label) via reference to id of either summary or details

(In reply to Simon Pieters from comment #12)

> > the minority use case can be addressed via scripting see
> > http://codepen.io/stevef/pen/jiCBE as an example.
> 
> I have less faith in all authors getting this right than UAs/OSes getting
> their accessibility act together. :-P

I have a lot less faith in authors getting bolt on accessibility right than getting something like this right as if event bubbling is not cancelled it causes issues that devs can see and directly effects core behaviour they are trying to achieve.

(In reply to steve faulkner from comment #14)
> right, it's an attempt to find a way to work with what the spec currently
> says while providing a method to have a larger click area (via the label
> element) and provide a method to explicitly label the anon control using
> native HTML rather than ARIA (which also does not provide the click region). 

OK. I would expect most authors will not use it though (like I think most authors don't <label> their checkboxes).

What do you think the accessible name of the widget should be if there's no <label>?

(In reply to steve faulkner from comment #15)
> I have a lot less faith in authors getting bolt on accessibility right than
> getting something like this right as if event bubbling is not cancelled it
> causes issues that devs can see and directly effects core behaviour they are
> trying to achieve.

Yeah.

(In reply to Simon Pieters from comment #16)
> (In reply to steve faulkner from comment #14)
> > right, it's an attempt to find a way to work with what the spec currently
> > says while providing a method to have a larger click area (via the label
> > element) and provide a method to explicitly label the anon control using
> > native HTML rather than ARIA (which also does not provide the click region). 
> 
> OK. I would expect most authors will not use it though (like I think most
> authors don't <label> their checkboxes).

data suggests usage of label is common 

label	166035 instances, from 26602 pages, average per page 6, max number of instances per page 1640	

total number of pages: 79,300 from latest data set on http://webdevdata.org

> 
> What do you think the accessible name of the widget should be if there's no
> <label>?

from summary text content

> 
> (In reply to steve faulkner from comment #15)
> > I have a lot less faith in authors getting bolt on accessibility right than
> > getting something like this right as if event bubbling is not cancelled it
> > causes issues that devs can see and directly effects core behaviour they are
> > trying to achieve.
> 
> Yeah.

(In reply to steve faulkner from comment #17)
> data suggests usage of label is common 

That's good. But it doesn't tell the ratio between unlabelled controls and labelled controls (especially checkboxes and radio buttons is relevant since they are "small").

> from summary text content

OK. And ignore aria-label/aria-labelledby?

(In reply to Simon Pieters from comment #18)
> (In reply to steve faulkner from comment #17)
> > data suggests usage of label is common 
> 
> That's good. But it doesn't tell the ratio between unlabelled controls and
> labelled controls (especially checkboxes and radio buttons is relevant since
> they are "small").

quick grep of 10,000 pages isolating checkbox/radio

type="radio" = 3263
type="checkbox" = 4036

label = 5143

safe to say at least 50%


> 
> > from summary text content
> 
> OK. And ignore aria-label/aria-labelledby?

didn't mean that, use the accessible name calc algorithm use summary as origin

(In reply to steve faulkner from comment #19)
> (In reply to Simon Pieters from comment #18)
> > (In reply to steve faulkner from comment #17)
> > > data suggests usage of label is common 
> > 
> > That's good. But it doesn't tell the ratio between unlabelled controls and
> > labelled controls (especially checkboxes and radio buttons is relevant since
> > they are "small").
> 
> quick grep of 10,000 pages isolating checkbox/radio
> 
> type="radio" = 3263
> type="checkbox" = 4036
> 
> label = 5143
> 
> safe to say at least 50%
> 
> 
> > 
> > > from summary text content
> > 
> > OK. And ignore aria-label/aria-labelledby?
> 
> didn't mean that, use the accessible name calc algorithm use summary as
> origin

grep file https://dl.dropboxusercontent.com/u/377471/label-checkbox.html (warning big 4.5mb)

(In reply to steve faulkner from comment #19)
> safe to say at least 50%

Thanks, I stand corrected.

> didn't mean that, use the accessible name calc algorithm use summary as
> origin

OK. Sounds good.

I'd prefer the label pointing to the <summary> over <details> since it's closer to the widget and it requires you to have a <summary> which is probably good if you want to have a <label>.

(In reply to Simon Pieters from comment #21)
> (In reply to steve faulkner from comment #19)
> > safe to say at least 50%
> 
> Thanks, I stand corrected.
> 
> > didn't mean that, use the accessible name calc algorithm use summary as
> > origin
> 
> OK. Sounds good.
> 
> I'd prefer the label pointing to the <summary> over <details> since it's
> closer to the widget and it requires you to have a <summary> which is
> probably good if you want to have a <label>.

i don't have an issue with the specifics as long as a method to do it is provided.

HTML5.1 Bugzilla Bug Triage: Moved to https://github.com/w3c/html/issues/250

If this resolution is not satisfactory, please copy the relevant bug details/proposal into a new issue at the W3C HTML5 Issue tracker: https://github.com/w3c/html/issues/new where it will be re-triaged. Thanks!