Video: Accessibility walkthrough of navigation menu block designs

Yesterday, @lukepettway was kind enough to sit down with me and walk through my and @melchoyce‘s initial ideas for a menu block design, in order to catch any areas that could be problematic from an accessibility standpoint.

Video recording and transcript

#gutenberg, #menus

Proposal: Navigation menu block design

After collecting feedback and discussing areas of the problem individually, @melchoyce and I have circled back to a proposed combined direction for the navigation menu block.

What problem are we trying to solve?

Building navigation menus for a website is a fragmented process that’s difficult to understand and visualise. It relies on a pre-existing understanding of the model WordPress uses to organise menus and doesn’t map to users’ understanding of how navigation menus should work. There are multiple different ways to create a menu (Customizer, Appearance > Menus, widgets) that all offer slightly different experiences, increasing confusion. Creating a link to certain parts of the site often requires manual work.


The core principles followed here:

  1. Any interactions that are required by a majority (over 50%) of users exist in the block interface itself.
  2. Advanced controls are moved to the block inspector in order to progressively reveal complexity.
  3. Switching between advanced and basic interactions is made simpler by links.
  4. The editing state of the block itself should mimic as closely as possible the front-end output.
  5. Use technology and data to make smart decisions for the user so as to limit the number of decisions they need to make.
  6. Users should be able to create pages from the menu interface if these pages don’t already exist on their site.

There’s a great deal of complexity that goes into a navigation menu (multiple levels of nesting, mega menus, social links, etc), but the majority of users require a very simple menu—a collection of links to the main sections of their site.

After a productive discussion in the #design meeting of 13 February, Mel and I decided to create slightly different experiences for core interactions and advanced interactions. For the majority of users, everything they’ll need to build a simple menu will be available in the block interface itself. Smart defaults help users get up and running as quickly as possible, so they may only need to make a few small adjustments to the out-of-the-box configuration of the block. For advanced users who want fine-grained control of complicated menus, a suite of advanced tools is available in the Inspector.

You can see how these interactions are classified in this diagram:

Diagram of core and advanced interactions.
Core interactions are blue, advanced interactions are pink.

Proposed Solution

The core (in-block) UX flow.
The core (in-block) UX flow.

When you first add the navigation menu block, Gutenberg will use some underlying code-magic to try to automatically generate a menu for you, based on a number of different factors including any pre-existing saved menus, where you’re inserting the menu on your site, and what content you already have set up. 

What your default menu might look like.

Once you’ve created a menu, you can delete items quickly using the delete on your keyboard, or you can delete them using the traditional block settings ellipsis menu.

To rearrange elements in your menu, select the menu item you’d like to move and either use the drag handle or the “move left” and “move right” buttons to shift it. Advanced options and hierarchy management exists in the inspector. 

Navigation item settings.

One level of hierarchy is visible in the block itself. By default, sub-menus are hidden in the block interface, but they can be toggled on and off using the drop-down icon. For more complex hierarchical structures, an inspector panel opens and allows for legacy-style reordering and nesting of navigation items. 

A sub-menu displayed.

To add an item to your menu, start typing or use the “+” button. The placement of the “+” button shifts depending on which item is currently selected, so you don’t need to add new items at the end and then move them up.

Adding a new item to a navigation menu.

Adding a new menu item pulls up a search interface, similar to adding an inline link or a button. The search returns all relevant content across your site, regardless of what content type it may be. Icons are used to provide additional context as to what type of content is being returned. From here, you can also opt to create a new page or enter the advanced mode to browse your content and bulk-add items.

If you’d like to dive more deeply into the finer points of discussion, there are a series of Github issues for discussing different parts of the interaction:

There’s also a Figma prototype that you can play with or leave comments on directly. Note that it’s under construction, so not everything works perfectly yet.

Get involved

At this stage, broad feedback would be extremely useful. 

  1. Overall, does this feel like a sensible direction? 
  2. Is there another approach that might work better?
  3. What’s the most elegant way to handle nested menus?
  4. How can advanced reordering be made as simple and user-friendly as possible?

If you have feedback on a specific element or interaction, it’s best to leave that in Github or Figma. If you’d like to remix or improve this work, please feel free to create a new page in Figma, or duplicate the whole document itself, and share here in the comments.

Next steps

These designs are a work in progress and will be iterated on based on your feedback as well as usability testing results. 

@lukepettaway and I will be meeting up later this week to do a walkthrough of the proposal and identify any potential accessibility problems in this design.

Mel and I will be working on a plan for usability testing of this prototype. If you’d like to be involved or sit in, please join us in #research at 18:00 UTC tomorrow, Tuesday 26 February for a text chat. More details will be posted here once those details have been hammered out. If you’re interested in helping with usability testing, there will be lots of opportunities to get involved!

#gutenberg, #menus

User Testing for Customizer Menus

Following are testing tasks/questions, my initial walkthrough of the plugin at this stage, and some feedback with blockers separated from nitpicks. I will post testing videos in the comments as they come in.

Please reply to each comment with the biggest takeaway you learn from the video if you watch any of them. Thank you!


Intro: You have a blog about travel, and you would like to setup a custom menu for your blog.

  1. Log in with username ******* and password *******
  2. Go to Appearance > Customize and then click on Menus.
  3. Add a new menu named “Main Menu.”
  4. Add all of the pages already saved on the site to the menu.
  5. Reverse the order of the menu items.
  6. Set the “Main Menu” as the primary menu so it shows in the live preview.
  7. Add the “Travel” category to the menu.
  8. Move “Travel” so it is a child of the first item in the list.
  9. Add a link to Twitter and make it a submenu item next to Travel.
  10. Move Travel and Twitter from the first item so they are submenu items under the About page. Save changes.
  11. Create a new menu for social media with at least one social media link in it and add it to the sidebar.
  12. There is a way to use advanced menu settings to enable descriptions for menu items. Try to find it and add a description for the “About” page.


  • Would you recommend this feature to a friend who needs to create menus on their website?
  • Have you used WordPress before? If yes, have you used the Menus feature inside the WordPress dashboard before?

Continue reading

#customizer, #menus, #usability-testing-2

Proposal: Making the relationship between pages and menus clearer [Update]

A common issue I encountered when I freelanced was a disconnect clients experienced when customizing menus. They would add a page, it would show up in the menu, they would delete the page, it wouldn’t disappear from the menu. My hypothesis is that this page/menu relationship can be clarified and improved by merging the Pages and Appearance > Menus section into one, then testing configurations of this thoroughly.

See also mockups by myself and Shaun Andrews.

Update: Please see new mockups based on feedback.


  • How does this scale to hundreds of pages/menu items?
  • How can it be made clearer that you can also add links or categories to a menu?
  • If we are able to merge, how do we best communicate the change in the admin-sidebar, a pointer?
  • What happens if a theme doesn’t use menus at all?
  • Are there other ways to improve the relationship between pages & menus, without merging the two sections into one?


Pages arguably do more than any other feature to make WordPress viable as a CMS, especially when combined with a static frontpage and a customized menu. Having to visit three disparate admin locations to set this up, however, is not necessarily intuitive. While the scope of this project is to simply merge the two and see if that tests better, if this succeeds it would give us a bunch of future opportunities for iteration, such as:

  • reducing duplicate functionality (no need for a duplicate page-list on the Menus section)
  • revisit the “Page Attributes” box, perhaps subsume it by integrating parent/sort order features directly into the menu management
  • integrate the “static frontpage” feature directly in the page-management section

Please share your ideas, questions and concerns, and let’s discuss whether this is worth moving forward with.

#3-8, #menus