The Popover Pattern That Actually Respects Screen Reader Users

The button renders. The submenu appears. And somewhere, a screen reader user exhales.

That small moment — a navigation pattern that just works without requiring the user to decode broken state announcements or fight a keyboard trap — is what Adrian Roselli's Link + Popover Navigation (opens in new window) is actually about. Published July 9, 2026, it updates his widely-cited 2019 disclosure widget pattern by replacing ARIA-heavy scripting with native HTML popovers. The technical shift is real. But the human case for it deserves more attention than the code does.

What Changed, and Why It Matters to Real Users

Roselli's original pattern used <button aria-expanded> — an ARIA-based disclosure widget that requires JavaScript to function. His updated pattern uses the popover attribute with popovertarget, which delivers aria-expanded state management automatically, without a single line of script handling that state manually.

For users of screen readers like NVDA, JAWS, or VoiceOver, this distinction is not academic. ARIA-based patterns depend on developers implementing state correctly, every time, across every browser update. When that implementation breaks — and it does break, routinely — users get buttons that announce "collapsed" when they're open, or menus that appear visually but never surface to the accessibility tree. Our research on automated testing limitations found that automated tools catch at most 37% of real accessibility barriers. Broken ARIA state is exactly the kind of failure that slips through.

Native HTML doesn't have that fragility. When the browser handles the semantics, the semantics are consistent. Roselli's pattern gets Escape-to-close, click-outside-to-close, and proper expandable state — all without custom scripting. That's not a developer convenience. It's reliability for users who depend on predictable behavior.

The Naming Decision Deserves Its Own Paragraph

The most instructive detail in this pattern isn't the popover itself. It's how Roselli names the button.

He uses aria-labelledby to point the button's accessible name at the preceding link's text — so a button next to an "About" link is announced as "About, expanded, button" rather than requiring duplicate visible text or an aria-label that might drift out of sync during translation. His reasoning: screen reader users hear a different control type and know it's expandable. Voice control users saying "About" get a choice between the link and the button.

This is the kind of decision that only makes sense if you've actually thought about who uses the interface. Not a persona. Not a checklist item. The real, specific experience of a Dragon NaturallySpeaking user trying to expand a submenu, or a braille display user navigating by control type. The pattern reflects that thinking.

Where the Pattern Has Real Limits

Roselli is candid about what doesn't come for free. Focusout-to-close requires custom scripting. Popover positioning across writing modes — particularly vertical text directions — breaks down in his current implementation. He says so directly, and invites suggestions.

There's a broader constraint worth naming: this pattern only works cleanly if your site already uses native <dialog> elements for modal content. If your site mixes custom modal implementations with popovers, z-index conflicts and layering issues will follow. That prerequisite matters enormously for organizations with legacy codebases — which is most of them.

The compliance framework paradox our research describes plays out here in miniature: adopting a better pattern requires that your surrounding infrastructure already meets a certain baseline. Teams that skipped proper dialog implementation years ago now face a sequencing problem. The right pattern exists. Getting there requires fixing things that came before it.

The Bigger Question This Pattern Raises

What does it mean that a navigation pattern this thoughtful — handling keyboard access, screen reader state, voice control, focus order, forced colors, motion preferences, and writing direction — exists as a single developer's blog post rather than as a default in the frameworks most teams actually use?

Roselli's pattern conforms to WCAG 2.5.8 Target Size (Minimum) (opens in new window), supports Windows High Contrast Mode without custom CSS, and honors prefers-reduced-motion. These aren't advanced accessibility features. They're baseline expectations for users who rely on them daily. The fact that achieving them requires this level of deliberate, expert effort — and that most navigation implementations don't bother — is the systemic problem underneath the technical solution.

For disability communities navigating websites daily, the gap between what's possible and what's deployed is not a technical gap. It's a priority gap. Organizations that would benefit from reading Roselli's post are often the same ones that won't find it, because they haven't made accessibility part of how they evaluate technical decisions at all. The settlement trap research documents what happens downstream: reactive fixes after litigation, without the organizational capacity to sustain them.

What Practitioners Should Take From This

If you're evaluating or building navigation patterns right now, three things from Roselli's post warrant immediate attention:

Audit your popover prerequisites first. Before adopting this pattern, check whether your existing modal and overlay implementations use native <dialog>. If they don't, the z-index conflicts will create new barriers while you're trying to fix old ones.

Test the button naming in actual assistive technology. The aria-labelledby approach is sound, but the experience varies across screen reader and browser combinations. Roselli's pattern is a strong starting point — it's not a substitute for testing with real users and real tools.

Don't treat "no JavaScript required" as "no maintenance required." Browser support for anchor positioning is recent. Behavior across Firefox, Chromium, and Safari will continue to evolve. Roselli flags positioning as an active challenge. Build in a review cycle.

The pattern works. It works because someone spent serious time thinking about the people who would use it — not as edge cases, but as the actual audience. That orientation is what separates accessible navigation from navigation that passes a checklist. The question worth sitting with: how many teams building navigation today are starting from that same orientation, rather than arriving at it only after something breaks?