List of all Examples

Implementing a Navbar with a lot of Submenus

These examples are focusing explicitly on a website navbar which has a lot of submenus.

Update October 24, 2022: In a previous version of this post, we tested a navbar structure where the main navigation item included both a link to a topic page for a subject and a button which toggled a submenu containing posts belonging to the topic. I had the hypothesis that the topic pages would be more intuitive for users and that the submenus could be implemented as a progressive enhancement. However, in the first tests this hypothesis proved to be false. The submenus are more intuitive for the users and it is confusing that the navigation item includes both a link and a button. This version therefore removes the link to the topic page and keeps the button for toggling the submenu.

I am using the navbar for the INNOQ.com website as a test for the navbar structure. Because the navbars here are only intended for test purposes, the link targets will always lead back to this page.

A lot of my opinions here are informed by this Menu & Menu Buttons post from Heydon Pickering.

Update November 04, 2022: The accessibility of the examples have been optimized by adding an aria-label to the ul to designate it as being the main navigation for the page. Additionally, the bullets of the list entries within the navbar have been hidden with CSS because it isn't possible to select an entry in the list by selecting the bullet point and it adds extra information for assistive technologies which is not useful.

Encapsulating Submenus in a Details Tag

In this first example, I am encapsulating the submenu in a details HTML element which will mean that for browsers which support the details element (i.e. all modern browsers), the submenus will by default be able to be expanded/collapsed even when no custom CSS and JavaScript are specified. The navigation itself is a list, and the submenu ul element has been labelled to provide information for assistive technologies.

For a website which has a lot of submenus, I like this option as the HTML fallback because it will allow ALL users to expand and collapse the submenus even when JavaScript on the website fails. There are some limitations to styling this variant with CSS, so I can also envisage using this HTML as the basis for a JavaScript component that modifies the navbar as a progressive enhancement.

Collapsing and expanding submenus with a custom Toggle Button

This is an example which uses a custom JavaScript component to expand and collapse the submenu for an option. This is similar in usability to the first example. The main benefit is the difference in the HTML structure which allows more flexibility for styling the elements. This would also make it possible to show the menu on hover in addition to toggling the menu via the toggle buttons.

When JavaScript is not enabled, all submenus will be rendered as a nested list of links without any option to collapse them.

This is also implemented in a similar way to the Example Disclosure Navigation Menu from the ARIA Authoring Practices Guide (APG) . It would also be possible to implement the optional keyboard support as described in that example, but the keyboard support (e.g. navigating with arrow keys) is not implemented here.

In this version, I would like to test especially if it is clear that the button will toggle a submenu or if we should add extra information to assistive technologies to test this.

Using the aria-haspopup attribute and menu role

I originally intended to try to implement my own example of a submenu using the ARIA aria-haspopup role on the menu toggle and the menu role on the submenu. However, I decided not to because this pattern is strongly advised against in the following sources:

The reasons why this is seen as an Antipattern is that a submenu within a site navigation is not semantically the same as what would be expected for a menu role, because setting the menuitem role on all the links (which is required in order for the menu to be accessible) causes the link to no longer be recognized as a link for assistive technologies.

Additionally: implementing the submenu navigation as a menu also changes how the menu should be navigated via the keyboard: instead of navigating between the links via the TAB key, the user can only exclusively use the arrow keys. For some keyboard users this may be intuitive, but it does differ from many sites which use the disclosure navigation pattern and allow navigating through the site navigation with the TAB key.

Note: there is an example provided by the ARIA Authoring Practices Guide for providing a submenu via the menu role. Also note that this is the example that is explicitly mentioned as misleading by Adrian Roselli in his post.