Accessible accordions part 2 – using <details> and <summary>

In my last post My favourite accessible accordion pattern I discussed how you could use a combination of HTML elements, some JavaScript and some appropriate ARIA to create a fully accessible accordion component that could be used by everyone.

Frank Palinkas left a comment on the post concerning the use of the <details> and <summary> HTML elements in accordions.

We always say that it’s good to use native controls wherever possible – see our future of accessibility podcast where I talked about the various custom dropdown elements I had encountered in various projects.

So I decided to do some more investigation to see whether or not these newer elements could safely be used to provide a native way of presenting accordions, that is also accessible to everyone.

The short answer is that support for these elements is fairly good in modern browsers, but it’s currently not as accessible as our suggested pattern. The longer answer is the rest of this blog post.

Using the <details> and <summary> elements

These two elements were first introduced with HTML5 some years ago, but so far they have not been widely used.

The idea is that together they can natively allow an area of content to be expanded and collapsed with user interaction – in other words, to create an accordion.

The <details> element contains all the content, and the <summary> element contains a short piece of text that summarises the rest of the content.

The <summary> element should be nested within the <details> element – in fact it should be the first child of the <details> element. So a typical structure would be:

<details>
<summary>Text that summarises the rest of the content</summary>
<p>Some detailed text for the user to read. It should be hidden 
by default, but will become visible when the user interacts with 
the summary element.</p>
<p>Multiple paragraphs and other elements are allowed.</p>
</details>

If you want more technical details, I’d really recommend this background article on these elements. Here I’m going to look at the accessibility implications of using them.

My original accordion requirements

Let’s revisit my own requirements for an accessible accordion from the original post:

1. Can be operated by a mouse click.
2. Can be operated by touch – on smartphones, tablets or desktops/laptops with touch screens.
3. Can be operated by keyboard – important for sighted keyboard-only users, and desktop/laptop screen reader users.
4. Can be operated easily by speech recognition software, like Dragon NaturallySpeaking.
5. Can be operated easily by users with screen magnification tools.
6. Can be easily understood by screen readers – are they aware the component is interactive, and whether the content is hidden or not.
7. It must be possible to close all the accordion panels if required.
8. It is not reliant on JavaScript to reveal content
9. The accordion should look good, and signal functionality to sighted users.

This is still a good list, but thinking about new elements like <details> and <summary>, a final requirement should be added: that the solution is supported within browsers that people are using.

Testing <details> and <summary> against the requirements

For the purposes of testing how the <details> and <summary> elements perform, I have created a new test page that uses them.

The page features two examples. In the first one the <summary> contains just plain text. As I liked using a header in my previous test page to help screen reader users find sections they might be interested in, the second example contains a header inside the <summary> element. I’ll be looking out for mention of the header when testing with screen readers.

Browser support for <details> and <summary>

Not surprisingly, support for the elements is better with more modern browser versions, but that is not always true.

These screenshots from Firefox 64 show that this browser supports the elements. Firstly, the element as initially viewed on the page:

And then, once the user has interacted with the <summary> element.

The view in Chrome on Windows 10 is broadly similar.

However, Internet Explorer 11 does not support the elements at all and so all the text just appears on the page without any arrows. There is no interactivity supplied by the browser. See screenshot below.

So here’s my list of support for these elements in current browsers, as at January 2019:

• Firefox 64 on Windows 10 – Supported
• Chrome 71 on Windows 10 – Supported
• IE11 on Windows 10 – No support
• Edge 17 on Windows 10 – No support (Perhaps surprising for a newer browser. Support may emerge once Edge is based on Chromium.)
• Chrome 71 on Android 8 – Supported
• Edge 42 on Android 8 – Supported
• Firefox 64 on Android 8 – Supported
• Safari on iOS 11 – Supported
• Safari on MacOS 10.14 Mojave – Supported

Full support details at Can I Use.

For browsers that don’t natively support <details> and <summary>, polyfills by mathiasbynens and LaurentGoderre exist to provide the functionality, but I haven’t tested them extensively.

Lets have a look at the other requirements, to see how <details> and <summary> stack up in terms of accessibility.

Requirement 1 – Operated with mouse click

Using desktop and laptop devices, all browsers that support the elements provide clickable interaction natively. Internet Explorer and Edge don’t provide this, but all the content is visible anyway.

