Brief: Navigation v. 0.1 [Block]
- nathan.mckean@reckitt.com (Unlicensed)
- Sergiy Nalyvayko (Unlicensed)
- Nick Harris
- Julia Boyarshchikova (Deactivated)
Component type | Navigation list |
|---|---|
Document status | IN REVIEW |
Design source (in Figma) | |
Author | @nathan.mckean@reckitt.com (Unlicensed) |
Responsible |
|
Navigation is the main way for users to move through a service and locate themselves as they progress.
Use When
You have a multi-page web experience with key ‘sections’ (main navigation)
You have a functional task (e.g. store locator, subscribe, contact us) that is less important than the main navigation items (utility navigation)
Don’t Use When
You have a small or single page experience (either navigation)
You have to many items in your navigation and you need a place to “dump” some (utility navigation).
Related/Similar Components
Table of contents is a navigation component for linking within the current page.
Footer links are a navigational link list, but don’t need to be semantically referenced as navigation.
Key Content
Item | Type | Notes |
Navigation list items | Text | Whether navigation items are manually or programmatically curated is yet to be discussed. Links should generally avoid the use of aria labels and should be descriptive of the content they point to. |
Navigation name | Text | Where multiple navigation regions exist on a page (e.g. primary navigation and breadcrumbs), the navigation must be named to distinguish one from the other. |
|
|
|
|
|
|
|
|
|
|
|
|
*Logo as a navigation item will be discussed further down this page.
*Where we have a dropdown control to toggle visibility, it is recommended to append the navigation name from “Example section” (visible) to “Show Example section submenu” and “Hide Example section submenu”. Whilst this may not be content editable specifically, it could pull from a dictionary. This is detailed more in “bigger discussion topics”.
Visual Style
The MVP version of the design system offers a single (but configurable via tokens) visual style for each of the two navigation items: “main” navigation and “utility” navigation.
Behaviour (main navigation - wide viewports)
Clicking on a primary link that includes a sub-menu will expand the sub-menu.
Each link in the navigation is a tab stop, meaning the menu can be traversed forwards with tab and backwards with Shift+tab on the keyboard. Non expanded submenus will not be focusable.
As per the examples in the Inspiration section (below) the submenu control and the primary link are separate elements with separate tab stops. This allows a keyboard user to first focus on the primary item (e.g. products) and click through if they like and then focus on the submenu toggle to open or close it by clicking Enter or Space (standard button behaviour). Once expanded and visible, the submenu can be progressed through by tab and shift+tab.
Where a submenu is not collapsed by toggling, tabbing to the next primary menu item will close the open submenu.
Each link, per link best practices includes a default, hover, focus and active state. Navigation links within the header do not utilise the visited state.
Where Javascript is disabled, submenus will not render and only the primary links will be available without the toggle controls.
Individual links have hover, focus and active states (not visited).
The current page also have a unique selected/current style.
FOR DICUSSION: Responsive behaviour options requires discussion, agreement and potentially prototyping before going too far. The end goal is to invoke a hamburger menu at the latest possible moment. The tension to balance is between ensuring style integrity ( as can be seen by wrapping items into a “more” dropdown when there is no space for them - reference Smashing Magazine and Microsoft for live examples) and allowing content editors to create unnecessarily long menus, avoiding hard choices (which we may be able to control by limiting menu items within the CMS depending on whether they are programmatically or manually curated). An alternative to degrading items into a “more” dropdown is to either adjust the font size responsively and/or begin (where possible) to wrap items to two lines as is the behaviour of the Bootstrap navbar. We must also remember that our solutions must service languages naturally longer in nature than English. We will also want to test different points at which the hamburger menu is invoked. It might be that simply having products and “more” is a more successful pattern than just a single “hamburger” menu as it makes links to products (our key section) more visible.
Updated: 05/07/22
We expect all child links to have a parent link.
Therefore:
On viewports wide enough to allow - and using css - we style the child links in a dropdown.
The parent link becomes a button with the same label
We use JS to inject the original parent link at position 0 in the list of child links.
The label for the injected link will be provided via a prop but will in most cases read “View all XXX“
On smaller viewports we display the list of links without any manipulation. Differentiating the difference between parent and child links with different styling. There is no need for a header or button in this case.
Behaviour (main navigation - narrow viewports)
Clicking the hamburger menu and close function toggles between visible and hidden states.
All links can be traversed with Tab and Shift+tab.
When the hamburger menu is expanded, focus should be locked within until such time as the menu is closed. Tabbing should never access content behind the open menu.
Where menu contents is longer than the viewport, the container will be scrollable. No scrollbar is currently designed, if needed a design update will be required. Default browser scrollbars (within the container) should be avoided. Browser scrollbars should only exist for the page itself. See New York Times for a live example.
TO DISCUSS: Potential consideration for a prop to offer single column vs two column solutions.
Behaviour (utility navigation)
Until such time as cart, login and language/country controls are added, utility navigation is a simple, single link like - much like the footer link list. Links are styled “subtle” as they are clearly identifiable as links through their position. As header navigation, these links will not include a visible visited state.
Editorial
Keep menu items only to the most critical content. Not every page deserves space in the primary menu.
Keep menu labels as short as possible, especially when fighting for space. “Dishwashing Guide” is better than “Our Ultimate DIshwashing Guide” - these longer terms can be used for page titles, not navigation labels. Help & Support, where space is confined could be reduced to only “Support” or “Help”.
Utilise the navigation menu for peripheral functional content such as “subscribe” “store locator” “contact us” and similar.
Accessibility
Where multiple navigation items exist o a page (likely, so best to implement regardless) <nav> regions require naming. If a name is visually available on the page, it should be implemented with aria-labelledby. If no visual label exists, use aria-label.
Use aria-current to define the current page.
The navigation behaviour described above in terms of keyboard behaviour should deliver an accessible solution.
Note the behaviour of the <li> on Microsoft and Smashing Magazine navigation when they invoke the “more” menu item. The number of items in the list changes to include the number visible + “more”. Note also that there is no link destination for “more” and so it would logically be a button, not a separate link and button like in the standard menu dropdowns.
TO DISCUSS: Whilst having the logo linked to the home page is a common behaviour (where the alt tag should state “Home” and not “Logo” (or similar), best practices still suggest including a text-based Home label as the first primary link. Where this occurs (and it might be generated through a Content Editor control and prop) we would effectively have two “Home” links in the menu. One (likely the logo) should therefore be hidden from screen-readers and additionally not be focusable via keyboard. Where there is no text-based “Home” link, the logo should form part of the link list rather than sit outside it as a separate linked image and a navigation list that doesn’t include “Home”. Additionally, whilst the MVP will only allow a logo at the start of the menu, future expansion may allow centred logos which, if clickable could cause DOM-order conflicts - but this can be addressed when the system is expanded.
Analytics & Data
It is likely that menu expansion, visibility and even clicks within menus (vs on page navigation links) will want to be tracked and so should be able to be isolated with CSS selectors or IDs.
Future Expansion
Inclusion of menu item icons
Entirely new navigation formats (split nav like Finish and Mega Nav) will be created - but since only one navigation will exist per site, could be completely different components. It is likely though that in the case of a split nav, a general “navigation” component will be used and simply labelled differently to differentiate them to screen readers.
Wider Conversations that may impact this
DOM Manipulation: Generally speaking, the navigation HTML should be set and styled and Javascript, under progressive enhancement would manipulate the DOM as smaller breakpoints for hamburger navigation, etc. Some developers will instead duplicate the menu structure in the navigation and hide/show it where required - that is technically poor practice under progressive enhancement, but if there is a significant performance gain, it might be an acceptable methodology considering that very few people load the raw HTML (but note that for browser support on old browsers like IE8, loading the HTML only may be the best solution and so it will be seen - albeit by a small percentage). Considering that visually, the menu contents on the hamburger menu is not visible until interactive, it would make more sense to set the order to the mobile layout and then DOM manipulate the mobile. (Open for discussion of course)
Functional Dictionary: There are certain content items that need to be in localised language that shouldn’t be content editable but which fuel accessibility such as Back and Next labels on carousels, Hide/Show and other functional phrasing. It is suggested that within the CMS we create a functional dictionary for these terms, allowing us to reference those dictionary items to populate certain text without requiring content case by case content entry.
Inspiration from elsewhere
Inclusive Components: Menus and Menu Buttons (must read)
W3C Fly-out Menus (specifically Approach 2: Use button as toggle)
Adobe Experience Manager Navigation Component (primarily of backend value)
Examples
Useful links