A details element as a burger menu is not accessible

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:

• No JavaScript required!
• The menu starts closed, which means no layout shift (and an excellent Cumulative Layout Shift metric score)
• Has great overall browser support

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

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

<details>
  <summary>
    <h2>Main menu</h2>
  </summary>
  <nav>
    <ul>…</ul>
  </nav>
</details>

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.