Requirement 2 – Operated by touch

On mobile devices, using browsers that support the <details> and <summary> elements, the expanding and collapsing can be achieved by touching the <summary> element.

The same is true for laptops with touch screens.

Requirement 3 – Operated by keyboard

This is obviously important for sighted keyboard-only users, and desktop/laptop screen reader users.

On Windows/Mac desktops/laptops using browsers that support the elements, the <summary> element automatically becomes a tab stop on the page. Once focus is on the <summary> element, the full <details> content can be toggled by using either the enter key or the space bar. So the <summary> element is effectively treated as a <button> element.

On Android devices, it is also possible to use a Bluetooth keyboard to control all aspects of the phone without using the built-in Talkback screen reader. Testing with browsers on my Android phone with a Bluetooth keyboard shows that the elements are supported.

Requirement 4 – Operated easily by Dragon NaturallySpeaking

Dragon NaturallySpeaking is Windows based voice recognition software. It is often used by those with severe motor impairments to control their machines. It is also used by people who are dyslexic, and others with cognitive impairments.

Since Windows-based browsers that support <details> and <summary> seem to treat the <summary> elements as buttons, I’d be expecting it to be easy to issue the necessary voice commands to expand the sections.

However, Dragon works best with Internet Explorer 11, and as we have seen, IE11 doesn’t support the <details> element. So I’ve tried it with Chrome and Firefox instead using version 14 of Dragon NaturallySpeaking.

The good news is that it works as expected. I can say “click [summary text]” and it toggles the content open and closed as required.

Requirement 5 – Operated when screen magnification tools are running

The entire area of the <summary> is clickable and responds to touch events, and by default it stretches to the full width of the available content area.

So assuming that suitable styles are applied to the summary element, users of screen magnifier tools will be readily able to toggle the content areas.

Requirement 6 – Understood by screen readers

In my version of the accessible accordion in my previous post, the element that opens the accordion is a button contained within a heading. That way the button is announced by screen readers, and the rationale for having the button in a heading is that screen reader users can list the headings on the page and find the sections they are interested in.

Ideally, with the <details> and <summary> elements I’d want there to be a similar announcement by screen readers a) that the <summary> element is interactive, and b) whether the <details> element is expanded or collapsed.

Finally, I’d want the full content to be hidden from the screen reader when it is collapsed.

Let’s see how different screen readers behave with the native element.

JAWS 18 for Windows

Normally I’d run JAWS with Internet Explorer 11, but since the <details> element is not supported in IE11, I’ve tried it with both Firefox and Chrome.

Unfortunately JAWS 18 does not appear to be compatible at all with Firefox 64 as I could get no meaningful interaction with anything on the test page (or any other web page in fact). So I had to abandon that test.

Using Chrome was much more successful. The <summary> element announced itself as a button – both when I tabbed to it, and when I used the up/down arrow keys to move to it. JAWS informed me whether or not the page element was collapsed or expanded. It also updated me with the new state when I used the enter key or space bar to toggle the contents. And when the component was collapsed, the full content was not accessed by JAWS.

So that works well.

NVDA 2018.4 for Windows

NVDA is best used with Firefox, so I tested it with this browser.

If the user uses the down or up arrow to get to the <summary> element NVDA announces it as “button collapsed [summary text]”. But if user tabs to it, the announcement is subtly different – “[summary text] button collapsed”. It also announces the heading and level in the second example.

The <summary> elements show up as buttons in NVDA’s elements list. The heading in the second example also shows up as a heading in NVDA’s elements list. So far, so good.

Sadly though, when the user actions the element with the Enter key or Space bar, there is no announcement of the toggle (state change) – so the user has to trust that something has happened. But when moving away from the <summary> element and then back again, NVDA will announce “expanded” instead of “collapsed” – as appropriate.

Given how NVDA performs when the value of aria-expanded is toggled in my previous example, this is disappointing.

However, this is a known issue with NVDA, and there is an open issue on the NVDA Github repository about it.

Voiceover with Safari on Mac

When you arrow down to the <summary> element, Voiceover says “Summary New Line. You are currently on a text element”. So it appears not to read out the text within the summary, or the state.

However, when you tab down/up to a <summary> element, Voiceover says “[summary text]. Collapsed. Summary. You are currently on a summary. To click this button, press Ctrl-Option Space”. This is better, and Voiceover is announcing “Collapsed” or “Expanded” when you tab to the element.

