Table of Contents
A keyboard accessible menu should let people open, browse, and close your site’s navigation without touching a mouse. That sounds basic, yet many menus fail because they rely on hover, hide focus outlines, or use clickable div elements instead of real controls. The fix usually isn’t a large JavaScript library. It starts with sensible HTML, visible focus styles, and a small amount of carefully tested behavior.
This guide focuses on the common desktop and mobile pattern: a navigation button opens a panel, the panel contains links or submenus, and users can close it with the Escape key. You’ll also see where CSS-only solutions stop being practical and how to test the finished menu with the tools already built into your browser.
What a keyboard accessible menu must do
A usable menu needs to communicate three things clearly: where focus is, whether the menu is open, and what happens when someone presses a key. A visitor using Tab should reach the menu button. Pressing Enter or Space should open it. The button should expose its state, and the links inside should receive focus in a sensible order.
When the menu opens, the first useful item should be easy to reach. For a compact navigation panel, that usually means moving focus to the first link. When the panel closes, focus should return to the button that opened it. Without that return step, a keyboard user may land somewhere unexpected on the page.
For a simple menu, the expected behavior looks like this:
- Tab reaches the menu button and then the visible links.
- Enter or Space opens the menu when the button is focused.
- Escape closes the menu and returns focus to the button.
- Clicking outside the panel closes it, if that behavior won’t cause trouble.
- Focus never disappears against the background.
- Screen readers can tell users that the button controls a menu and whether it is expanded.
Don’t confuse a visual dropdown with a menu in the accessibility sense. A row of site links is often just navigation, and a disclosure button may be the right pattern. The word “menu” has a specific meaning in accessibility guidance, particularly for application-style controls. For ordinary website navigation, a button that reveals links is often simpler and easier to use.
Start with the right HTML
HTML gives you useful keyboard behavior for free when you choose the right element. Use a button for an action that opens or closes a panel. Use an anchor for a link that takes the visitor to another URL. Don’t turn a div into a button with a click handler and a role attribute unless you have a strong reason and understand the missing behavior you must rebuild.
A basic structure might look like this:
<button
class=”menu-toggle”
aria-expanded=”false”
aria-controls=”site-nav”>
Menu
</button>
<nav id=”site-nav” class=”site-nav” hidden>
<ul>
<li><a href=”/about/”>About</a></li>
<li><a href=”/services/”>Services</a></li>
<li><a href=”/contact/”>Contact</a></li>
</ul>
</nav>
aria-expanded tells assistive technology the current state. It must change from false to true when the panel opens. aria-controls connects the button to the element it controls. The matching ID matters.
The hidden attribute is useful because it removes the closed panel from the page’s normal focus order. Don’t hide the panel with opacity alone. An element with opacity: 0 may still be reachable by keyboard, leaving users tabbing through invisible links.
Make focus visible in a keyboard accessible menu
Focus indicators are not decoration. They tell keyboard users where they are. Browser defaults are often adequate, but site-wide CSS can accidentally remove them with rules such as outline: none. If that rule exists, replace it with a clear focus treatment rather than deleting it.
.menu-toggle:focus-visible,
.site-nav a:focus-visible {
outline: 3px solid #155eef;
outline-offset: 3px;
}
:focus-visible usually shows the indicator when keyboard input needs it, without adding a strong ring after every mouse click. Test it on the real background, not just on a blank page. A pale outline on a white header may technically exist while remaining difficult to see.
Keep the focus style stable when the menu changes. Avoid a design in which the button shifts position after opening, since that can make the focus indicator appear to jump. If the panel pushes content downward, that is often easier to understand than a floating panel that covers the page.
Use JavaScript for state, not for basic links
The script should manage a small state change: open the panel, update the button, move focus, and close the panel when appropriate. It shouldn’t replace ordinary links or intercept every keyboard event.
const toggle = document.querySelector(‘.menu-toggle’);
const nav = document.querySelector(‘#site-nav’);
const firstLink = nav.querySelector(‘a’);
function closeMenu() {
toggle.setAttribute(‘aria-expanded’, ‘false’);
nav.hidden = true;
toggle.focus();
}
function openMenu() {
toggle.setAttribute(‘aria-expanded’, ‘true’);
nav.hidden = false;
firstLink.focus();
}
toggle.addEventListener(‘click’, () => {
const isOpen = toggle.getAttribute(‘aria-expanded’) === ‘true’;
if (isOpen) {
closeMenu();
} else {
openMenu();
}
});
document.addEventListener(‘keydown’, (event) => {
if (event.key === ‘Escape’ &&
toggle.getAttribute(‘aria-expanded’) === ‘true’) {
closeMenu();
}
});
This example assumes one menu button. If your site has several menus, select each component and attach behavior inside a loop. Avoid using one global ID or one global “open” class for every menu. Each button should control its own panel.
Moving focus to the first link is a sensible choice for a menu that opens as a panel. Some teams leave focus on the button and let the user press Tab. Either approach can work, but the behavior should be predictable and documented in your testing. A menu that opens while focus silently remains elsewhere feels broken.
How CSS should hide and show the panel
The HTML hidden attribute handles the closed state, while CSS controls the visible design. You can use the attribute as a selector:
.site-nav[hidden] {
display: none;
}
.site-nav {
display: block;
padding: 1rem;
background: white;
border: 1px solid #d0d5dd;
}
For a small screen menu, a normal block panel is often the least troublesome option. It stays in the document flow, remains readable at high zoom, and doesn’t cover the entire page. A fixed drawer can work too, but it introduces more work. You’ll need to manage the drawer’s position, prevent background content from receiving focus, and decide how focus behaves when the drawer closes.
Be careful with animation. A closing transition can leave links focusable for a moment after the panel looks closed. If you animate the panel, coordinate the visual transition with its accessibility state. A short fade is rarely worth a keyboard bug.
Handling dropdowns inside the main navigation
Nested navigation needs a second decision. If “Products” goes to a page and also opens a submenu, don’t force one control to perform two unrelated actions. Use a normal link for the page and a separate button for the submenu.
<li class=”has-submenu”>
<a href=”/products/”>Products</a>
<button
aria-expanded=”false”
aria-controls=”products-submenu”
aria-label=”Show Products submenu”>
<span aria-hidden=”true”>⌄</span>
</button>
<ul id=”products-submenu” hidden>
<li><a href=”/products/widgets/”>Widgets</a></li>
<li><a href=”/products/tools/”>Tools</a></li>
</ul>
</li>
Hover-only dropdowns exclude keyboard users and are awkward on touchscreens. You can keep hover as a convenience for pointer users, but the button must provide the same access. Don’t make the submenu appear only when a mouse passes over its parent.
Nested menus also need a clear close rule. Escape should close the open submenu before closing the entire navigation. That requires a little more state tracking than the basic example, but the principle is simple: close the most recent layer first, then return focus to its controlling button.
Common mistakes with keyboard accessible menus
Using hover as the only trigger
Hover doesn’t exist for keyboard users, and it behaves poorly on phones. It also creates accidental openings when someone moves a pointer across a crowded header. Make the button or link usable on its own.
Removing the outline
A polished visual design is not an excuse to hide focus. Replace the browser ring if needed, but keep a high-contrast alternative. Test with a keyboard after every header redesign.
Leaving hidden links in the tab order
Absolute positioning, opacity, and off-screen text can hide a panel visually without removing its links from keyboard access. The hidden attribute or a carefully managed display state avoids that trap.
Closing the menu on every document click
Outside-click behavior is useful, but careless event handling can close the menu when someone clicks inside it. Check whether the click target is outside the button and panel before closing. Also make sure a user can still activate a link without the document handler interrupting it.
Forgetting small screens and zoom
Test at 200 percent zoom and at a narrow viewport. Text may wrap, buttons may grow taller, and a fixed header may cover the panel. A good keyboard accessible menu should remain usable when the browser zooms or the user increases text size.
Test the menu without special software
Start with the keyboard. Reload the page, press Tab, and watch where focus goes. Open the panel with Enter, then repeat the test with Space. Tab through every link, press Escape, and confirm that focus returns to the button. Try closing the panel by clicking outside it, then reopen it and use the browser’s Back button after following a link.
Next, use a screen reader if one is available. On Windows, Narrator or NVDA can expose problems that visual testing misses. On Apple devices, VoiceOver is built into macOS and iOS. Listen for the button’s name, expanded state, and the names of links inside the panel.
Browser developer tools can help with the rest. Inspect the button and check that aria-expanded changes. Confirm that the panel’s hidden state matches the visual state. The accessibility tree in Chromium-based browsers can show how controls are being announced.
Test with a mouse, touch, a keyboard, zoom, and a narrow screen. Each input method reveals a different failure. If the menu works only in the developer’s preferred setup, it isn’t finished.
When a library or framework makes sense
A small menu rarely needs a third-party package. Plain HTML, CSS, and JavaScript keep the behavior easy to inspect and reduce the number of hidden assumptions. That is especially helpful on a marketing site where the navigation is simple.
A component library may be a good choice for a large application with nested navigation, dialogs, focus trapping, animation, and state shared across multiple layouts. Before adopting one, inspect its actual keyboard behavior. A component can look accessible in a demo and still fail when placed inside your header.
Framework code also needs careful server-rendered output. The page should begin in a usable state before JavaScript finishes loading. A closed mobile panel with a real button and real links is a better starting point than an empty header that only becomes functional after hydration.
If your site has broader browser inconsistencies, the guide on why websites look different in every browser can help you separate layout bugs from accessibility bugs. They often appear together, but they need different fixes.
Final Verdict
Build a keyboard accessible menu with native buttons, real links, visible focus, accurate expanded state, and a reliable Escape-key path. Keep the first version simple, test it with several input methods, and add focus management only where the interaction truly needs it. A small, predictable menu is better than a flashy header that leaves people guessing.