Mega Menus Eat Keyboards: The Escape Key Test

Tab into the navigation, and the mega menu opens. Tab again, and you are inside a panel with forty links. Tab again, and you are still inside it. The Escape key does nothing. The only way out is to tab through all forty links or to click somewhere with a mouse you do not have. That is a keyboard trap, and it fails WCAG 2.1.2, No Keyboard Trap, which has been Level A since WCAG 2.0.

The trap

Mega menus trap keyboards in three ways, and most menus do at least two of them. First, the panel opens on hover and never opens on focus, so a keyboard user cannot get in at all, or gets in by accident and cannot get out. Second, the panel opens on focus and stays open, with no Escape key handler, so the only exit is tabbing through every link inside it. Third, the panel moves focus into itself when it opens and never returns focus to the trigger when it closes, so the user loses their place on the page entirely. All three are the same failure wearing different clothes: the menu was built for a pointer and the keyboard was an afterthought.

The test that finds it is simple. Tab to the menu trigger, press Enter, and count how many tabs it takes to get out of the panel. Then press Escape and see what happens. If Escape does nothing, or if closing the panel leaves focus somewhere the user did not come from, the menu fails. The date picker that eats keyboards is the same failure in a different component, and it shows up in the same audits for the same reason: a component built for a pointer, tested with a pointer.

The pattern that passes

The WAI-ARIA practices guide names the pattern, and it has four parts. The trigger is a button with aria-expanded, true when the panel is open and false when it is closed. The panel opens on Enter or Space, and on focus if the design calls for it, but it always opens on keyboard activation, never on hover alone. Escape closes the panel and returns focus to the trigger, every time, without exception. And arrow keys move between the top-level items, while Tab moves out of the menu entirely, because Tab is for leaving, not for navigating inside a component.

Two details trip teams that have the first three right. The panel must not steal focus when it opens on hover for a pointer user, because focus theft breaks the keyboard flow for the person who was tabbing elsewhere. And the panel must close when focus leaves it, not only on Escape, because a keyboard user who tabs past the last item expects the menu to be gone when they look back. A menu that stays open behind the shopper is a menu that will obscure the focused element two screens later, which is a 2.4.11 failure on top of the trap.

The 60-second test

You need a keyboard and the site's navigation, nothing else. Tab to the first menu item, open it, press Escape, and confirm focus is back on the trigger. Then open it again, tab through the panel, and confirm you can leave without tabbing through every link. Then open it on hover with a mouse and confirm the keyboard user is not affected. If any of those three fails, the menu traps keyboards, and the fix is the pattern above, not a redesign: a button, an aria-expanded attribute, an Escape handler, and focus returned to the trigger. For the dialog version of the same trap, see the modal focus trap test, and for the checkout version, the keyboard-only checkout test.

Frequently asked questions

Is a mega menu that opens on hover a failure on its own?

Not by itself. Hover is a pointer behavior. The failure is a menu that cannot be opened, used, and closed from the keyboard, or one that traps focus inside it. A hover menu with a proper keyboard pattern passes.

Does Escape have to close the menu?

Yes, for keyboard users. Escape is the expected exit for a disclosure pattern, and the WAI-ARIA practices guide names it directly. Closing on Escape and returning focus to the trigger is the behavior keyboard users rely on.

What is the difference between a trap and a bad menu?

A trap is specific: focus enters a component and cannot leave except by tabbing through everything, or cannot leave at all. A menu that is merely awkward, with too many links or a confusing order, is a usability problem. A menu that holds focus hostage is a 2.1.2 failure.

Should Tab move inside the menu or leave it?

Tab leaves it. Arrow keys move between top-level items and inside the panel. Tab is for moving to the next thing on the page, not for navigating inside a component, and a menu that consumes every Tab press is the trap.