Firefox 49 supports the HTML5 and elements

As you may or may not have heard, Firefox 49 supports the HTML5 <details> and <summary> elements. Both full keyboard support and support for assistive technologies is also available right from the start.

What are they?

<details> and <summary> allow to dynamically show and hide blocks of content. For example, when composing a list of frequently asked questions, each question could be wrapped in an details-summary-block, with the summary being the question, and the details following in the rest of the details block. The user can then show and hide the details by just clicking or pressing on the summary content.

Previously, to achieve the same goal, web developers would have had to use a <button> element and bind some JavaScript to it that would show or hide some other adjacent block of text by modifying certain CSS properties. And as things go, these turned out to not always be accessible. Either developers used a clickable <div> or <span> element without proper keyboard support, or forgot to add the proper WAI-ARIA semantics, or both, turning these kinds of dynamic content into a challenge.

Well, no more, as the HTML5 specification addresses these issues with the <details> and <summary> elements.

An example

This can be very easily demonstrated. Navigate to the below heading, which is going to be announced by screen readers as a button, with a collapsed state, and then press Space, or use the mouse or your finger (when on a touch screen) to click or press on it. Then, the button will change to an expanded one, and there will be another new paragraph below that heading. You can press on the button again to collapse that paragraph again and make it disappear.

Press me to show what I’m wearing underneath

Hahah, thought you’d find something naughty here, eh? Well, sorry to disappoint, it’s just a silly rambling of mine. Go ahead and go back up to close me again.


The code for this is pasted below.

<details><summary><h3>Press me to show what I'm wearing underneath</h3></summary>
<p>Hahah, thought you'd find something naughty here, eh? Well, sorry to disappoint, it's just a silly rambling of mine. Go ahead and go back up to close me again.</p></details>

The content inside the <details> element can be all kinds of elements like lists, tables, sub headings if need be etc. Just remember to keep the proper heading structure when you do it. The fact that I used a heading up there is totally optional, too. It just fits in the heading structure of the blog.


Hope these elements will now help to create more accessible collapsible content blocks! Other browsers like Chrome and Safari also support these elements, and we’re hoping that Microsoft Edge will follow lead soon as well!



13 thoughts on “Firefox 49 supports the HTML5 and elements

  1. This is somewhat troubling. The version that exists in browsers that do not support this markup is by far more accessible than the version supported. The reason I make this claim is because now the question, imagine if that was a question in an FAQ like you said, is a button. That means that one can’t browse by the heading markup, that has gotten eaten up, to navigate the hierarchy, the semantic hierarchy I should add, that the content author has spent time architecting. Are a11y folks seriously OK with this solution?

    1. Hi Sina, I see the heading despite the surrounding element being declared a button. I can navigate to it, and I get told that it is collapsed. Using NVDA and Firefox. I also see this with VoiceOver and Safari on OS X.

    1. And that’s probably a good way to think–at least right now. It’s still true that a lot of persons using screen readers are using Windows.

  2. I doubt that we’ll ever see this implemented in IE. But, I can file an enhancement request for Edge. Considering the fact that Edge support by screen readers is preliminary at best, we might actually get and support in Edge by the time screen readers fully support the browser.

    At this time, both IE and edge seem to ignore the presence of and . Remaining elements are interpreted. if people do use these elements during development, users will get fully expanded content. Expand and collapse won’t be possible.

  3. Not as i would expect:
    A. SR should announce change of state and only change of state not the all summary again.
    B. On state change (open=true|false), UA should shift focus appropriately.

    NVDA + FF does not report change of state. No focus change,
    Jaws + FF report state change but reads the summary again. No focus change.

    1. I would expect the summary to act like a button and not move my focus, allowing me to toggle at will instead of constantly shift-tabbing every change. When I know a button has aria-expanded set to true that I can arrow down into content. If the summary tells me it’s open, I would expect the same.

  4. This is great for the web. Hopefully the a11y issues will be ironed out in the near future. Meanwhile it has the potential to reduce the dependance on JS libs and the weight they add to pages, simply to provide a very simple and very common use case.

    Browser devs should take this example and follow it, hard, so we can stop seeing Chris Heilman whine about the state of the web 🙂 Once an established, simple pattern like this is seen on the web, it should be immediately pushed into a rapid-review process for streamlining it’s way through standards and into browser engines. Follow that up with developer awareness, the sort of stuff we should be flooding Heilmann’s time with so that he stops hypocritically whinging about the web immediately after whinging about people bagging the web. I mean really, come on, he’s done it in successive posts! Just nine days apart.

  5. I can file an enhancement request for Edge. Snapback Caps Considering the fact that Edge support by screen readers is preliminary at best, we might actually get and support in Edge by the time screen readers fully support the browser.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.