Navigation: Next steps for supporting non-links in Navigation block and screen

[noisysocks]

A complementary feature to Full Site Editing is that we want to allow users to add blocks to their navigation menus and widget areas even if they are not using a block-based theme. Exploration of how to support non-link blocks in a navigation menu began in #22656 and was further discussed in #22096 and #23915.

In this issue, I'll attempt to provide a complete overview of this feature and go over the next steps for building it. This supersedes the above linked issues.

Overview

Navigation block

The Navigation block allows non-link blocks to be added alongside Link blocks. To begin, we can support useful blocks like Search, Social Icons, Image, Separator and Spacer. In the medium term, we can look at supporting nearly all non-layout blocks as well as blocks for building complex mega menus such as Pages (#23689) and Submenu (#23745 (comment)).

It is a "tailored group" block (#23207 (comment)). Unlike Group, it allows the user to customise whether to show these blocks horizontally, vertically, spaced evenly, etc. Also, unlike Group, it uses (<nav> and <ul>) markup to denote the special semantic meaning of its content.

Navigation is a static block. Features such as background colour, foreground colour, and whether or not to display submenu indicators should be implemented using cascading CSS or block context. The Link block should be mostly static but with dynamic PHP code that adds the current-menu-item class when the user is currently on the page represented by that link.

Children of the Navigation block are automatically wrapped in a <li> element using the API described in #23915 (comment). In the medium term, a more flexible API (#23915 (comment)) should be used. This more flexible API would allow us to support blocks like Pages and Submenu inside Navigation while still retaining semantic list markup.

Navigation screen

The Navigation screen displays a single Navigation block. Each item in the Navigation is saved to the database as a menu item CPT. By default, only Link blocks may be added to the Navigation block inside the Navigation screen. This ensures that wp_nav_menu() works as it always has done and that existing themes do not need to be changed. It also means that plugins which use menu items for their functionality will continue to work.

Themes may opt in to allowing more blocks to be inserted the Navigation screen by declaring add_theme_support( 'block-navigation' ).

Non-link blocks that the user adds to the Navigation screen are then saved to the database as a menu item with type set to 'html'. Alternatively, the type can be 'blocks' which mirrors how block widgets are stored per #24267.

Opting in causes wp_nav_menu() to output a complete Navigation block using render_block() instead of Nav_Menu_Walker. This significantly changes the outputted markup. By declaring add_theme_support( 'block-navigation' ), a theme author is indicating that they have tested their theme with the Navigation block markup. Customisations such as mega menus will work as they do when using the Navigation block in a block-based theme. Note that, in a typical case, opting in allows a theme author to delete CSS because wp-block-library already contains Navigation block styling.

If a user switches from a theme that supports block navigation to one that doesn't, non-link blocks will no longer render on the frontend. This prevents the site's navigation from appearing visually broken as it is not common that a theme's existing styling will correctly style block markup. Existing non-link blocks in the Navigation screen will continue to display but are marked as invalid so that the user is able to replace them with Link blocks.

If a user disables the block-based Navigation screen using a plugin, non-link blocks will, no longer render on the frontend. Again, this prevents a site's navigation from appearing visually broken. Existing non-link blocks in the Navigation screen will display in nav-menus.php as a HTML menu item so that the user is able to replace them with a menu item.

Next steps

I'll be working through the list below in the coming weeks. Ping me if you'd like to help out with any of the items!

• Make Navigation wrap its children with <li> using the API proposed in Navigation: Non-link blocks should be wrapped in a <li> #23915 (comment). InnerBlocks: introduce prop to specify render callback for each block. #24232
• Make Navigation block static. Navigation: Make Navigation a static block #24371
• Make Link block mostly static. Navigation: Make Navigation a static block #24371
• Update styling of Navigation block so that it is a flexbox container that supports non-link children. Navigation: Try adding Links block #24644 Navigation: Make Search block look nice when added to a Navigation #24643
• Make wp_nav_menu() render entire Navigation block using render_block() when theme opts in to block navigation. This gist demonstrates the approach. Navigation screen: Add opt-in Navigation block rendering #24503
• Make Navigation screen hide non-link blocks when theme has not opted in to block navigation. Navigation screen: Add opt-in Navigation block rendering #24503
• Hide non-link blocks from frontend when theme has not opted in to block navigation. Navigation screen: Add opt-in Navigation block rendering #24503
• Mark non-link blocks in the Navigations screen as invalid when theme has not opted in to block navigation. Navigation: Improve how invalid non-link blocks appear in Navigation screen #24640
• Make HTML menu items display the HTML when displayed in nav-menus.php. Navigation screen: Add opt-in Navigation block rendering #24503

[afercia]

Having read this issue and previous discussions on #22656, #22096, and #23915 I still fail to understand why a navigation menu should contain extraneous content like a Search form and potentially any other type of non-link blocks.

The Navigation block allows non-link blocks to be added alongside Link blocks. To begin, we can support useful blocks like Search, Social Icons, Image, Separator and Spacer. In the medium term, we can look at supporting nearly all non-layout blocks as well as blocks for building complex mega menus

I can understand additional text (e.g. a paragraph) meant to be used as description of a menu item. That would need to be correctly associated with the link but I guess it can work.

Other extraneous elements are arguably appropriate for a navigation menu.

HTML 5.2 specification:
https://www.w3.org/TR/html52/sections.html#the-nav-element

The nav element represents a section of a page that links to other pages or to parts within the page: a section with navigation links.

Please also read the notes there and see the examples. If an unordered list is used for the menu items, the list is supposed to exclusively contain links. A search form would break the expected semantics for all software that read the page (Google included) and break the users expectation.

An "All Pages" block would make sense as it's a set of links, as long as the HTML is valid and semantic. Other blocks seem completely inappropriate for a navigation menu and I'd tend to think the list of allowed blocks should be very limited.

Will propose the accessibility team to discuss this issue in the next meeting.

Other useful references:

Landmarks usage:
https://www.w3.org/TR/wai-aria-practices/examples/landmarks/

Native HTML sectioning elements that define ARIA landmarks by default:
https://www.w3.org/TR/wai-aria-practices/examples/landmarks/HTML5.html

Search landmark usage:
https://www.w3.org/TR/wai-aria-practices/examples/landmarks/search.html

[noisysocks]

Hey @afercia! I want to get this right, so thanks for the feedback and for the resources. Please do bring this up at the next accessibility meeting as I'd love to get the team's perspective on best practices here. In particular, what markup would you expect to have for a navigation menu like this?

[talldan]

There was a pretty lengthy discussion about this issue on slack (https://wordpress.slack.com/archives/C02RQBWTW/p1596613710043800).

In particular the idea of wrapping all inner blocks in li elements.

I have some concerns here because it's not really the idiomatic way to build navigation based on what's out there on the web. Most sites seem to use a ul just to represent a list of links, and put other content either at the root of the nav or outside of a nav element.

Though I do realise at the same time there's a great deal of inconsistency.

You've got sites that tend to put all kinds of elements inside nav:

• https://www.w3.org/WAI/ (this seems closest to what you're proposing @noisysocks, as they put everything, including a search form inside of list items within a nav).
• https://www.theguardian.com/

And sites that just use navigation for links and put other elements outside the nav:

• https://www.bbc.com/
• https://developer.mozilla.org/

Some that don't even use an ul:

• https://github.com/

Beyond that W3 site I haven't been able to find many others that wrap everything in li.

[enriquesanchez]

It's worth noting that a navigation block does not necessarily need to translate 1:1 to the HTML nav element. Navigation links can just be a part of the whole.

That said, the nav element does allow for flow content, according to the WHATWG HTML spec. This can be seen in the W3C's example, where a search form is nested inside a list in a nav element.

<nav class="metanav" aria-label="Meta &amp; Search" lang="en">
    <ul>
      <li><a href="/WAI/about/participating/">Get Involved</a></li>
      <li><a href="/WAI/about/">About W3C WAI</a></li>
      <li>
        <form action="/WAI/search/" role="search">
          <div>
            <label for="header-search">
              <span class="visuallyhidden">Search:</span>
              <input id="header-search" type="search" name="q" placeholder="Search" aria-label="Search">
            </label>
            <button class="button button-icon button-nobg button-noborder"><span><svg focusable="false" aria-label="Submit Search" class="icon-search "><use xlink:href="/WAI/assets/images/icons.svg#icon-search"></use></svg></span></button>
          </div>
        </form>
      </li>
    </ul>
</nav>

[afercia]

https://www.w3.org/WAI/ (this seems closest to what you're proposing @noisysocks, as they put everything, including a search form inside of list items within a nav).

What the W3C does on their website is not normative. WCAG and the HTML specification are normative.

That said, the nav element does allow for flow content, according to the WHATWG HTML spec. T

Same for the HTML 5.2 spec I linked above but that applies to the <nav> element, meaning it can contain children that are flow content. I also recommended to read the notes and examples here:

In cases where the content of a nav element represents a list of items, use list markup to aid understanding and navigation.

Which excludes that the list within a <nav> element can contain content other than the links. The rationale is pretty clear: a list represents a set of related navigational items (the links). Using other content within the list is unexpected as it would be extraneous to the logical grouping.

For completeness:

Not all groups of links on a page need to be in a nav element — the element is primarily intended for sections that consist of major navigation blocks. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases; while a nav element can be used in such cases, it is usually unnecessary.

[joedolson]

Hi all!

The accessibility team discussed this extensively, and there are a few key points that we want to make sure the expanded navigation block ensures:

1. Links must be contained in lists of items, using the same general mark-up used by existing navigation menus.
2. Lists of links should only contain links. (This may need to vary to allow some structural references, e.g. headings and decorative icons for mega menu support, depending on what our research into mega menu structures indicates is ideal)
3. Other content that's navigation-relevant needs to be semantically identified, but should not be within the list of links. E.g., a list of social media links should possibly be a separate nav element; a search input could be within the same nav element, but not within the list of links. (Other elements could be within a ul/li structure, just not the same one.)

The important characteristic is that the <nav> element should ideally represent a single body of content that's being navigated that can be represented by a single label.

We would like to actively pursue developing a semantically sound and accessible version of a mega menu; this will require some research and exploration to determine exactly how that should be structured.

Some references for mega menus:

Adobe Accessibility: https://adobe-accessibility.github.io/Accessible-Mega-Menu/
Deque University: https://dequeuniversity.com/library/aria/menus/megamenu
Level Access: https://www.levelaccess.com/challenges-mega-menus-standard-menus-make-accessible/
Nielsen Norman Group: https://www.nngroup.com/articles/mega-menus-work-well/

One thing I want to note, is that we probably need to be extra careful with use of vocabulary in this issue, as we have three separate concepts that all use the same basic terminology. Can we agree to use the following terms and definitions?

1. nav element - the HTML defined semantic element
2. nav menu - the list of navigation links inside a navigation block
3. nav block - the Gutenberg block used to structure navigation

[tellthemachines]

From the accessibility feedback above, it looks like we're back to this proposal for nav structure (I'm not quite sure why we deviated from it in the first place, as semantically it makes the most sense) so, with that in mind, I'll implement #23689 as an unordered list.

[draganescu]

Is this overview relevant anymore?

[priethor]

We are still facing the issue of the Navigation block wrapping all its inner blocks within a <ul>, so I would say so.

I would suggest creating a new issue to transform the Navigation block's markup into a <nav> wrapper, as @draganescu suggested in the Navigation block Slack channel.

[draganescu]

In that case @priethor we should have a new issue and close this one as it's a big blob when the next step is a lot clearer. What do you think?

[priethor]

I second that 👍

It will be a good match to #28265 as it already brings its own <ul> wrapper. Are you going to create it? I can help do so otherwise.

[priethor]

Closed in favor of #29036.