Disallow interactive content in <summary>

[zcorpan]

https://html.spec.whatwg.org/#the-summary-element:concept-element-content-model

Content model:​
Either:​ phrasing content.
Or:​ one element of heading content.

From #2246 -- the content model for summary should disallow interactive content descendants.

[zcorpan]

Hmm I just realized that wpt-stability-checker in web-platform-tests uses links in summary. Maybe it should be allowed? 😐

@sideshowbarker

[sideshowbarker]

Hmm I just realized that wpt-stability-checker in web-platform-tests uses links in summary. Maybe it should be allowed?

Maybe so, given we know at least one real-world use case for it (which just spontaneously emerged from how we ended up building out the format of the stability-checker comments—as opposed to being some synthetic demo constructed to advocate for the need).

[domenic]

Maybe one path would be to add guidance in the rendering section asking UAs to make it possible to toggle the details even if the summary contains entirely interactive content? That seems to be what everyone does so far.

[zcorpan]

Well... with summary having activation behavior, this results in quite confusing UI when interactive elements are nested, like for other interactive elements, which is why nesting them is generally disallowed.

See http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4821

In Chrome/Opera/Firefox/Safari, for several of the things (but not the link), clicking also toggles the details's open state. Focusing and pressing space or enter as well (but not for the link).

I don't know right now what correct behavior should be per spec for these cases. Should compare with elements with activation behavior in label as well...

[domenic]

That's really strange. I wonder why <a> is special. It'd be good to understand that better.

Maybe links should be allowed, but other interactive content should not?

[patrickdark]

@domenic a should definitely be allowed within summary for <a rel="bookmark"/>. If you can absolutely position one piece of interactive content over another, I see no reason why you shouldn't be able to nest such content instead to get the benefits of inline text flow alignment.

