Navigation block: Allow parent item to be clickable when using "on click" option

[kathrynwp]

What problem does this address?

When adding a sub-menu to a Navigation block via the Site Editor, the parent menu item is not clickable, which means that users can never reach this page through the menu.

When I reported this behaviour in Trac I thought this was a bug, but apparently this is the intended behaviour:

When "Open on click" is selected, the parent menu item becomes a button that only expands the submenu.

To Replicate

1. Activate a block theme like Twenty Twenty-Three
2. At Appearance > Editor, add a navigation block to the Header template part
3. Add a sub-menu to one of the top-level menu items
4. In the Navigation block's Submenu settings on the right, select "Open on click"
5. View the site on the front end and try to click the parent item above the sub-menu

Result

The top-level item that has the sub-menu under it is no no longer clickable, so it can never be reached. Clicking the parent item only opens the sub-menu.

Expected

You should be able to reach the parent item above a sub-menu.

What is your proposed solution?

Perhaps trigger the sub-menu only by clicking on the arrow icon, not the parent menu item itself. This would allow visitors to access the parent menu page.

User report

Reported in: https://wordpress.org/support/topic/stop-mouse-over-on-submenu-item/

Screencast

onclick-bug-tt3.mov

[annezazu]

Would be curious to hear from @WordPress/gutenberg-design on this one.

[jameskoster]

It's tricky for me to see how you can have both behaviors. We can't rely on the icon because it is optional. I suppose we could force the icon when Open on click is enabled, but then you couldn't have Open to click without an icon which seems like a downgrade.

You should be able to reach the parent item above a sub-menu.

One way to achieve this would be to add the parent item to the submenu as well.

I do agree that it's a bit misleading to have a URL input for a menu item that doesn't link anywhere. Perhaps those settings should be hidden when Open in click is enabled.

[kathrynwp]

Thanks for your input, @jameskoster

We can't rely on the icon because it is optional.

At first I'd thought the same as you, but when testing again yesterday I noticed that the icon seems to be required when selecting "on click." As you can see in the below screenshot the "Show arrow" toggle is greyed out and cannot be toggled off when "on click" is active. Let me know if you see something different on your end!

[jasmussen]

There are a lot of intricate details going into how this was decided to work:

When the navigation is opened on hover, the dropdown arrow exists as a separate tab-stop and affordance for opening and closing the menu. This is useful so you can tab through a huge navigation menu without having to tab through every submenu item on the way, requiring an explicit invocation:

In comparison, if you toggle off the separate dropdown indicator, you have to tab through every submenu rather than explicitly opening each. This works well for small menus, but less well for mega menus:

When set to open on click, it makes the parent item inert, intentionally, to keep the behavior uniform between keyboard and mouse. It becomes a button with no destination, and because that make the markup different from the surroundings (button instead of a), the dropdown arrow is locked in place to differentiate the behaviors:

I like to think we can do better as far as styling goes, letting you choose dropdown arrows and such. That's a todo on the docket.

We did also ponder whether to add an option to "auto duplicate" the top level menu item as the first item inside the menu. But since you don't always want to do that, we decided to make this be an editorial decision you can make, to include or not to include. This is also to acknowledge the fact that there are many site designs that rely on the top level item as a categorization tool rather than a destination on your own.

In that light, and outside of novel ideas, it doesn't seem like there's a lot we can meaningfully do here without taking a hit to many of the core features and accessibility affordances.

[kathrynwp]

@jasmussen Hey there! Whatever is decided, the status quo is really not good, IMO, as site owners may not even notice that their top-level item isn't clickable when choosing the "on click" option, so their users will never be able to reach the page. People's assumptions when creating a menu is that all pages in their menu will be reachable, since that is normally the case. So what's being done here goes against the expected menu behaviour.

Perhaps have a peek at Twenty Fifteen, which has a default "on click" menu behaviour, and yet the top-level item is still clickable. https://twentyfifteendemo.wordpress.com/

[jasmussen]

Thanks for the clarification. You helped me find what I think is a regression in the nav block that I missed when testing the last time. TwentyFifteen's behavior is — more or less — what you are supposed to get when you have menus set to open on hover, and the dropdown arrow visible:

However that's not the case:

What's supposed to happen is that you can open the submenu on hover, but you can also click the separate chevron arrow to explicitly open/close. CC: @tellthemachines I know you worked on this a while back, do you recall the correct behavior here? I'm happy to work on a patch if need be.

That aside, it sounds like you'd like an additional option, which is to untoggle "open on hover", so that you can only access the submenus by clicking the separate arrow. Does that sounds right? If yes, I think this is something we could consider, but that it might be worth giving it low priority since there's so much stabilization to still be done for the block itself (the just discovered regression is one example).

As far as the clarity of the on-click behavior, good note. We can add contextual help text. So the default state could say this:

When you then toggle on click, the help text could clarify top level items become unlinked:

The verbiage above is just an example and could use love.

[tellthemachines]

@jasmussen the current is the correct behaviour:

• by default the options are set to open on hover and show the dropdown arrow, with the arrow being a button that allows opening on click for keyboard users.
• when open on click is set, the whole element (text and dropdown arrow) becomes a button.
• when open on hover is set and the dropdown arrow is hidden, keyboard users have to tab through the whole submenu in order to reach the next top-level item.
• it's possible to make the top-level element not clickable by removing the link from it even if the Nav is not set to open on click.

The open on click functionality was added to provide better accessibility support; there was a long back and forth on how it should work in #33775 and the current implementation was vetted by the accessibility team.

I agree with adding some helper text to better explain the options, but given that open on click is not enabled by default, I don't think we should change its actual behaviour in any way.

[jasmussen]

Thanks for looking! What I'm stumbling on right now is the open on hover and show arrow combo, where the dropdown arrow is also clickable. It appears to be clickable in the current implementation, and the DOM changes to indicate aria-opened, but there's no counterpart visual effect:

This seems like a bug, no? But I wanted to confirm.

[tellthemachines]

This seems like a bug, no? But I wanted to confirm.

I think it's happening because the submenu stays open as long as you hover over it, though clicking on the arrow should open and close it. If you tab to the arrow instead of using the mouse, it behaves as expected.

What would be the desired behaviour here? Should clicking the arrow always open/close whether the element is being hovered or not? Another possibility would be to change the pointer to make it seem as if the arrow isn't clickable for mouse users, which would keep consistency with the hover behaviour.

[jasmussen]

That's a good question, I guess it's working as intended — if I click the button to "pin it open", it does stay open when I mouse out. Not super intuitive, which is why I thought it was initially a bug, but I guess it is technically the right approach.