Angie, AI and Tenniel

For a long time, this was quite complex. Accessible navigation with submenus requires semantic HTML — properly structured nested lists — along with JavaScript using complex event listeners and dynamically updated ARIA states. In practice, this means: lots of code, lots of potential errors, and high maintenance effort. But that is starting to change.

The WHATWG has come up with something. The Web Hypertext Application Technology Working Group, the body responsible for developing HTML as a living standard, recognized that some UX elements are so universal that they belong directly in the browser. Not as a framework solution, not as a JavaScript workaround — but as native HTML. The <dialog> element was a first step, <details> another. The Popover API is a real milestone.

Popover API and Accessibility

The Popover API makes it possible to implement overlays, tooltips, and menus using just two HTML attributes, popovertarget and popover — largely without JavaScript. Since 2024, it has been part of the Baseline set, meaning it is supported in modern browsers (Chrome, Firefox, Safari, Edge). For navigation — and especially accessibility — this is a significant improvement. But be careful: while the API removes a lot of work, it is not a complete “all-in-one solution.” Especially with complex structures like a Joomla menu, it’s important to understand what the browser handles and where manual implementation is still required.

What the browser handles

As soon as you assign popovertarget to a button — pointing to the ID of the target element — and set popover="auto" on that target element, the browser takes over. The submenu automatically appears in the so-called Top Layer. And that’s not all — the browser provides three key features out of the box:

• State management: aria-expanded is automatically set to "true" or "false" depending on whether the element is open. Screen readers correctly announce “expanded” or “collapsed” — without a single line of JavaScript.
• Focus management: When a user opens the submenu via keyboard, focus automatically moves to the first link inside it. When the menu is closed, focus returns to the triggering button.
• Top Layer management: The target element is placed in the Top Layer. In practical terms, this means no more z-index chaos. The menu always appears above all other elements.

Accessibility: where we still need to step in

The Popover API has a technical detail that you need to be aware of. In the so-called Accessibility Tree — the structure read by screen readers — the menu loses its original context when placed in the Top Layer. It effectively becomes detached from its surroundings. To ensure users can still navigate effectively, four manual steps are essential:

• Give the dropdown a name. Even if the button and dropdown list are semantically correct within a nested <ul>, the dropdown loses its relationship to the parent structure in the Top Layer. An aria-label that references the triggering element solves this. The difference is noticeable: without a label, users hear “list, 2 items” — not very helpful. With a label: “Menu for …, list, 2 items.” Small effort, big impact.
• The announcement: aria-haspopup. While aria-expanded describes the current state — open or closed — aria-haspopup="true" goes further by signaling that the element can open a submenu. Without it, assistive technologies interpret the button as a regular link.
• The <nav> element as a landmark. Screen reader users often navigate pages via landmarks. To make the navigation discoverable, the entire structure should be wrapped in a <nav> element with a meaningful label. aria-label="Main navigation" is perfectly sufficient.

The popover lives in the Top Layer — and that’s the challenge. Above all other layers, there is no normal positioning context. position: absolute relative to a parent element simply doesn’t work there. CSS Anchor Positioning solves exactly this problem.

The new approach: one element — the dropdown — is positioned relative to another element — the triggering button. All without JavaScript.

In practice, this means using position-area to define the position relative to the so-called anchor. For a classic dropdown that appears below the button and aligns to the right, it looks like this:

Example:

#mybutton { anchor-name: --my-button; }

.joomla-dropdown {
  position: absolute;
  position-anchor: --my-button;
  position-area: bottom span-right;
  margin: 2rem 0 0 0;
  inset: auto;
}

Advantages of Anchor Positioning

• Reduces classic z-index issues
• Less need for JavaScript for positioning logic
• Stronger coupling between trigger and target element

Conclusion

The combination of the Popover API and CSS Anchor Positioning shows where modern web development is heading: many previously complex tasks — such as overlay logic and positioning — are increasingly handled or standardized by the browser itself.

This reduces the need for JavaScript for basic UI mechanics and significantly lowers the effort required to deal with common issues like z-index stacking or manual positioning logic.

At the same time, accessibility remains an active responsibility in development. While the Popover API supports aspects such as focus management and state handling, semantic structure, ARIA attributes, and meaningful landmarks still need to be implemented deliberately.

Taken together, this results in a modern approach: the API and Anchor Positioning handle the technical complexity of presentation, while developers remain responsible for clean semantics and accessibility.