(IMO, a elements should also allow interactive content such as and button and select elements—for a language switcher that flows inline with a linkified heading—which implies that summary should allow them as well since it's just a special type of heading, but that seems to be out of the scope of this issue.)

[JAWS-test]

Not only interactive content, but any content within summary that has an implicit role should be prohibited. The element is treated like a button by the accessibility interfaces. However, a button has implicit role=presentation, i.e. with assistive technology any content of a button is output as plain text, any roles (such as links, headlines, etc.) are not perceptible. This also applies analogously to buttons (<button>), in which no interactive elements are currently allowed, but elements with an implicit role.

[scottaohara]

Been meaning to respond to this issue for.... years now it appears.

I've filed bugs against Chromium and Webkit because nested text fields within a summary will cause the details to open/close if the space key is pressed within the text field.

https://bugs.chromium.org/p/chromium/issues/detail?id=1361983

https://bugs.webkit.org/show_bug.cgi?id=244984

That said though, this doesn't address the fact that role mappings for the summary element have resulted in unexpected or problematic behavior across browsers when using AT for years now. For instance, because MSAA/IA2 expose a summary element as a button - which is not supposed to have nested interactive elements, JAWS does not expose the nested interactive elements of the summary, or the semantics of non-interactive elements (headings) within due to the button mapping.

For instance, JAWS handles the following very poorly:

<details>
  <summary>example <a href=...>text</a></summary>
   ...
</details>

The link is not discoverable at all to JAWS when navigating with its virtual cursor. If navigating to the summary element via the Tab key, JAWS announces "example text, button" as the name and role of the element. If hitting Tab key again, JAWS again announces "example text, button" even though keyboard focus is on the link.

NVDA, however, paired with Firefox/Chromium browsers will continue to expose the mappings of elements within buttons, because these browsers have moved away from treating the children of button elements as presentational (dropping their semantics/mappings) to mitigate against authors incorrectly putting nested interactive elements within button elements - or in this case, doing what the spec says is allowed although the mapping for summary has made this problematic over the years. But even though the nested elements of the summary remain exposed, navigating to them with NVDA's scan mode is still not consistently possible. Tab key is essentially required to make sure one is accessing the appropriate interactive element.

If I were to give a summary element an accessible name via aria-label, reaching any nested elements of the summary element becomes even more difficult as the aria-label is a signal to AT that the child content is not important. That'd just an extra wrinkle that makes the current content allowance a bit more difficult to deal with.

There is more I could go on about with the various problems different AT have with the content model for summary... but that would just extend this comment out beyond what is necessary. tldr; the summary content model produces very inconsistent and sometimes just flat out broken experiences for people using AT.

Potential solutions:

1. Since the summary element effectively acts as an expand/collapse button, it would make sense to follow the button content model, which doesn't allow nested interactive elements. This would resolve the issue in a sense that while the browsers would still "allow" the content within the summary element, HTML would not condone it and it could then allow checkers to produce author errors explaining why this is problematic.

2. if the content model remains as is, then it does beg the question of why buttons could not also have their content model match summary elements? I'm not actually advocating for that, but it is a current contradiction to how the summary element was mapped vs what buttons otherwise allow within them. Nesting interactive elements inside a button has the same problems I mentioned above for summary element. <button>hi <input></button> actually has the same behavior as the above Chrome/webkit issues - but this is an author error because of the difference in content models. There would be a lot of work with both browsers, AT and even developer education if buttons were to allow nested interactive or other semantic elements like headings. It's clearly possible to expose the information, but right now it's being done to mitigate author errors, and thus not all UAs are on the same page in supporting it.

3. Alternatively, if the content model remains for summary, then the mapping or implementation of the element should effectively change. I highly doubt that changing the implementation for the element is on the table, so I won't even go into that any further. Changing the mapping would likely require the creation of a new role that effectively communicates that the element serves as both a container element, but also that it is also itself interactive in some way. Getting buy in for this role, and getting implementations would take a lot longer than getting all browsers to align on implementing the button role for the summary element. But it may be the right thing to do to allow summary's current content model, and to create a role for other interactive elements that often have nested interactives or other elements with semantics important to accessibility. E.g., "cards" that often are mouse clickable for some primary action, but may have other buttons or links and a heading within.

Very curious to people's thoughts on this, and if there are any further clarifications I might be able to help with to move a resolution to this issue along, whatever the resolution may be.

[JAWS-test]

I am for solution 1. Later we can change to 3 (after resolving w3c/aria#1440)

[zcorpan]

For option 3 we would also need to make interaction of the inner interactive element only affect that element and not also the ancestor interactive element, somehow. But it seems like it would be useful to solve, since web pages will inevitably continue to nest interactive elements even if HTML says it's not allowed.

I'm OK with option 1 until option 3 is ready.

I mentioned <label> in my previous comment above; see #5415

[scottaohara]

i'm not sure what you're referring to as being outlawed? something to do with that webkit pr? the instance of the details element in the linked comment? if the latter, there's nothing there conflicting with the proposal? if the former, I apologize that I'm not following.

[annevk]

Thanks! It was about the linked comment. I got confused between details and summary. Nevertheless, in chat @sideshowbarker mentioned he also had some concerns and hopefully he'll elaborate on those later.

[sideshowbarker]

I will not willingly implement this in the HTML checker, because I assess that on balance this restriction will end up wasting more time of HTML developer-authors than it helps others — or end up just being widely ignored.

Fundamentally, use cases for summary are very different from use cases for button, and there is much existing content that is making logical normal natural reasonable use of what the change in this PR would make non-conforming.

What I see in practice out in the wild is that summary often acts essentially as a title/heading — and unsurprisingly and logically and naturally so —  as far as its informational purposes go, rather than just being there for its UI function.

I understand and recognize the very-real accessibility problems with allowing it, and I am in no way dismissing those as being ignorable. They are extremely important.

And I know that what I will say now is as a standard cop-out we have been accused of using for many years in discussions — but it really seems like what needs to happen here is for the AT to be refined to provide the right UX for this. It seems like given the reality of widespread usage of this in practice, AT regardless already really needs to be find some way to handle this.

We know usage of what this would make non-conforming has been in the wild already for years and is being used very commonly. And I can say from experience that this looks to me like the kind of case where very many (or most) developers would be very unlikely to choose to change their existing stuff just because the spec says it’s non-confoming and the HTML checker has started barking at them about it.

[scottaohara]

appreciate much of your response @sideshowbarker . i disagree with implying this is something AT should work out - i have tried (and failed) to write a response to that which hasn't turned into a blog post in its length multiple times. I don't want to a reply that long.

But the gist is that the AT is doing what it's being told - in that AT is treating summary as a button because that's what browsers are inconsistently telling it be. So, as you mentioned, it is a bit of a cop-out to say AT should handle this. It's a long-standing implementation issue.

So, seems that if the content model doesn't end up changing, then it would come down to revising the a11y mappings - which is truly needed anyway since there is no unified implementation for this element now. And in the meantime, it'll continue to be the responsibility of a11y practitioners and those that just 'know' to warn - in this specific instance - that while it may be valid HTML, it will result in accessibility gaps.

[annevk]

Domenic pointed out https://participate.whatwg.org/agreement#signature on chat, as a real-world example.

How does AT deal with the label element? I always thought of summary as much more like label than like a button, personally.

[scottaohara]

i can appreciate that comparison. I mean, the summary element is defined as a 'summary, caption, legend' for its details parent. Elements like label/caption/legend all provide a name for the element (labellable element, table, fieldset) that they are associated with.

There are some key differences here though, per your question to how AT handle label:

• only caption has a meaningful role that can be exposed to AT. label and legend are just exposed as their contents / are exposed when interacting with their associated form controls (it's a bit different for legend, but we'll leave it at that for now)
• none of them are inherently keyboard accessible, nor expected to be directly interacted with via keyboard/AT
• and as such, none of them are presently setup to / expected to, from a user's POV, expose expanded/collapsed state.

Another difference between the current implementations for summary vs the above mentioned elements is that summary was never implemented to provide a labeling association to the details element / content that was exposed. The details element itself is - without specific intervention from an author - completely ignored/irrelevant to AT. Rather, the summary element effectively labels (and thus names) nothing but itself - there are both pros and cons to this which are a bit tangential to this thread - but it is another key difference for how this is being perceived/spec'd vs how it was actually implemented oh so long ago.

So yes, while I can appreciate the thought that a summary is a label for its associated content, it leaves out the part that it's also expected to behave and act like a button that communicates it shows/hide that content, as well.

Per the example: https://participate.whatwg.org/agreement#signature, which is quite a good one to poke at. I can tell you that different screen reader/browser pairings either don't allow the screen reader's virtual cursor to reach those nested links, or they don't make it apparent there is even a link within the summary at all (but it can be force-found using the tab key), OR the link is left out of name announcement of the summary (e.g., "if signing as an" - with no mention of 'individual')... and that's just some of the quirks. it's all rather inconsistent once nested interactive elements get involved.

Now (some thoughts I've briefly shared with others in various conversations where I've been trying to figure out what could be done with these elements), If summary had been implemented where its shadow DOM was essentially:

<summary>
  <button id=b aria-expanded=...>
    <!-- disclosure triangle here -->
  </button>
  <label-like-element for=b>
    <!-- authors put whatever they want here (but still, let's be reasonable) -->
  </label-like-element>
</summary>

The mention of label-like-element is more to the point that if labeling the hypothetical shadow dom button of this summary example, then it couldn't be exactly like a label element because if someone were to nest another form control in that, then we'd have a labeling conflict. A div with an onclick to activate the button, and an aria-labelledby association between the button and this div would be a 'more appropriate' example, i suppose.

Regardless, if it had been implemented in a way similar to this, and the button's marker could be styled (but the button itself not removed so as to consistently remain keyboard accessible / available to AT), then AT could have treated summary similar to:

<input type=checkbox id=f> <label for=f>whatever you want here</label>

And, that's generally treated just fine by AT.

I am concerned that might be a larger lift than what browsers want to actually take on - and i'm sure there'd be other bumps along the road that AT would need to smooth out, that I've glossed over here.

The point being more so that yes, summary could be/have been treated like a label/heading/title/caption... But it was also given the behaviors of a button to show/hide content. There was nothing then, and still nothing standardized now that really accounts for that double duty without actually implementing the separate elements that each can do these respective jobs.

But that's again the other path that could be taken here in fixing this up. If the underlying implementation cannot be restructured as I mentioned above ( and again, I will absolutely call out that I'm likely making that seem a far 'easier' solution than it would be in reality), then the alternative would be to create a new role or make revisions/expansions of capabilities to an existing role which would allow for the current content model, and allow AT to be aware that the summary element could contain a simple string of text, or that there are other important structural elements / interactive elements within it. Firefox and Safari, and Chromium on macOS are all handling this element a bit differently, each with their own pros/cons in individually solving for this issue, while also introducing their own quirks. iOS Safari unfortunately is representative of what this'd be like if summary were treated as if it simply were a label... in that it exposes no role or state information at all, so there's no way for someone using VO to even know they can expand/collapse the information. That's been an issue since at least iOS 11.4 :(

So yeah, that was a lot... i really do hope it was helpful... again, if HTML doesn't end up changing the allowed content model for summary - as i do understand why that'd be an issue for existing author implementations, then there are other pathways forward. It would have never really "solved" the problem anyway... but would have allowed for a way to let authors know there are problems with doing this.

I'm reopening w3c/aria#939, which also links to an HTML AAM issue about this element. Seems there might be a lot of work/discussions to restart with those issues.

[domenic]

I was talking with @muan about this and one thing we noticed is that mouse/keyboard users are able to activate interactive content inside <button>s with no problem (despite it being invalid HTML): http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=11725 .

Is it correct that AT users have no way of activating such content? And so the problem is that by treating <summary> like a <button>, interactive content in summary is similarly inaccessible to AT users?

If so, one other angle from which this could be tackled is by allowing AT users to interact with such interactive content inside <button>s and <summary>s. That would fix the problem for summaries, and also probably make various other non-valid-HTML parts of the web accessible when they're (ab)using buttons in this way.

[zcorpan]

I queried httparchive (total pages 12,808,711). Findings:

• 1.77% of pages use summary (226,719 pages)
• of those, 46% use summary with interactive content (or 105,235 pages or 0.82% of total pages)

Limitations: <a> (sans href) is included, <img>, <audio>, <video> are excluded. These were intentional since getting them right is hard and I expected marginal returns. tabindex on summary is included. tabindex="-1" is included (despite my attempt to exclude it). These were mistakes.

Export of the first 1327 results (ordered by rank): https://docs.google.com/spreadsheets/d/1o2X2ld_S0JjYdZs2vPKNwfrAIdceiVH2HLSmo4BLYTI/edit?usp=sharing

query

SELECT
  *
FROM (
  SELECT
    rb.page,
    sp.rank,
    ARRAY(
      SELECT
        match
      FROM
        UNNEST( REGEXP_EXTRACT_ALL(body, r'(?i)(<(?:summary)(?:\s+[^>]+)?>(?:[^<]+|<[^/]|</[^s]|</s[^u])+</summary\s*>)') ) AS match
      WHERE
        REGEXP_CONTAINS(match, r'(?i)(<(input|a|button|details|embed|iframe|label|select|textarea)(\s|>)|\s+tabindex\s*=\s*["\']?[^-])')
    ) AS filtered_match
  FROM
    `httparchive.response_bodies.2023_05_01_desktop` AS rb # TABLESAMPLE SYSTEM (0.1 PERCENT)
  JOIN
    `httparchive.summary_pages.2023_05_01_desktop` AS sp
  ON
    rb.page = sp.url
  WHERE
    rb.page = rb.url
    # AND sp.rank <= 10000
    )
WHERE
  ARRAY_LENGTH(filtered_match) > 0
ORDER BY
  rank

[zcorpan]

Also usage of summary seems to have grown from 0.9% last year.

I agree with @domenic that making nested interactive content accessible in AT seems ideal. I don't expect we'll be able to make web developers not use interactive content in summary seeing that almost half of the pages using summary do so today.

[sideshowbarker]

of those, 46% use summary with interactive content (or 105,235 pages or 0.82% of total pages)

So that data compels me to even more emphatically assert that in the HTML checker, I will not willingly implement any error reporting for summary with interactive content — because reporting an error (or even just a warning) to developers in 46% of all cases where they are using summary at all is not going to be productive for developers in practice.

At that 46% rate, for any error message I were to start reporting, I expect that developers will just filter out that message (using one of Message Filtering mechanisms the checker provides to them), or else the developers will just completely ignore the messages (and likely, file bugs against the checker issue tracker asking me to make the checker just shut up about it) — or because of the annoyance of it, those developers will just completely quit using the checker (which is something I really really do not want to make them end up deciding to do).

[dbaron]

Given the discussion above, I've closed #9372, but I'm glad it triggered this discussion. It sounds like the path forward for improving accessibility here is somewhat complex and may involve changes to HTML-AAM (see w3c/html-aam#345), maybe ARIA (?, see w3c/aria#939), browsers, and ATs. I think @scottaohara (and hopefully others) understand how those pieces fit together a lot better than I do...

[scottaohara]

regarding:

we noticed is that mouse/keyboard users are able to activate interactive content inside s with no problem

when the parent button doesn't do anything there's no problem, sure. but make it do something - https://codepen.io/scottohara/pen/PoxYOQQ - and that's not quite the case without further scripting by the author. This is notably different than how a link within a summary works today (so that's good at least).

To the question:

Is it correct that AT users have no way of activating such content?

It is variable. It depends on the AT in use and the browser implementation for the feature, I've already called out some of this in previous comments. But quickly: screen readers like VoiceOver on macOS and iOS, as well as JAWS on Windows cannot access the nested link within the button when using non-tab key navigation. If tabbing to the nested link, neither will announce the user has reached a link - rather the name of the button is repeated. Note that for summary, since macOS/iOS do not map summary to a button, there's no 'problem' reaching the link there. But they have their own usability / a11y issues - more on that in a bit...

Other AT, like NVDA, also doesn't allow the virtual cursor to navigate within the button, but it does announce that there is a link within. e.g., the example "text link text" is announced as "text link, link text" - so there's a signal there that one can navigate in - and then get the double firing of events. (I'm thinking this is likely what HTML could help improve - ensuring that regardless of it being invalid, if a link within a button is activated, then don't allow the event to bubble up and activate the button as well).

Interestingly, if a summary element contains only a link, then NVDA cannot open the details. But if the link is accompanied by static text, then this allows the summary to toggle the details, and another tab press to navigate into the summary to activate the link.

And that's a good place to turn back to the usability issues of this, because we've only been talking about AT in the context of screen readers up till now. But there are other AT, and other disabilities which also are impacted by nested interactive elements. For instance, using Voice Control and asking for a number overlay to interact with a button with a nested link, a number will appear for the outer button element, but not the inner link. For a summary element, a number to activate will appear for the inner link, but not the summary (likely because with Webkit, summary is not mapped to a button, so it doesn't get included as an interactive item to show numbers for - this being a valid instance of where AT should update to fill this gap). But in both of these cases, one can't rely on the show numbers or saying "click [name of control]" to get the desired result, one would have to use other commands - like using the mouse grid feature to click on a part of the button or summary that wasn't the nested link. In the case of summary, since <summary><a href=...>all my text here</a></summary> is entirely valid, it can make clicking the control more awkward than it should be - which to be fair, will be a usability issue for really everyone, but it'll impact those with motor disabilities more so.

So all that to say that yes, there is some work that could be done to make nested interactive elements (at very least links) more consistently exposed by AT. But again, there are likely changes that need to happen in the way buttons/summaries are mapped to allow this, and then possibly further updates that AT would need to change - specifically VO and JAWS as far as screen readers are concerned, per my examples above. But in doing that, that's not going to necessarily make these things truly "accessible", they'll still likely be awkward and create usability issues depending on their implementation by authors. There is an effort in the ARIA WG to push forward a concept of secondary actions - that being a way for authors to purposefully specify that an interactive element has additional actions (which would often be visually conveyed as nested interactive).

Maybe a way to close this out could be:

• HTML/browsers investigate if it'd be possible to change how links within buttons behave, so that dual activation no longer occurs.
• would it be outside the realm of reason to request that the content model for summary at least be updated to state that a summary cannot contain only interactive descendants? That would be helpful to mitigate some of the usability issues at least.
• Per the issue and sub-issues I linked in my previous comment (and @dbaron just relinked in the comment above), work through a way to standardize the mapping for summary to revise how this is exposed to AT. The usability of nested interactive elements may not be fully addressed, but the content could at least be consistently handled if the element mappings were to be truly standardized.

[AutoSponge]

I'm more comfortable with "focusable" content restrictions in <summary> than I am with a (dis)allow list of elements. With aria-hidden="true" and tabindex="-1" or inert, we can turn most elements into appropriate children of <summary>. As long as "all functionality [is] available from a keyboard" having an additional mechanism for sighted mouse-users doesn't need to be forbidden in the spec.

[tabatkins]

One bit of the issue, I think, is that a reasonable pattern one might want is a details where the arrow toggles it open/closed but the rest of the summary is normal interactive content. I presume that's essentially the mechanics authors are aiming for when they put links or inputs in summary; it's just not actually possible in the current design.

"just add a switch" is often a lazy idea, but maybe that's the solution here - some way to tell the details to only make the indicator trigger the toggle behavior, and have the content model (and the accessibility tree) reflect on that. Then we can keep the "buttons can't contain interactive content" rule and don't have to do a lot of complicated changes.

[dbaron]

I attempted a data gathering run from a different data source (compare to @zcorpan's collection of HTTP Archive data in #2272 (comment)). My goal was to try to characterize the interactive content that's inside of summary a little better so that we can try to figure out what to do about it.

I used cluster telemetry with trace collection and ran a Chromium patch to gather data using Chromium's implementation of the spec's "interactive content" definition, and also checking for the presence of a tabindex atttribute (I didn't exclude tabindex="-1" since the content model requirements for <button> do not do so). This is probably a higher quality measurement, but against a lower quality page dataset (focused on homepages).

I'm sharing a spreadsheet of the results. A brief summary is that, of the 100,000 pages (site homepages):

• 776 had a <summary> element
• 73 of them had interactive content inside the <summary>. Of those:
  • 40 had an element with the tabindex attribute
  • 30 had an <a> element
  • 4 had a <button> element
  • 3 had an <input> element
  • 2 had a <label> element
  • 1 had a <select> element
• note that there were only a 3 cases of a page falling into more than one of the above buckets:
  • 1 page had both <a> and the tabindex attribute
  • 1 page had both <input> and <label>
  • 1 page had all 6 types of error! (I suspect perhaps a missing </summary>, but I didn't check)

[zcorpan]

Thanks @dbaron! My httparchive query is also for only homepages, FWIW. It's interesting you found about 9% of summary-using-pages use interactive content in summary and in httparchive it was 46%. Also in your results 0.7% use summary, httparchive 1.7%.

In either case, it seems it's still high enough to try to improve the experience for AT users for such pages (#2272 (comment)).

[zcorpan]

Looking at some examples from #2272 (comment) :

• https://nyheder.tv2.dk/ in the site menu, the sections are expandable details, and the summary has a link (that will navigate to another page). It has a custom dropdown button which is implemented using CSS generated content on the link, but it has pointer-events: none (so as to not activate the link) and so relies on the click event reaching the summary element to expand the details. The browser's disclosure triangle is hidden with CSS summary { display: block }
• https://www.jollyroom.se/ in the cookie dialog, click "Cookie inställningar". The summary elements have a transparent checkbox, on top of a custom switch control. The checkbox receives the click event and changes the appearance of the switch. Clicking anywhere else in the summary expands the details. The browser's disclosure triangle is hidden with CSS summary { display: flex }
• https://mamaworks.jp/ in the table (search for 営業・マーケティング), the summary has a checkbox, a label, and a link in the label. The link navigates to another page, the checkbox can be checked/unchecked, and the rest of the summary area is to expand the details. There's a custom dropdown button on the right, and the browser's disclosure triangle is hidden with CSS summary { display: block }.

I created a demo: https://software.hixie.ch/utilities/js/live-dom-viewer/saved/12116

• In Chrome and Firefox, clicking the checkbox or label only changes the state of the checkbox. Clicking the link only follows the link. Clicking "Normal text" expands the details.
• In Safari, the only difference is that clicking the label text both changes the state of the checkbox and expands the details.

Since most pages seem to get rid of the browser's disclosure triangle, making only the disclosure triangle expand the details by default would effectively break most pages using details. Making it an opt-in could work, but not be so useful I think since the sites seem to expect the summary element to expand the details, just that nested interactive content can be interacted with separately, without also causing the details to expand (which already works in browsers in most cases).

[dev-nicolaos]

"just add a switch" is often a lazy idea, but maybe that's the solution here - some way to tell the details to only make the indicator trigger the toggle behavior, and have the content model (and the accessibility tree) reflect on that. Then we can keep the "buttons can't contain interactive content" rule and don't have to do a lot of complicated changes.

I worry making the disclosure triangle (::marker) the only thing to trigger the toggle behavior is going to be a pretty big hit to usability.

The size of the pointer target would decrease drastically. While this may only be mildly annoying for some, it would probably have a significant effect on the ability to navigate the site for those with a disability that effects their fine motor skills. At present, the clickable area (non-margin) of the default UA marker is well below the WCAG AA minimum target size of 24px by 24px (Firefox is about 14px square, while chromium appears to be around 11px square). Browsers would have to drastically increase the default marker size to be accessible, which has the potential to break the design of some pages.

<summary> have been clickable by default for a while now, and I suspect many users have built up an expectation that will be the case. Breaking that learned behavior would probably cause surprised frustration for many users. It would probably also create a lot of work for devs/teams that want to restore the original functionality, but have to resort to wiring up JS event handlers to do so.

[joshuaboele]

Hi, sorry to necro the thread. I think I've read the thread diligently. But if I understand it correctly: summary/details often gets misused for an accordion element?

The reason I'm asking is that for example when details + summary gets used as a "native" HTML5 non-aria solution, the summary part of the component usually functions as a heading aswell. It visually indicates a relationship between the heading (summary text) and the details (content). However the issue is that when a user browses based on headings, that a lot of these components will be skipped.

What's a good solution? I can think of three solutions myself:

1. Nesting a h2 element within the summary element? This feels wrong, mainly because a couple of years ago it was a bad pattern to use a heading element within a button element. I still think this is not an ideal pattern, but AT and browsers know how to circumvent the accessibility-related issues as far as I'm aware.
2. Using a descriptive heading above the accordion elements? This one also doesn't feel quite right because the summary in itself is the heading of the underlying content
3. Not use summary/details for an accordion pattern.

Bit of a ramble and I'm not as experienced as you guys, but I would love to hear your take :)

Thanks!

[JAWS-test]

I think summary and details are good for accordion. Especially since the name attribute combines the individual details into one element: https://html.spec.whatwg.org/multipage/interactive-elements.html#attr-details-name

In the past, there was the problem that summary was transmitted as a button in the Accessibility API and buttons had an implicit role=none, i.e. all nested elements (which are permitted according to the HTML specification) lost their role and could therefore not be used in an accessible way. This meant that headings could no longer be perceived as headings, e.g. with a screen reader. In the meantime, however, mapping has changed: https://w3c.github.io/html-aam/#el-summary

It now works better, but probably not yet perfectly with all browsers and screen readers. A workaround would be not to have the heading in the summary, but behind the summary element, so that the heading is only displayed when details is open. This also seems to make more sense to me, because otherwise the page has many headings with no content.

Example:

<h1>heading for the accordion</h1>
<details>
 <summary>button</summary>
 <h2>heading for the content in the details element</h2>
 <p>content</p>
</details>

[aardrian]

@JAWS-test

I think summary and details are good for accordion. Especially since the name attribute combines the individual details into one element: https://html.spec.whatwg.org/multipage/interactive-elements.html#attr-details-name

That's not accurate. The name does not combine <details> (with a matching name value) into one element. For now, all it does is enforce a rule that only one in a set of <details> with a matching name value can be open at a time.

The name does not even provide an overall grouping context nor accName for the associated <details> elements (dbaron already knows my thoughts on this, so not tagging).

@joshuaboele As Scott noted above (and more succinctly over here), headings are allowed but UA implementations vary. Since this isn't a support forum you may want to ask for peoples' experience addressing this in a dedicated forum (social media with #a11y hashtag, A11y Slack, mailing lists, etc.).

[scottaohara]

@dev-nicolaos re:

I worry making the disclosure triangle (::marker) the only thing to trigger the toggle behavior is going to be a pretty big hit to usability.

that's a solid concern - but there's also the solution of making the disclosure marker the button part in the shadow dom, and the rest of the summary still behave as a clickable label. this sort of 'treat the summary as a label' idea was already alluded / mentioned by simon and myself in prior comments, though.

[dev-nicolaos]

@dev-nicolaos re:

I worry making the disclosure triangle (::marker) the only thing to trigger the toggle behavior is going to be a pretty big hit to usability.

that's a solid concern - but there's also the solution of making the disclosure marker the button part in the shadow dom, and the rest of the summary still behave as a clickable label. this sort of 'treat the summary as a label' idea was already alluded / mentioned by simon and myself in prior comments, though.

My concern was that giving authors a "way to tell the details to only make the indicator trigger the toggle behavior" would open up another accessibility/usability foot gun, one that could affect uses of <summary> without any interactive content. And given the observations that authors sometimes hide the indicator, its not clear it would solve the issues with interactive content in/as a <summary>.

If I'm understanding the "label-like behavior" proposal correctly, it sounds like that approach would center on changing the shadow dom browsers would use for <summary>, and thus how that element would get exposed to AT. But there wouldn't be any change to how author's use it or how pointers interact with it. If that's the case, then I don't think my concern applies to that proposal.

[scottaohara]

without getting too much into it, if this were even something people would consider, i'd submit there should be no change to the pointer behavior. and i'd also submit that if someone were to hide the default indicator, that does not necessarily mean that the button itself would need to become hidden/inaccessible. but yeh, otherwise i'd say your concern was absolutely valid.