Put your mouse in a drawer for a minute and try to reach your own Services page. On a lot of WordPress sites, that is where the trouble starts: the top-level items take focus, but the dropdown under “Services” never opens, so the pages inside it simply do not exist for anyone using a keyboard.
An accessible navigation menu is one that people can open, move through and close with a keyboard, a screen reader, a phone or a zoomed-in browser, not just with a hovering mouse. This post covers the menu itself: dropdowns, hover-only behavior, the mobile toggle, the aria-expanded attribute and big mega menus. It is written for owners and managers, so the code is kept short.
Why the menu deserves its own attention
The main menu appears on every page. A barrier in the content of one blog post affects one blog post; a barrier in the header affects the whole site at once. If a visitor cannot reach “Book an appointment” or “Contact” through the menu, they may have no other route there at all.
Menus are also among the most scripted parts of a theme, and that script is where keyboard support is either built in or forgotten.
A keyboard test for your menu
You do not need any tools for this, only the Tab key and a few minutes. Open your homepage in a desktop browser and follow these steps.
- Click once in the address bar and keep tapping Tab until the first menu item lights up. Each item should show a visible outline or highlight as you go.
- When you land on an item that has a dropdown, press Enter or Space. Does the submenu open? Some menus also open when the parent item simply receives focus, which is fine.
- Keep pressing Tab. Focus should move into the submenu items in order, then on to the next top-level item.
- Open a submenu and press Escape. A well-built menu closes the panel and leaves focus on the parent item.
- Press Shift+Tab to move backward. Check that nothing jumps to an odd spot or vanishes.
- Now zoom the browser to 200 percent and repeat. Many themes switch to the mobile menu at that zoom level, which gives you a second menu to test.
Write down what you saw for each step. “Services dropdown never opens” or “focus disappears after About” is exactly the kind of note a developer can act on.
The hover-only dropdown
The failure to look for first is a submenu that only appears on mouse hover. It is usually pure CSS :hover. The parent link still gets focus, so the menu looks fine in a quick check, but the child pages stay hidden. That conflicts with WCAG 2.1.1 Keyboard, which expects every function to work from a keyboard.
There are two honest ways to fix it. The first is to make the submenu also appear when anything inside the menu item has focus, using :focus-within alongside :hover. That is a quick improvement, but it means every submenu link becomes a Tab stop, which gets tiring on large menus. The second, better for most business sites, is a real disclosure button next to the parent link that opens and closes the submenu. That is how most accessible dropdown menu patterns work.
Hover menus that close too fast
Mouse users have problems too. If the submenu vanishes the moment the pointer leaves the parent by a few pixels, people with tremors or anyone using a trackpad carefully will struggle. A short delay before closing helps, and so does a submenu that starts right at the edge of the parent item, with no gap for the pointer to fall through. People who zoom in a lot meet the same issue, because the panel may be partly off screen.
Disclosure buttons and aria-expanded
A screen reader user needs to know two things about a dropdown: that it is something that opens, and whether it is open right now. The usual pattern is a button element with an aria-expanded attribute that switches between “false” and “true” as the panel opens and closes. A screen reader then says something like “Services, button, collapsed”, and after a press, “expanded”.
<li>
<a href="/services/">Services</a>
<button aria-expanded="false" aria-controls="sub-services">
<span class="screen-reader-text">Show Services submenu</span>
</button>
<ul id="sub-services" hidden> ... </ul>
</li>Notice what is not there. There is no role="menu" or role="menuitem". Those roles are meant for application-style menus, like the File menu in a desktop program, and they tell screen readers to expect arrow-key navigation. Website navigation is a list of links, and adding menu roles without the full keyboard model behind them usually makes things worse. If a theme or plugin adds those roles, ask whether it also supports arrow keys, Home, End and Escape the way the pattern requires. If not, plain links in a list inside a nav element are the safer choice.
What “button, button, button” tells you
If you turn on a screen reader and hear a string of unnamed buttons in your header, the toggles have no accessible name. Each one needs text a screen reader can read, either visible or hidden for sighted users, that says what it opens. This falls under WCAG 4.1.2 Name, Role, Value.
The mobile menu toggle
The hamburger button is small, and there is a lot that can go wrong with it. An accessible navigation menu on mobile needs a toggle that passes all of these:
- It is a real button. A
divor a bare icon with a click handler cannot be reached with Tab. - It has a name. “Menu” or “Main menu”, not silence.
- It reports its state with
aria-expanded. - Focus moves sensibly. After opening, the next Tab press should go into the menu, not to content hidden behind the panel.
- It can be closed with a visible close control and with Escape if the panel covers the page.
- Its tap area is generous. Under 2.5.8 Target Size (Minimum), the hamburger should be no smaller than 24 by 24 CSS pixels unless spacing around it makes up the difference.
Full-screen mobile menus behave a lot like dialogs. If the panel covers the page, focus should stay inside it until it is closed, and focus should return to the toggle afterward. If you are still choosing how your mobile menu works at all, our guide to the WordPress mobile menu options covers the setup side.
Mega menus
A mega menu is a large panel, often with columns, headings, images and sometimes a search box. They can be accessible, but they multiply the problems above. The common issues:
- Column headings that are just bold text, so screen reader users hear one long list of links with no grouping.
- Thirty or forty links that all become Tab stops whenever the panel opens on focus.
- Panels that open on hover and cover the content the user was reading, with no way to dismiss them.
A good mega menu opens on a button press, uses real headings or labeled groups inside the panel, and closes with Escape. On a small business site, it is also worth asking whether you need one. A shorter menu with a clear Services page that lists everything is often easier for every visitor.
Smaller details that still matter
The current page
Many themes highlight the current page in the menu with color only. An aria-current="page" attribute on that link lets screen readers announce it too. Standard WordPress menus often output it already, but custom headers built in a page builder may not, so it is worth checking in the page source.
Focus that you can see
Some themes remove the focus outline in the header because it looked untidy in a design mockup. Without it, a keyboard user has no idea where they are. Our post on visible focus styles and WCAG explains what good focus styling looks like.
Sticky headers
A sticky header can cover the very link that has focus as someone tabs down the page. WCAG 2.2 added 2.4.11 Focus Not Obscured (Minimum) for this. Adding scroll padding at the top of the page usually fixes it.
Repeated menus
Keyboard users have to Tab through the whole header on every page unless there is a way to jump past it. That is the job of a skip to content link, which is a separate fix from the menu itself but often done at the same time.
Getting an accessible navigation menu in WordPress
Where the fix goes depends on where the menu comes from:
- Classic theme menus are built from the menus screen and rendered by the theme. Keyboard behavior lives in the theme’s JavaScript and CSS, so fixes belong in a child theme so updates do not wipe them.
- Block themes use the Navigation block, which handles submenus and the mobile overlay in core. It is generally a reasonable starting point, but custom styling can still hide focus or shrink targets, so test it after you style it.
- Page builder headers in Elementor or Divi use the builder’s own menu widget or module. Check its output with the keyboard test above; the fixes there are covered under our Elementor and Divi accessibility fixes.
- Mega menu plugins each have their own behavior. Test a plugin’s live demo with a keyboard before you install it.
If you are adding a dropdown for the first time, set it up the normal way first (see how to add a dropdown menu in WordPress), then run the keyboard test before you call it done. Our walkthrough on making a WordPress website accessible shows where the menu sits in the order of work, and the rest of the topic is gathered in our website accessibility hub.
Frequently asked questions
Do dropdown menus fail WCAG by themselves?
No. Dropdowns are fine when keyboard and screen reader users can open them, move through the links and close them again. The problem is the way many are built, opening only on mouse hover, with no button to toggle them and no indication of whether the panel is open or closed.
Should the parent menu item be a link or a button?
If the parent leads to a real page, keep it as a link and add a separate small button that opens the submenu. If the parent is only a label with no page behind it, make it a button that toggles the submenu. Avoid a link with a dummy href that does nothing when pressed.
Is the WordPress Navigation block accessible?
It is a sensible base. The block uses buttons for submenus and the mobile overlay and is designed to work with a keyboard. Theme styling and custom CSS can still undo that, for example by hiding focus outlines or making the toggle too small, so test it with a keyboard after styling.
How many items should a navigation menu have?
There is no WCAG number. Shorter menus are easier for everyone, especially keyboard and screen reader users who move through every item one at a time. If your menu has many items, group them under a few clear parents and make sure each group opens and closes cleanly.
Menus are one part of the WordPress work we do: testing the header, theme and plugins together, fixing what blocks people and checking it again after changes. If you want that done on your site, see our WordPress accessibility services.
Next in this series: WordPress Accessibility Checker: Reading the Results
