When a Website Menu Closes, Where Does the Keyboard Go?

Try this on your website: open the small-screen menu with the keyboard, move to a link, then press Escape. The links disappear. Where will the next Tab press take you?

That last question is easy to miss when reviewing a menu by clicking around. Someone using a keyboard needs a clear place to continue after the panel closes. If the active control disappears with it, the person may have to work out where they are all over again.

This lesson comes from our September–October 2026 navigation work on the Dash Digital site, revisited in November. The current menu code moves keyboard focus to the first link when it opens, returns it to the menu button on Escape, and lets people tab onward into the page. Those small decisions deserve their own review alongside the way the menu looks.

Follow the active control through the whole change

Keyboard focus is the control that will receive the next keyboard action. A visible outline or other clear indicator helps someone see which button or link they are about to use. It has to remain useful as the page changes.

For a menu that shows and hides ordinary website links, write down three moments: opening it, leaving it, and closing it without choosing a destination. Each needs a deliberate answer.

On our site, opening the menu moves focus into the links. Escape closes it and brings focus back to the button that opened it. Moving focus outside the navigation also closes the panel, allowing the person to keep going through the page.

These are choices for this navigation pattern. A dialog that requires someone to finish or cancel a task needs a different review. Treating every panel as the same kind of control can create confusing keyboard behavior.

The W3C disclosure navigation example is a useful reference: it shows ordinary links with Tab navigation and an Escape action that returns focus to the controlling button. Its guidance also explains why typical website navigation does not need the more complex keyboard behavior of an application-style menu. Use that reference to understand the pattern, then test your own implementation.

Check what happens when the layout changes

A menu can close because the visitor presses a button, follows a link, or changes the window size. Consider a person who opens the mobile layout on a narrow desktop window, tabs into the links, then widens the window.

The mobile controls may disappear as the desktop navigation appears. If focus was inside the disappearing section, choose a sensible visible destination. Our code intends to use the home link in that situation. Another site's layout may call for a different choice.

A browser check on our live site while preparing this article found a gap: the panel closed when the window widened, but focus ended up on the page itself instead of that visible link. That remains a follow-up to resolve. The check showed why reviewing the intended rule in the code needs to be paired with using the menu.

There is a tradeoff here. Moving focus can help someone recover when their active control disappears, but moving it unnecessarily can interrupt what they were doing. Keep the movement tied to a clear reason, and check that the destination is visible and useful.

You can describe the expected behavior without writing code. “After Escape, the menu button is active again” gives a builder and a reviewer something concrete to check.

Make one keyboard journey part of the review

Set aside the pointer and walk through the menu with Tab, Shift+Tab, Enter, and Escape. Watch the focus indicator as carefully as you watch the open panel.

Check that you can reach the menu button, open the links, move through them, close the panel, and continue into the page. Try going backward too. Repeat while the narrow layout is active, and change the window width with a menu link focused.

Write down where the journey becomes unclear. A report such as “Escape closes the menu, but I cannot see which control is active” is much easier to investigate than “the menu feels broken.”

This focused check is one part of accessibility review. It does not establish how every screen reader, device, or interaction will behave. Include people using relevant assistive technology when checking the wider experience.

If your menu leaves people unsure where to go next, send us the page and the keyboard steps that lose your place. We can start the conversation over email and identify the interaction that needs a closer look.