summary should serve as label for details

[JAWS-test]

HTML spec:

The summary element represents a summary, caption, or legend for the rest of the contents of the summary element's parent details element

HTML AAM does not indicate that summary is used to label the group defined by detail. As a result, I have to explicitly label the detail element with aria-labelledby or aria-label so that my group has a label. This is contrary to the HTML specification. I suggest adding to details that the summary serves as a group label (analogous to fieldset and legend).

[scottaohara]

i'm not so sure on this one. there are times where it might be needed to provide a grouping boundary/name for a details element - but that's not always the case. Consistently giving a details a name per its summary element would introduce redundancy of the name of the summary (which someone has to interact with to expand/collapse the details content) and the details element, now with the same name, both being announced. So like... foo button, foo group (for the few instances where it'd actually be that concise... testing with firefox and VO (just cause i'm on a mac while i write this) i get "foo, collapsed, summary, group foo, details" when initially navigating to the element. and that's a bit much.

Comparing summary directly to caption or legend is one of the reasons why details/summary has some of the problems it does. For example, HTML allowing summary to contain interactive elements, and the stance that summary is considered more like a "label", so therefore it can have nested inputs, buttons and hyperlinks - but where HTML does not allow hyperlinks or buttons to contain other interactive elements.

Per this specific issue, caption/legends are not themselves interactive elements - so it is less likely for someone to keyboard navigate to them and thus hear their name be redundantly announced as both the name of the current focused element, as well as the name of their containing element.

tldr; I understand the use cases where one might want to name their details (or do something like the following markup to cut down on redundancy when navigating to the summary element). But I question how good of an idea it would be to always name a details element. especially since it's not consistently easy (or even a good practice) to then inform people how to negate a name for their unwanted named group

<details>
  <summary id=f>...</summary>
  <div aria-labelledby=f role=group>...</div>
</details>

[JAWS-test]

@scottaohara Thank you very much for your detailed answer. I understand your objections and am happy to close the ticket if no one else wants to comment.

Just to briefly explain why I opened the ticket:

• I started from the HTML specification and I read it to mean that the summary element serves as a label and therefore has to be submitted accordingly in the Accessibility API, regardless of whether that makes sense or not. Perhaps the HTML specification would have to be adapted here so that the summary element is not the label, but simply a button that shows and hide an area.
• In my day-to-day testing, I often see form areas that can be shown or hidden using buttons. There are some possibilities with fieldset and legend or role=group, but they never manage without ARIA with regard to the button for showing and hiding. However, the 1st ARIA rule is that native HTML elements are to be preferred and that is why I came up with details and summary, because the element does exactly that without ARIA. But if I use details and summary for form field groups, then the group should also have a label that results from the summary. I would also have the redundant output in the screen reader if I placed a button in the legend to show or hide the fieldset (see example 2 at https://html.spec.whatwg.org/multipage/form-elements.html#the-fieldset-element). Here, the screen readers could also simply adapt their output so that they do not output the label of the group and button twice if they are identical. JAWS and NVDA can already avoid such redundant output if the label and description (e.g. in the title attribute) are identical: the description is then not output.