Add a Navigation Heading block. #33351
Conversation
tellthemachines
added
Needs Accessibility Feedback
tellthemachines
requested review from
ajitbohra,
nerrad,
ntwb,
spacedmonkey and
TimothyBJacobs
as code owners
tellthemachines
requested review from
talldan,
draganescu,
jasmussen,
getdave and
gwwar
|
Size Change: +3.41 kB (0%) Total Size: 1.07 MB
ℹ️ View Unchanged
|
|
👋🏻 why can't we use a heading block? Or just a paragraph? |
There's some more context in the discussion starting here, but tl,dr: there are too many differences between what we need here (a block exactly like Navigation Link but without the link) and either of those blocks. |
|
There's a conversation going over on Slack about the best element to use here, considering screen reader accessibility:
Looking at classic menu patterns in default themes, most of them expect the parent element that opens the dropdown to be a link; dropdowns open on hover or focus so screen readers are only aware that they are entering a nested list, the fact that it's housed in a dropdown isn't relevant. (Twenty Twenty One is an exception, with a dedicated button to open the submenu dropdown.) The problem is that it's possible to set a menu item without a URL in classic menus, although it's a bit of a hack (it requires creating a custom link and then deleting its URL), and if that happens, the element displayed is an anchor tag without a href. The screen reader ignores it altogether, but it's still possible to tab to the submenu even if the anchor itself isn't focusable. This isn't great, but it's not clear what a more semantic alternative might be. |
|
This is a really popular pattern online, but most sites seem to prefer to open a submenu on a click rather than a hover. Some markup I've observed in the wild. These open on click and clicking only opens a submenu, the item doesn't act as a link to anywhere: These open on hover and the same as above, even though the first one has a link href, clicking it just opens a submenu 🤔: This one, the H&M site, opens on hover, but the item can also be clicked as a link. I couldn't figure out a way to open the submenu using the keyboard only, though there is an 'accessibility trigger' button element in there as well: So while this is a limited subset, link or button seem the most popular options. Some related issues:
I wonder if the idea of a submenu block could be explored. The submenu block could contain options for whether the submenu opens on click or hover. I feel like the following might work:
Introducing a submenu block would require a bit of work in the navigation editor, but I don't think that should be considered a reason not to do it. |
|
This pull request was reviewed today during the Accessibility Team's meeting.
|
@Ryokuhi I think this is possible now, the navigation block has a frontend script for the responsive menu, so it should be possible to build on top of that: |
|
Thanks for the feedback, everyone! We have two aspects to consider here: the front end UI (whether it opens on click, hover, etc.), and the editor UI (whether to open submenus directly from Link/Heading blocks, or to build a dedicated Submenu block). Front End UIBearing in mind the accessibility feedback that the submenu shouldn't open on focus, I think our best bet is to follow a similar pattern to Twenty Twenty One, where submenus open on both hover and click. Then later on we can implement #18395 to make hover optional. The difference in this implementation is that, unlike classic menus, where top-level items without a link still render as anchor tags, we can make these non-link items buttons instead. So, if we have a top level item that is a link, the markup will be something like: Whereas if the top-level item isn't a link, it will be: I'm wondering if the button content needs explicit text instructions for screen readers, or if the Editor UIShould we build a Submenu block? I see two main advantages:
If we do go this route, we have to think about how to structure the Submenu block internally. @talldan are there any obvious advantages to either of these approaches for the Navigation editor? Also, I'm wondering how the Link block deprecation will work. Can we auto-transform existing Link blocks with submenus into Submenu blocks? An important question to consider is: would we ever want to use a Submenu block outside of the Navigation? As a child of Navigation, we'll want to limit its inner blocks to only Links for now, and then when we go on to building mega menus, we'll need some logic to render groups of links as lists, such as we currently have for the Navigation block. As we'll need a bunch of logic custom to Navigation, I'm not sure how viable it will be to make it a general use block. I'm going to put this PR on hold and investigate what a Submenu block might look like, and see if we can answer some of these questions. |
If the editor UI is cleaner, it'd be beneficial, but other than that there would be no real difference. The code that maps menu items to blocks and blocks to menu items would need to be updated to handle submenu blocks. Some feature may also need to be removed in the nav editor.
Yeah, this is an interesting one. It could be that the nav link block still supports submenus for back compat, but it's not something exposed in the UI. An option to convert to a submenu block could be shown as well. It might also be possible at some point in the future to remove submenus from the nav link block entirely, given the block is plugin only. It might be interesting to find out if there have been other similar use cases in the past. I'm sure some blocks have been renamed, but can't recall which ones. |
|
Very cool work. At first and due to the name of the block, I instinctually thought of this as a "subheading" type item, to help build mega menus, like "Highlights", "Clothing" or "Accessories" in this draft mockup:
However I understand that the goal at least for now is to create a menu item that doesn't link, so that you can create submenus whose parent item doesn't also link anywhere, is that correct? Here's what I see:
To be clear, that's cool. As I expanded on in your "Dropdown Menu" PR here, a dropdown menu that opens on click in a wholly unambiguous way can be very useful and perhaps even more usable than hover-only dropdown menus. See also #18395.
💯
Fixing this might also fix #33091. See also #33849 (comment). |
|
Closing this in favour of #33775. |
Description
Fixes #18866. It should be possible to add a heading to a submenu list that is not itself a link.
Some questions to consider:
index.phpfile. E.g. there are identical versions in everything but name of the...build_css_colorsand...build_css_font_sizesfunctions across 4 files. Might be worth extracting some of these into a common file, but where should it live?TODO:
How has this been tested?
Tested in the browser. Add an empty Navigation block to a post or page, then add a Navigation Heading block inside. Verify a submenu can be created from it and Navigation Links added as children. Also verify that Navigation Heading can only be added at the top level.
Screenshots
Types of changes
New feature (non-breaking change which adds functionality)
Checklist:
*.native.jsfiles for terms that need renaming or removal).