Hot HTML Summer: Details and summary

A list of tags for this post.

This post is a part of a series where I write a post for each module of the Learn HTML course. I'll note things I didn't know, highlight interesting items, and generally enjoy having a Hot HTML Summer.

This post covers the Details and summary module of Learn HTML. Each section below corresponds to a section in this module of the course. The quoted items are relevant passages from the course.

Intro section


There’s no anchor for this section, it’s the first part of the module.

jQuery has included an accordion UI pattern since at least 2009. The original JavaScript-free accordion solution included making each FAQ question a <label> followed by the checkmark it labeled, and then displaying <div> answer when the checkmark was checked.

I didn’t know this bit of history.

Like all semantic content, you can progressively enhance the default features and appearance.

Heart emoji.

Toggling visibility: the open attribute


Go to this section at Learn HTML.

The hidden content in the collapsed state is searchable in some browsers but not others, even though the collapsed content is not part of the DOM. If you search in Edge or Chrome, the details containing a search term will expand to display the occurrence. This behavior is not replicated in Firefox or Safari.

I knew this one because Manuel Matuzović posted about this earlier in the Hot HTML Summer. He also has a post on inconsistencies for screen reader users that’s worth a look if you are planning on using <details>.

How errors are handled


Go to this section at Learn HTML.

If you don’t include a <summary>, the browser will create one for you: with a marker and the word “details”. This summary is part of a shadow root, and therefore will not have author CSS summary styles applied. Unfortunately, Safari does not include the details in the keyboard focus order.

Didn’t know this, good to keep in mind. And…

If you do include a <summary>, but it is not the first element in the <details>, the browser still displays the summary as it should. It will also not fail if you include a link, label, or other interactive element within the summary, but browsers handle interactive content within interactive content differently. For example, if you include a link in a summary, some browsers will add both the summary and the link to the default tabbing order, but other browsers will not focus on the link by default. If you click on a <label> nested in a <summary>, some browsers will give focus to the associated form control; other browsers will give focus to the form control and toggle the <details> open or closed.

I couldn’t find any examples of screen reader test results for interactive elements within the summary, but if you planned on taking this approach it would be best to test it.

A list of tags for this post.

Enjoying this site? Leave me a tip at Ko-fi!

Back to top