You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Three options for navigation block overlay toggle #79082
The button to toggle navigation overlays inside a navigation block can only be displayed as a word "MENU" or an icon (hamburg or sandwich). This way users can only pick one option but option with the best of both worlds is impossible to achieve without custom code.
The new "Navigation overlay close" block is showing the need to do this.
What is your proposed solution?
Rework the settings for the toggle to allow:
only icon
only word
both
Based on what option is picked the further details like what icon can be shown or hidden.
The components to build the options are available see the "Navigation overlay close" block.
I second this. 🙂 This is actually a real accessibility issue in disguise. The hamburger icon alone is notoriously bad for usability, many users, especially older people or less tech-savvy visitors, still don't recognize what three stacked lines mean. The word "MENU" alone has no visual anchor. Having both together is widely considered the most accessible and usable pattern.
Thanks for opening this. I'd like to add a +1, and also mention one small thing I noticed in the editor.
Icon / Text / Both
I agree with the three options. One thing that might add to the case: the closing side already has exactly these three.
Selecting the Navigation Overlay Close block gives a Display mode control with Icon / Text / Both:
The opening side, however, only offers a single Show icon button on/off:
So the two halves of the same overlay are configured in different ways. Bringing the toggle button in line with the close button would make them consistent, and it looks like PR #79146 is already heading in that direction.
From a usability point of view, I'd also rather show the menu label and the button together. The label tells people what the menu is, and the icon gives it a visual anchor.
Here is where it actually gets awkward in practice. Today, the only way to get that combination is to build the button yourself in custom code — and a button built that way can't make use of the overlay settings that core provides. So the moment you decide you want both, you give up the built-in overlay mechanism along with it. Having the three options would remove that trade-off.
One more thing that might be worth considering alongside it
When both are shown, it would be useful to be able to choose which side the text sits on — before or after the icon. Depending on the design, one order sits better than the other.
I had a look at PR #79146, and as far as I can tell it adds the overlayOpenButtonDisplay attribute and the three-way Display Mode control, but no control over the order. It might feel more natural to fold this into the same group of settings than to chase it separately later.
A separate, smaller thing about the editor
In the editor, clicking the overlay toggle button switches the canvas to editing the Navigation Overlay template part. Inside it, clicking the ✕ (Navigation Overlay Close) doesn't bring you back to where you came from — it just selects the block. The only way back seems to be the < Back button in the top bar.
2026-09-09.214942.mp4
It isn't broken as such, but the first time I ran into it, it felt like a dead end. It might be worth considering whether the ✕ in the editor could return to the previous view. I may well be missing something here, and if this is better tracked separately, I'm happy to open a new issue for it.
Environment
WordPress 7.1 (no Gutenberg plugin)
Theme: Twenty Twenty-Five 1.5
Edge 152 / Windows 11
Local site running on PHP's built-in server with SQLite (WordPress Studio), so please treat the environment as non-standard.
Activity
Bovelett commentedon Jun 10, 2026
I second this. 🙂 This is actually a real accessibility issue in disguise. The hamburger icon alone is notoriously bad for usability, many users, especially older people or less tech-savvy visitors, still don't recognize what three stacked lines mean. The word "MENU" alone has no visual anchor. Having both together is widely considered the most accessible and usable pattern.
CC @amberhinds
YourMark commentedon Jun 10, 2026
Third! Yes please. And also it could do with some filters to programmatically change this to offer alternatives.
armandovias commentedon Jun 10, 2026
I also agree!
hagege commentedon Jun 10, 2026
I agree: the third option: both.
prasadkarmalkar commentedon Jun 12, 2026
Here is a POC I have created for this feature. Let me know if this looks good or if any changes are needed. Will raise a PR for it.
te.1.mov
369work commentedon Sep 9, 2026
Thanks for opening this. I'd like to add a +1, and also mention one small thing I noticed in the editor.
Icon / Text / Both
I agree with the three options. One thing that might add to the case: the closing side already has exactly these three.
Selecting the Navigation Overlay Close block gives a Display mode control with Icon / Text / Both:
The opening side, however, only offers a single Show icon button on/off:
So the two halves of the same overlay are configured in different ways. Bringing the toggle button in line with the close button would make them consistent, and it looks like PR #79146 is already heading in that direction.
From a usability point of view, I'd also rather show the menu label and the button together. The label tells people what the menu is, and the icon gives it a visual anchor.
Here is where it actually gets awkward in practice. Today, the only way to get that combination is to build the button yourself in custom code — and a button built that way can't make use of the overlay settings that core provides. So the moment you decide you want both, you give up the built-in overlay mechanism along with it. Having the three options would remove that trade-off.
One more thing that might be worth considering alongside it
When both are shown, it would be useful to be able to choose which side the text sits on — before or after the icon. Depending on the design, one order sits better than the other.
I had a look at PR #79146, and as far as I can tell it adds the
overlayOpenButtonDisplayattribute and the three-way Display Mode control, but no control over the order. It might feel more natural to fold this into the same group of settings than to chase it separately later.A separate, smaller thing about the editor
In the editor, clicking the overlay toggle button switches the canvas to editing the Navigation Overlay template part. Inside it, clicking the ✕ (Navigation Overlay Close) doesn't bring you back to where you came from — it just selects the block. The only way back seems to be the < Back button in the top bar.
2026-09-09.214942.mp4
It isn't broken as such, but the first time I ran into it, it felt like a dead end. It might be worth considering whether the ✕ in the editor could return to the previous view. I may well be missing something here, and if this is better tracked separately, I'm happy to open a new issue for it.
Environment
joedolson commentedon Sep 9, 2026
This is definitely an accessibility issue; not being able to choose the most accessible option is a significant bug. Fully support fixing this.
Note that we're already using this same model in other contexts, like the buttons in lightboxes.
TheRadicalDreamer commentedon Sep 10, 2026
can you choose to where the text is displayed when the option BOTH is enabled?