The state of <details> in 2024

Many respected accessibility experts (like Scott O’Hara and Adrian Roselli) have correctly urged caution when considering <details> in years past, because of its inconsistent implementations in various browsers and assistive technologies.

But are these concerns still valid in mid-2024? I’ve read the latest specification, perused the browser engine Bugzillas, and done a ton of browser and screen reader testing to get the current state of HTML’s most interactive element. The results are below.

This page is adapted from a presentation I recorded for HighEdWeb’s 2024 Accessibility Summit.

Browser and accessibility considerations

<summary> works without issue via mouse, keyboard, and touch in all browsers.
<summary> announces role and expanded state in all major browser/reader pairings upon focus. (This was bugged in iOS Safari/VoiceOver until the release of iOS 16.7 last fall.)
<summary> announces state changes on toggle except in Mac Safari/VoiceOver. (This was also bugged in iOS Safari/VoiceOver until iOS 16.7.)
Adding aria-expanded to <summary> has no effect (in case you were thinking it might fix the Mac Safari issue, as I have also thought and tested!) and should be avoided.
<summary> is not strictly a button. Its announced role varies based on browser/reader (can be “summary,” “button,” “pushbutton,” or “disclosure triangle”).
Nor should you apply role="button" to a <summary> to make it a button. In fact, doing so may break it with Safari/VoiceOver.
According to the spec, <summary> can include headings in addition to phrasing content. And when navigating via headings in all major screen reader pairings, this works fine. However, when reading the page or focusing on the element, the text may or may not be announced as a heading. (Also, the heading will need a display: inline style to appear properly–and be announced properly in Chrome/JAWS.)
An expanded <details> can appear on top of other content. (In these cases, you can use aria-haspopup on its <summary>.)
Adding a common name attribute to each of a set of <details> elements will auto-close all others in the set when one is opened. This is bugged in Firefox.
Chromium browsers will auto-expand <details> when doing find-in-page searches. Webkit and Gecko have issues created to add this. But no ETA. (Webkit seems closer.)
<details> elements can be nested without issue.
Unlike most custom expand/collapse elements, <details> elements do not collapse when the user has focus on the <summary> and presses the esc key.

When should you use it?

As-is, <details> may not be the perfect choice for all use cases, but I feel a solid argument can at least be made for the following:

To store long descriptions of complex images/diagrams.
To store audio transcripts.
To collect groups of related form elements (like a sidebar of checkbox filter groups at an online store).

The current HTML specification may also include recommendations regarding <details> usage (both for and against).

Implementation tips

The non-<summary> content within a <details> doesn’t need to be in a single container for grouping. But for the sake of styling this section separately from the summary, I do recommend putting it in a <section> (which can then be targeted via details[open] > section in CSS).

<details>
  <summary>The summary</summary>
  <section>
    <p>Some content.</p>
    <p>More content</p>
  </section>
</details>

I also like adding a cursor: default property to my <summary> elements, so the mouse pointer will be an arrow on hover. This is in line with button behavior. By default, the mouse pointer is a text selection icon when hovering over a <summary>. This just feels off to me, even if the text is selectable.

<details> demos

You can test out different implementations of <details> with various browsers and assistive tech via these CodePen links.

Browsers (and paired screen readers) used in testing

I used the latest versions of all these technologies, as of July 2024.

Mac Safari (with VoiceOver)
Mac Chrome
Mac Firefox
Windows Edge (with Narrator)
Windows Chrome (with JAWS)
Windows Firefox (with NVDA)
Linux Firefox (with Orca)
iOS Safari (with VoiceOver)
Android Chrome (with Talkback)