Mobile navigation and focus: disclosure versus modal

Opening a mobile menu adds a floating panel to the screen, but that does not necessarily mean readers must close it before using the rest of the page. That distinction affects where Tab goes, what Escape does, and where focus ends up after the panel closes.

The site’s mobile navigation used a disclosure: one control expanded or collapsed a group of links. It was not modal and did not make the rest of the document unavailable for interaction. On October 26, 2026, I traced the actual HTML and event handlers to check these responsibilities separately.

Expanding navigation does not require taking over the page

The items in the panel were links to notes, products, work, collaboration, and about pages. Readers were choosing a destination, not completing a flow that required other activity to stop.

The W3C disclosure navigation example makes the same distinction: what we casually call a “menu” does not necessarily need the WAI-ARIA menu role. Ordinary website navigation usually does not need the full keyboard behavior of that composite widget. [1]

The site therefore kept native links and the normal Tab order. It did not add menu or menuitem roles or confine focus to the panel. That does not make modals a poor choice; the two interactions have different responsibilities. A dialog flow that readers must complete or cancel before continuing would call for reassessing background interaction and focus constraints.

Let the native control handle opening and closing

The mobile navigation was wrapped in details, and the first summary was the control. HTML defines this pair as a disclosure control. The summary labels the content; it does not need another button inside it to perform the same action. [2]

The shared Button component supplied styling only; the rendered element was still a summary. The destinations inside the panel were already present in the initial HTML, rather than being created by a script after opening.

This provided a basic control even without JavaScript. After disabling page scripts and reloading the about page, I focused the mobile navigation summary and pressed Enter, then Space. Enter opened the navigation; Space collapsed it. The custom closing effect and extra event handling were missing, but the links were not.

Native opening and closing does not supply every dismissal method. Outside clicks and the site’s Escape behavior still depended on scripts. A working details element did not guarantee those behaviors too.

Escape does more than hide the panel

With scripts enabled, I pressed Tab after opening the navigation. Focus moved to the first notes link. Pressing Escape then collapsed the panel and returned focus to its controlling summary.

That restoration matters. Simply hiding the panel while leaving focus on an internal link can make it unclear where the next keyboard action will start. The site’s Escape handler explicitly called focus() on the control instead of expecting the browser to work it out after the animation.

An outside click followed a different path: it collapsed the mobile navigation without forcibly returning focus to the control. A reader who has clicked outside the panel should not have the Escape focus strategy applied indiscriminately to that action.

There was also no handler that automatically closed the navigation as soon as Tab moved focus outside it. The W3C example includes that behavior, but this site was not an item-by-item implementation of the example. [1] Referring to a pattern does not establish that every interaction in it exists.

The closing animation is an enhancement

In the normal motion mode, the closing script added is-closing so the panel could fade out and shift slightly before the details element’s open state was removed. The code set a 200 ms closing timer. That was a configured duration, not a measured interaction delay.

With reduced motion enabled, the closing branch closed the panel directly, and CSS also removed the opening animation. I emulated that preference in the browser and operated the control, confirming that the panel closed without leaving a closing-state class behind.

These paths can be recorded separately:

Interaction	Basic responsibility	Site-specific handling
Activate summary	Expand the native disclosure	Play the panel’s entrance effect
Press Escape within navigation	Script handles closing	Return focus to summary
Click outside navigation	Script handles closing	Do not force focus back to the control
Disable page scripts	Keep native opening, closing, and links	Omit the custom events and transitions above

On page exit, the code also cleared the closing timer and temporary class. That was a resource-cleanup arrangement in the source, not evidence that every history-navigation scenario had been checked.

Start with one complete interaction path

When checking mobile navigation, I start with the full sequence: find the control, open it, move focus to a link, close it, and check focus. I do not stop at whether the icon changes. I then test outside clicks, reduced motion, and disabled scripts separately to see what each layer provides.

These local Edge observations used a narrow viewport of 390 CSS px with actual keyboard and mouse input. They were not tests on a physical phone or with a screen reader, nor a cross-browser acceptance check. Readability and panel size still need to be assessed in the actual reading context.

Native details: exclusive opening, keyboard operation, and a no-JavaScript fallback covers expanding work-experience content. Mobile navigation adds the question of destinations and focus. Even after choosing the right native control, each reason for closing still needs a clear explanation.

Sources

[1] https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/examples/disclosure-navigation — W3C APG: Example Disclosure Navigation Menu [2] https://html.spec.whatwg.org/multipage/interactive-elements.html — WHATWG HTML: Interactive elements