How to build accessible nested popovers and manage showPopover(), focus, and light-dismiss

The fixture exports one HTML document from main.mjs. Open options is a declarative popover invoker; Background action is a normal button outside both panels. The parent contains More options and Parent action. The child contains two selectable options. Both panels use popover="auto", so the browser controls their top-layer visibility and automatic dismissal. The fixed positions deliberately keep the parent, child, and outside button apart, making the click targets unambiguous in a regression test.

Neither panel makes the rest of the document inert. The non-modal test opens both panels, programmatically focuses Background action, and verifies that the focus change succeeds without closing either panel. This is a positive control: it would fail if application code accidentally turned the interaction into a modal focus trap. A popover appearing above the page does not give it exclusive ownership of page input. When true modality is required, choose and test an appropriate modal primitive instead.

The markup uses role="group" with accessible names, and each option remains an ordinary button in sequential keyboard navigation. Adding role="menu" would introduce expectations such as menuitem semantics, arrow-key navigation, and managed tab stops that this example does not implement. The one ArrowRight shortcut is an application convenience for opening the child, not evidence of a complete menu pattern. Keep those boundaries visible when adapting the example into an actual navigation menu or command palette.

The child is not a DOM descendant of the parent. Its relationship comes from the source supplied to showPopover: the More options button inside the open parent invokes the child. This exercises the source-based nesting case directly. Merely placing two panels next to each other visually would not establish the same interaction relationship. The tests require both panels to remain open after the child opens, so accidentally opening an unrelated auto popover cannot pass unnoticed.

The source option also establishes a focus-navigation relationship. In this fixture no element has autofocus, and opening the child does not explicitly call focus. The first Tab from its source reaches the child’s first option, the next reaches its second, and Shift+Tab returns to the first. These assertions observe concrete element IDs rather than accepting any active element. They test the insertion point in keyboard order without asserting that focus must stay inside the popover forever.

Programmatic opening does not automatically provide all the accessibility relationships of a declarative popovertarget control. The fixture supplies aria-controls and aria-details, initializes aria-expanded to false, and updates expanded state from the child’s toggle event. The test waits for expanded state to become true. This documents the application’s contribution separately from the browser’s top-layer behavior. It does not demonstrate how every screen reader announces those relationships, which still needs task-based assistive-technology testing.

More options opens the child on click and on ArrowRight. The keyboard handler prevents the key’s default behavior and calls the same openSub function used by the click handler. That function passes the actual invoking element as source. There is no catch-all error handler that logs a failure and lets the interface pretend it succeeded. The test harness records page errors and fails if the fixture produces one, keeping script failures distinct from successful DOM interactions.

The example does not schedule a microtask as a supposed universal cure for toggle reentrancy. Its opening call comes from a user interaction after the parent is already open, not from a beforetoggle callback. A resolved promise is not proof that an arbitrary component transition or asynchronous operation has completed. In a larger component, identify the actual state dependency, observe the relevant event or condition, and avoid recursively changing the same popover from its own transition handler.

Selecting a child option is a separate application action. Each option hides the child and explicitly focuses More options, leaving the parent open. The corresponding test asserts all three outcomes: child closed, parent open, and source focused. This is intentionally not presented as a universal browser guarantee. After a real selection, the appropriate next focus target might instead be a new item, an editor, or a confirmation. Choose that target based on the task and assert it directly.

Clicking Parent action is outside the child but inside its logical parent. The child should close while the parent remains open. The test clicks that named control rather than a guessed body coordinate, then verifies both popover states and the focused parent control. This is the interaction that preserves the parent context. It is not equivalent to clicking somewhere unrelated on the page, even though both clicks are outside the child’s rectangle.

Clicking Background action is outside the entire stack. Both panels should close, and that outside button should receive focus. This is not an over-eager dismissal or a focus leak: it is the expected non-modal interaction. A test that insists the parent remain open after a body click confuses the two boundaries. Keeping separate named tests for the parent-area click and the outside-stack click makes that confusion much harder to reintroduce during a refactor.

The positions in this fixture support deterministic targeting but are not a production positioning strategy. They do not demonstrate collision detection, viewport-edge flipping, scrolling anchors, or responsive layout. Those concerns need their own component tests. The dismissal assertions depend on which element receives the click and its relationship to the open popovers, not on a particular pixel offset. Preserve that distinction when replacing the fixed test layout with CSS anchor positioning or an application positioning library.

The Escape test opens both panels, tabs into the child, and presses Escape once. It requires the child to close while the parent stays open, and checks that focus is no longer inside the hidden child. A second Escape must close the parent as well. Unlike an outside click, this is a sequential dismissal interaction. Combining the two into one generic “close overlay” expectation would miss the difference that matters for nested keyboard navigation.

Do not assume the source option always restores focus to the invoker after every dismissal. Native restoration depends on the opening and focus behavior. This fixture has no autofocus and leaves the initial focus on the source before Tab moves into the child; its Escape test therefore does not promise a particular restored invoker. Selection is different because the application explicitly focuses its source. If your product requires invoker restoration on Escape too, implement and test that policy without stealing focus after an intentional outside click.

Closing the parent through Open options is tested independently and must close its logical child. There is no defensive parent-toggle listener that manually hides the child, so the test can observe the native nested-popover relationship instead of merely testing application cleanup. Removed invokers, route changes, and component unmounting are outside this fixture. An integration test for those cases should decide the logical next focus target and verify that no detached or hidden control retains interaction state.

Save main.mjs and main.test.mjs together. With Node 22, run npm init -y, install the pinned dependency using npm install --save-dev playwright@1.63.0, and install the browser with npx playwright install chromium. Then run node --test main.test.mjs. Browser installation is a setup action, not something the tests perform. In a controlled runner, use a matching browser image and install operating-system dependencies before running the fixture; a missing executable is not a popover regression.

Each case launches a fresh headless Chromium instance, loads the fixture with page.setContent, aborts page network requests, and closes the browser in finally. State waits use page.waitForFunction with one serialized argument, such as the object containing the expected parent and child states. Playwright does not accept several positional application arguments after the callback. Passing an empty object where a selector is expected causes querySelector to receive “[object Object]”, failing before the intended browser behavior can be checked.

The seven tests cover source-based Tab order, parent-area dismissal, outside-stack dismissal, sequential Escape, explicit selection focus, non-modal background focus, and parent closure. Passing them establishes those observations for this fixture in the tested Chromium version. It does not prove Firefox or WebKit behavior, screen-reader announcements, visual contrast, or a complete menu widget. Run relevant cases against supported browsers and the real component, add manual keyboard and assistive-technology checks, and retain the exact fixture revision with the resulting evidence.