| Page Properties | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Behaviour (main navigation - wide viewports)
Hovering over Clicking on a primary link that includes a sub-menu or hovering over the submenu toggle will expand the sub-menu (see W3C example in the inspiration section).There must be a delay applied once moving off a submenu before it disappears to allow a user to return quickly without having to re-expand the 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.
| Panel | ||
|---|---|---|
| ||
Updated: 05/07/22
|
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.
...
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.
...
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.
...