Once focus is on the <summary>, if you use space to open the element, sometimes no announcement is made. But if you use “Ctrl Option Space” the announcement is made: “[summary text]. Expanded. Summary. Main.” when expanding, or “[summary text]. Collapse. Summary. Main” when collapsing.

Voiceover with Safari on iOS11

Voiceover reads the <summary> text and says “collapsed”. It doesn’t specifically voice the element as a button, but it does announce “double tap to expand” implying that this is an interactive element.

Once I double tap, Voiceover announces the <summary> text and then says “expanded”. Double tapping once again toggles the content and Voiceover announces that the element is collapsed.

Checking with the rotor confirms that Voiceover does not see the <summary> as a button.

In the second example on the test page, there is a heading within the <summary>. The heading and level are announced, so having the heading there could be helpful.

Talkback with Chrome 64 on Android 8

Upon arriving at the <summary> element, Talkback announces “collapsed, [summary text], disclosure triangle” and then “Actions: expand. Double tap to activate”. So the user knows the element is interactive and that the element is collapsed.

Double tapping causes the content to be shown, and Talkback announces “Expanded”. Double tapping once again toggles the content and Talkback announces that the element is collapsed.

When Talkback visits the second example with the heading, there is no voicing of the heading or level. Tweaking the Talkback navigation options reveals that Talkback sees these elements as ‘Controls’.

Requirement 7 – All the accordion panels can be closed if required

This is not a problem – the user is in complete control of the states.

It is however possible to have the <details> element expanded by default by adding the open attribute when the page is loaded.

Requirement 8 – Not reliant on JavaScript to reveal content

Obviously that requirement is satisfied since the browser handles all the functionality.

Requirement 9 – Accordion should look good, and signal functionality to sighted users.

Browsers that support <details> and <summary> add in a disclosure arrow to the left of the <summary> text. Initially the arrow points to the right, but when the user has expanded the content the arrow points down.

Since <details> and <summary> are HTML elements, their appearance can be influenced by using CSS definitions. So in theory the elements can follow whatever style is required:

• It’s possible to use the :hover and :focus pseudo-classes to influence how the <summary> responds to mouse over and keyboard focus.
• The browsers’ addition of the open attribute to the expanded <details> section can be exploited using attribute selectors in the CSS. For expanded – details[open] and collapsed – details:not([open]).
• If a heading is included in the <summary> element, it’s necessary to make sure it is set to display:inline to avoid odd alignment with the disclosure arrow placed there by the browser.
• If required, it is possible to override the default disclosure arrow using vendor prefixes or possibly by changing the list-style-type (preferred technique, alternate technique).

Conclusion

As we’ve seen, browser and assistive technology support for the <details> <summary> construct is now generally pretty good, but with deficiencies in Windows-based browsers Internet Explorer and the newer Edge. Whilst Edge may start supporting the <details> <summary> combination soon when it becomes built on Chromium, there will never be any native support within Internet Explorer.

It’s possible for developers to overcome browser support issues by using the polyfills mentioned earlier within the sites they build. These polyfills bring the elements more into line with the JavaScript/ARIA model I proposed in my initial post.

There are some deficiencies in assistive technology support – specifically the missing state change announcements in NVDA. Whilst this doesn’t prevent NVDA users from interacting with the elements, they do rely on users understanding the interaction that’s going on. We hope that the deficiencies with the screen reader functionality will be addressed soon. While it’s not possible to vote for bugs on the NVDA Github, developers could add comments on the issue.

So is it OK to use the <details> and <summary> elements in an accessible way?

We always say that it’s good to use native controls wherever possible. However in the case of <details> and <summary>, the browser/AT support issues mean that it’s currently not as good as the accessible accordion pattern I outlined in my previous post. But it is better than a badly implemented accordion pattern.

Therefore, at the moment our view is that it’s still too early to embrace the <details> and <summary> elements to provide a fully accessible accordion experience.

Our hope will be that the NVDA issue is resolved soon, and that the Chromium version of Edge will support these elements properly.

What do you think?

We hope these insights are useful to you, and would love to hear your experiences around implementing accessible accordions. Please share your comments below.

Want more?

If this blog has been useful, you might like to sign-up for the Hassell Inclusion newsletter to get more insights like this in your email every month.