Skip to main content

A details element as a burger menu is not accessible

By Gerardo Rodriguez

Published on September 20th, 2022

An illustration of a faux burger. The bun is a frosted cake cut in half with lit candles as the topping. The cake bun holds a shark-looking fish with a confused expression along with some seaweed-type leaves.
Illustration by Paul Hebert

Using the native HTML disclosure widget for a burger menu is so enticing. Toggling menu navigation links open/closed without any JavaScript is a big win. Unfortunately, the details/summary elements come with accessibility issues, so it’s not an inclusive solution.

I previously explored different strategies for removing layout shift from a progressively enhanced burger menu. Before publishing, I removed one technique that used a native HTML disclosure widget (<details>/<summary> elements). I had a demo and WebPageTest result ready to go. The potential solution was exciting:

Sadly, using a native HTML disclosure widget has accessibility issues. 

For the purposes of this article, let’s consider the following code snippet:

    <h2>Main menu</h2>
</details>Code language: Handlebars (handlebars)

Now let’s look at why it is problematic.

Using voice control with assistive technology like Dragon Naturally Speaking with Chrome or Voice Control (macOS) with Safari means you cannot use the “Click <text name>” command to activate the <summary> toggle element. Saying “click main menu” does nothing. Using the element role instead (e.g., “click button” or “click summary”) will also fail with Dragon Naturally Speaking.

With some screen readers, such as NVDA with Chrome and Edge and VoiceOver (iOS) with Safari, the disclosure widget expanded state is not announced, nor is the state change when toggled between a collapsed and expanded state.

VoiceOver offers a rotor feature as an alternative method of navigating to elements on the page. But unfortunately, the <summary> element is not accessible through any of its menus. The <summary> element has an implicit ARIA role of “button,” but even so, it is not listed under the “buttons” or “form controls” list. It’s as if it’s not even on the page. Accessing the <summary> element via the “Next Form Control” shortcut won’t work either.

When using VoiceOver (iOS) with Safari, the role of the summary element is not conveyed. There is no announcement like “button,” “details,” or “summary,” which means a screen reader user won’t know the element is interactive. Instead, assuming the code snippet above, VoiceOver only announces:

main menu, heading level 2

Children of the <summary> element can have their semantics removed. If you navigate to a <summary> element containing a heading, VoiceOver (macOS) with Safari does not mention anything about the heading:

main menu, collapsed, summary, group

Neither does JAWS with Chrome, Edge, or Firefox:

main menu, button, collapsed

Nesting a heading in the <summary> element is a contrived example. If the child element semantics aren’t important (e.g., a <span> element), then it should be okay. It can also be argued that this is expected behavior since <summary> has an implicit role of “button.” But this restraint may not be obvious at first and is also inconsistent depending on the assistive technology & browser combination.

Because the <summary> children semantics are removed, there is no longer a way to use a shortcut to jump to the element. For example, with JAWS, you can navigate to the next heading using the "h" key. No heading semantics means the ability to use shortcuts is not available.

I consider myself an accessibility advocate, and even so, I very nearly published in my previous article a recommendation to use a native HTML disclosure widget as a technique for a burger menu, unaware of the above accessibility issues. Those of us with the privilege of not depending on assistive technology to navigate the web have an increased responsibility to validate that what we design and build is accessible. I wrote this article in hopes that it might help others as I was having a very difficult time understanding how using a native HTML disclosure widget for a burger menu leads to accessibility issues. I also wrote this article as a reminder to myself to check my own privilege as I work toward the goal of helping create a more inclusive web.


sl said:

This is good information. However, it points out failings of accessibility software, not failings of html or current major browsers. Users of assistive technology should be petitioning designers of the software they use to be html standards conformant and work correctly. If everyone forever works around these failings there is no incentive for screen readers to improve… It is similar to IE controlling things for everyone all over again and why we, and users in need of accessibility tools, cannot have nice things.

I certainly support accessible design but draw the line when basic standards supported html elements are broken by third party tools. At a certain point it is the tool failing users with disabilities and not the design.

Replies to sl

Gerardo Rodriguez (Article Author ) replied:

Thanks for your message, I appreciate you sharing your thoughts! I certainly understand and relate to your frustration. There are already a few open bugs for the details/summary element experience in the WebKit Bugzilla tracker (see Bug 211284, Bug 108979, and Bug 241401), so hopefully, the situation will improve in VoiceOver and beyond in the future.

Whether the failure is in the assistive technology or the browser, the result is the same: The experience may be unusable for those who depend on these tools to do things a non-disabled user like myself might take for granted, such as navigating a website. User needs come first (see our priority of constituencies), so we’re happy to have plenty of other techniques for accomplishing the same task.

Peter said:

All the problems you list, seem to be generally bad support of details/summary in assistive technology, nothing specific about burger menu’s. Or am I missing something?