Ensuring Keyboard Operation for Dropdowns and Mobile Menus

How can dropdowns and mobile menus be fully keyboard operable?

Dropdowns and mobile menus must follow their actual navigation pattern and be fully accessible without a pointing device. When opening, switching, and closing, the visible state, keyboard logic, and focus position remain synchronized, ensuring that neither the background nor the parent target becomes a dead end.

Predictable focus return

Diagnostic case: "Hover dependency"

A mobile menu opens as a side panel, but the focus remains on the hidden menu button, and the tab key moves to the background. Upon opening, the focus moves to the menu heading, remains in the panel during use, and returns to the menu button after pressing Escape; desktop sublinks remain normal links in a logical tab order.

Hover dependency

• Hover dependency Sub-items only appear when hovering the mouse over them and are not accessible via focus or activation.

• Focus trap in the mobile panel The focus moves behind the opened menu or remains on an invisible element after closing.

• Foreign keyboard layout – Arrow keys and Escape behave as in an application menu, even though standard web navigation is expected.

Appropriate menu layout

• Appropriate menu layout – Navigation, action menu, and selection fields are not mixed up but retain the keyboard behavior of their actual purpose.

• Accessible opener and content – Triggers, entries, sub-levels, and close remain fully operable without a pointing device in a logical order.

• Predictable focus return – Open and close deliberately set focus without losing it, throwing it back to the top of the page, or skipping content.

Accessible opener and content

1. For desktop dropdowns and mobile panels, document the purpose, states, tab order, and expected keystrokes before implementation.

2. Open, navigate, exit, and re-enter all menu levels exclusively via keyboard.

3. Synchronously check focus position, aria-expanded view, and visibility during opening, closing, viewport changes, and dynamic content updates.

How "Operating menus entirely via keyboard" relates to other topics.

Differentiatedly test for contrast problems instead of blindly working through threshold values. Answers the next practical question: How to differentiate and test for contrast problems instead of just working through threshold values?

Combine infinite scroll with crawlable page states. continues this line of thought with another question: How can an infinite-scroll menu remain fully accessible without scrolling events?

If you want to practically implement "operating menus entirely via keyboard," you can refer to Robust Website Systems This resource focuses on "Keyboard, Focus, and Dynamic Interaction" and "Appropriate Menu Pattern."

Conclusion: Operating Menus Entirely via Keyboard

A menu is keyboard accessible if its pattern is appropriate for its purpose and each state change carries the focus. Additional keyboard logic is only helpful if it is implemented consistently and documented.

Sources and Further Information

The primary sources define the technical framework for "operating menus entirely via keyboard."

• Understanding Keyboard — W3C WAIWCAG 2.1.1 requires that all functions be operable via a keyboard interface without specific timing.

• Disclosure Navigation Menu Example — W3C ARIA APGThis APG example documents focus order, Enter, Space, and Escape behavior, as well as aria-expanded behavior for navigation with collapsible sections.

• Disclosure Pattern — W3C ARIA APGThis pattern defines roles, states, and mandatory keyboard interactions for controls that show and hide content.