Features Accessible mobile menu
FREE FEATUREAn accessible mobile menu for WordPress
A hamburger menu that works with a keyboard and assistive technology: a real button, labelled submenus, focus that stays in the open menu, and Escape to close. It's in the free plugin.
What the menu does for you
These work out of the box. You don't need to configure anything.
- A real menu buttonA <button> with an accessible name, aria-controls and aria-expanded, so screen readers announce whether the menu is open.
- Labelled submenu buttonsEach parent item gets its own button, such as "Toggle submenu of Services", beside the link, so the link still works.
- Focus stays in the open menuTab and Shift+Tab move through the menu and loop back, instead of wandering into the page behind it.
- Escape to closeEscape closes the menu and puts focus back on the menu button, where the visitor started.
- Visible focusA clear outline shows which item is focused when someone uses a keyboard, without adding outlines for mouse users.
- Respects reduced motionVisitors who turn on "reduce motion" on their device get the menu without animations.
- A labelled nav landmarkThe menu sits in a <nav> named after your menu, so screen reader users can jump straight to it.
How we tested it
October 2026, Responsive Menu 4.7.4 free and Pro, Chrome at phone width (390px), keyboard only, plus axe-core 4.10 on the open menu.
| Test | What happened | Result |
|---|---|---|
| Open the menu with Enter | Menu opens, focus moves into it, the button reports aria-expanded="true" | Pass |
| Tab through the open menu | Links, submenu buttons and the search box in order, then back to the menu button. Focus never reaches the page behind | Pass |
| Shift+Tab | Moves backwards through the same items | Pass |
| Open a submenu from the keyboard | "Toggle submenu of Services" button opens it, aria-expanded="true", Tab moves into the submenu | Pass |
| Press Escape | Menu closes, aria-expanded="false", focus returns to the menu button | Pass |
| Visible focus | 3px outline on the focused item, shown for keyboard use only | Pass |
| axe-core, free plugin | 0 issues across 20 WCAG 2.0–2.2 A/AA rules (button names, link names, lists, nested controls, target size, contrast) | Pass |
| axe-core, Pro | 0 issues across 21 rules on a standard menu | Pass |
| axe-core, Pro with a mega menu | 0 issues across 21 rules. The mega menu list structure issue is fixed; the fix ships in the next Pro release | Pass |
| Screen readers (VoiceOver, TalkBack, NVDA) | Not tested yet. Planned, and we will publish the results here | Planned |
Automated tools catch only some accessibility problems, which is why we test with a keyboard too and are adding screen reader testing.
What's still up to you
You choose the colours and the words, so check these when you set up your menu. Our mobile menu accessibility checklist has the details.
- Colour contrastMenu text needs at least 4.5:1 against its background (WCAG AA). Check your colours with a contrast checker.
- Tap target sizeKeep menu items at least 24×24 pixels (WCAG 2.2 AA); 44×44 is more comfortable on a phone.
- Clear link textUse menu labels that make sense on their own, like "Pricing", not "Click here".
- A button labelIf you hide the button text, keep an accessible name such as "Menu" for screen readers.
Get it in three steps
- 1
Install or update
Install Responsive Menu from Plugins → Add New, or update to 4.7.4 or later. The accessibility support is on by default.
- 2
Check your colours
In the menu editor, make sure text and background colours have enough contrast.
- 3
Try it with a keyboard
On a narrow browser window, Tab to the menu button, press Enter, Tab through the menu and press Escape.
Accessibility questions
Is this in the free plugin?
Yes. The keyboard and screen reader support is in the free plugin from version 4.7.4 (October 2026), and in Responsive Menu Pro 4.7.4.
Does it make my website WCAG compliant?
No plugin can do that on its own. Responsive Menu makes the menu itself work with keyboards and assistive technology. The rest of your site, and the colours and text you choose for the menu, still need checking.
Does it work with screen readers?
The menu uses the standard HTML and ARIA that screen readers rely on: a real button with aria-expanded, labelled submenu buttons and a labelled nav landmark. We have tested it with a keyboard and with axe-core. Testing with VoiceOver, TalkBack and NVDA is planned, and we will publish the results here.
Does it respect reduced motion?
Yes. If a visitor has turned on "reduce motion" on their device, the menu and button open and close without animation.
I updated to 4.7.4 and my custom CSS broke. Why?
To make submenus keyboard-accessible, the submenu toggle is now a button beside the link instead of inside it, and the menu is wrapped in a nav element. CSS that targets .rmp-menu-item-link .rmp-menu-subarrow should now target .rmp-menu-subarrow.
Is this legal advice for the European Accessibility Act?
No. The EAA has applied to many online shops and services in the EU since 28 June 2025, and websites are usually measured against WCAG 2.1 AA. An accessible menu is one part of that. Check your obligations with a specialist.
Read more: How to edit and customize your WordPress mobile menu · All features