For years, one of the most common reasons people installed Responsive Menu was that their theme’s mobile menu was cramped, broken or impossible to style. WordPress 7.0, released in May 2026, changed part of that story. Block themes can now design their own mobile menu overlay in the Site Editor, without a plugin.
We build Responsive Menu, so we had an obvious question: does the built-in menu do the job well enough that people don’t need ours? To answer it, we ran core’s mobile menu through the same accessibility tests we publish for our own plugin, side by side with Responsive Menu on its default settings.
The short version: WordPress’s default mobile menu passed every test. A customised overlay built from one of core’s own patterns didn’t. And our plugin passed every keyboard test but failed on its own default colours. Here’s the detail, and where we think each option fits.
What changed in WordPress 7
The Navigation block has had an overlay menu for a long time. Its Overlay Menu setting (Mobile, Always or Off) collapses the menu behind a button on small screens. What was missing was control over how that overlay looks.
WordPress 7.0 makes the overlay a template part you can design in the Site Editor, and ships new patterns to start from, including one called “Overlay with centered navigation”. On a block theme, you can now style the open mobile menu with the same tools you use for the rest of the site.
How we tested
We set up a fresh sandbox on 12 October 2026 and kept everything identical apart from the menu:
- WordPress 7.1.3 with the default Twenty Twenty-Five theme (version 1.5).
- The same eight-item menu in every case, with one parent item holding a three-item submenu and a search field.
- A phone-width browser window (390 pixels), operated by keyboard only.
- axe-core 4.10.3, an automated accessibility checker, run on the open menu against WCAG 2.0 to 2.2 A and AA rules.
We compared three setups:
- Core default: Twenty Twenty-Five’s header Navigation block with the overlay set to Mobile and no customisation.
- Core custom overlay: the same block using an overlay built from core’s “Overlay with centered navigation” pattern.
- Responsive Menu: the free plugin, version 4.7.4, on the setup wizard’s default settings with nothing restyled.
Each setup went through the nine checks in the accessibility test protocol we publish for Responsive Menu.
The results
| Check | Core default overlay | Core custom overlay (centered pattern) | Responsive Menu 4.7.4 (defaults) |
|---|---|---|---|
| Opens with Enter or Space, focus moves in, open state announced | Pass | Pass | Pass |
| Tab and Shift+Tab stay inside the open menu | Pass | Pass | Pass |
| Submenu works from the keyboard, with a labelled toggle | Pass (submenus are always expanded) | Fail | Pass |
| Escape closes the menu and returns focus to the button | Pass | Pass | Pass |
| Visible focus indicator on every item | Pass | Fail | Pass |
| Respects reduced motion | Pass | Pass | Pass |
| Labelled navigation landmark | Pass | Pass | Pass |
| axe-core on the open menu | Pass (0 violations) | Fail (1 violation) | Fail on a page that is in the menu, pass on other pages |
| Closed menu hidden from assistive technology | Pass | Pass | Pass |
| Score | 9/9 | 6/9 | 8/9 on pages in the menu, 9/9 elsewhere |
Core’s default overlay: it passes
The default mobile menu in WordPress 7.1 opens from the keyboard, keeps focus inside, closes with Escape and puts focus back on the button. It shows a clear focus ring, drops its animation for visitors who ask for reduced motion, and axe-core found nothing wrong with it.
The only difference from our checklist is wording. Our protocol asks for aria-expanded on the menu button. Core uses the modal dialog pattern instead, marking the open menu as a dialog. That’s a valid way to build it and not an accessibility failure. If you’re on a block theme and use the default overlay, you have an accessible mobile menu out of the box.
The custom overlay we built: three problems
Customisation is where it went wrong. Using core’s “Overlay with centered navigation” pattern, the open submenu was drawn on top of the next three menu items. When a keyboard user tabbed to those items, the focused item was completely hidden, which fails WCAG 2.4.11 (Focus Not Obscured). The submenu button was stuck in its open state and did nothing when pressed, and at 10×10 pixels it was far below a comfortable tap size. axe-core reported a serious target-size violation.
This is one pattern, on one theme, in our test, so it isn’t a verdict on every custom overlay. The underlying behaviour is already tracked by WordPress contributors in Gutenberg issue #53308 (submenu items covering main items), #81589 (click-to-open submenus in the overlay) and #44346 (letting overlay submenus collapse). The practical lesson is simple: if you customise the overlay, test it with a keyboard before you ship it.
Responsive Menu: keyboard checks pass, default colours don’t
Responsive Menu passed every keyboard step. Submenus open and close with a labelled button that announces its state, focus stays in the menu, and Escape returns you to where you started.
It failed on colour. On default settings, the menu item for the page you’re on is white text on a light green background (#6fda44). That’s a contrast ratio of 1.78:1, well below the 4.5:1 WCAG AA requires for text, and axe-core flags it as serious on any page that is in the menu. On a page that isn’t in the menu there’s no highlighted item, and axe-core found no violations. The open menu button, a white X on the same green, is also 1.78:1, under the 3:1 minimum for interface graphics. axe-core doesn’t test that, so it would never show up in an automated scan.
We found two smaller gaps compared with core too. Our menu button comes before the theme’s “Skip to content” link in the tab order. And while our menu is open, a screen reader can still move into the page behind it, which core prevents by marking its overlay as a modal dialog.
If you use Responsive Menu today, open the menu editor and change two colours: the current item background and the active menu button background. Pick values with at least 4.5:1 contrast against white, or switch the text to a dark colour.
When the built-in menu is enough
If your site uses a block theme, your menu is short, and you’re happy with the default overlay or a light restyle, use what WordPress gives you. It’s accessible, it’s maintained by core contributors, and it’s one less plugin to keep updated. We’d rather say that plainly than pretend otherwise.
If you haven’t built the menu itself yet, our guide to adding a menu in WordPress walks through the three ways to do it.
Where Responsive Menu still matters
There are still plenty of sites where the built-in overlay isn’t available or isn’t the right fit:
- Classic themes and page-builder headers. The overlay is part of the Navigation block. If your header is built by a classic theme or a page builder, WordPress 7’s overlay doesn’t apply to it. Responsive Menu replaces the mobile menu on any theme.
- Long menus with submenus. In core’s overlay, every submenu is shown fully expanded and there’s no toggle to collapse it, which is still an open request (#44346). On a menu with several sections, that makes for a lot of scrolling. Responsive Menu gives each parent item its own labelled toggle.
- Designing without editing templates. Responsive Menu has its own editor with a live phone preview, pre-built themes, and export and import, so a menu built on a staging site can be moved to production or reused on a client’s site.
- Different items for different visitors. The free plugin can hide individual menu items from logged-in users, from guests, or from everyone outside chosen user roles.
- Headers that do more. Responsive Menu Pro adds a fixed mobile header bar, desktop and mega menus, a WooCommerce mini cart and 26 button animations. Responsive Menu Pro plans start at $49 a year for one site, and the menu keeps working if you stop renewing.
If you’re also weighing plugins other than ours, our roundup of the best free WordPress menu plugins compares the main options and what each is best at.
What we’re taking from this
Core’s default mobile menu is now good, and that’s good for the web. It also raises the bar for us. A plugin that replaces the built-in menu has to be at least as accessible on its default settings, and on colour contrast ours isn’t yet. Our published test result holds on pages that aren’t in the menu, and we’d rather tell you that here than have you find it in an audit.
Whatever you use, a two-minute check catches most of what we found:
- Narrow your browser to phone width.
- Press Tab until you reach the menu button, then press Enter.
- Tab through every item, including any open submenu. Can you always see where focus is?
- Press Escape. Did the menu close and put you back on the button?
- Run the open menu through a contrast checker, including the highlighted current page.