Native HTML Popover Cuts Script and ARIA From Site Navigation

A navigation pattern published by accessibility engineer Adrian Roselli now opens and closes submenus with no JavaScript and no aria-expanded, using the native HTML popover attribute instead of scripted disclosure widgets. The pattern is a rework of his 2019 "Link + Disclosure Widget Navigation" post, and it changes the arithmetic for teams that previously maintained custom state management for every expandable menu.

Roselli's earlier approach relied on <button aria-expanded> triggers, which cannot function without script. The HTML-native alternative, <details> and <summary>, carries its own defects. In two browser engines, in-page search hits force <details> elements to expand. Exposure to accessibility APIs is inconsistent across browsers and over time. Roselli also reports that styling overrides routinely confuse teams. He documented each failure mode in a 2020 post.

The popover attribute, defined in the HTML Living Standard, removes script from the equation. A <button popovertarget="SubItem02"> paired with a <ul id="SubItem02" popover> gets open and close behavior from the browser alone.

What does the pattern give developers for free?

Three behaviors previously required hand-written code:

• Escape-key closing — automatic.
• Click-outside-to-close — automatic.
• Programmatic expanded state — popovertarget conveys aria-expanded semantics without the author writing it.

Focusout-to-close behavior is the one exception; authors must still write it themselves. The popover specification also does not manage focus, so the HTML requires placing popover content immediately after its trigger in the DOM to avoid reading-order and focus-order problems.

Roselli retains two deliberate uses of ARIA. He marks the current page with aria-current="page" and uses that same attribute as his CSS selector, a technique he has advocated since 2021. He names each trigger button with aria-labelledby pointing at the adjacent link text, which avoids text duplication and auto-translation issues while giving voice-control users one utterance that presents both the link and the button as options.

What are the constraints?

The pattern carries prerequisites that rule out casual adoption. Popovers render in the top layer, so any site still using z-index-managed dialogs will hit overlap issues unless every dialog already uses the native <dialog> element. CSS anchor positioning, which the layout depends on, only recently reached cross-browser support.

Roselli's demo also conformed to WCAG 2.2 Success Criterion 2.5.8, Target Size (Minimum), for its triggers. The styles use logical properties throughout, with test buttons cycling four writing directions, and support forced-colors mode with no custom CSS because focus styles use outlines.

Positioning proved the hardest part. Roselli reported that aligning the popover to the right edge of the parent item across Firefox, Chromium, and Safari — without overflowing the window or breaking under text-direction changes — was a challenge, and that positioning fails in vertical writing modes, though he could not confirm whether the fault lay in his code or in browser bugs.

Community response

Ana Tudor forked the demo the same day, replacing block links with grid layout, improving the SVG, and keeping popovers in the viewport for vertical right-to-left layouts. Curtis Wilcox produced a fork using the anchor positioning polyfill. Nathan Knowler noted that :not(:open)::details-content can suppress the in-page-search expansion problem in <details>, with a demo on his own site.

On 10 July 2026, Kirk Loretz built a pen testing popover positioning across writing modes and filed issue #14159 against the CSS Working Group's css-anchor-position-1 draft, titled "Popover text direction/writing-mode bugs."

On 27 August 2026, Roselli amended the code after reading Ahmad Shadeed's post on flex-wrap: balance. He added the balance value alongside wrap rather than replacing it, because balance shipped only in Chrome 150, released 30 June 2026. Replacing wrap entirely would stop navigation items from wrapping in Firefox and Safari. The value originates in the CSS Flexible Box Layout Module Level 2 Editor's Draft.

Roselli's stated disclaimers are blunt: the pattern may not suit every audience, likely contains bugs, and browser support can change. He closes with an open request for contributors with multilingual popover anchor positioning experience to share their findings — a signal that this pattern is still stabilizing as implementations mature.