Navigation templates

4 templates

Navigation is the component most likely to be built three times on the same project, and the one where keyboard and screen-reader support is most often skipped. Each of these works without a mouse.

Navigation is where keyboard support usually breaks

It is the component most likely to be rebuilt three times on one project, and the one where the shortcuts cost the most. A hamburger built from a <div> with a click handler is invisible to a keyboard, announces nothing to a screen reader, and cannot be reached at all by anyone not using a mouse.

Every template here uses real elements. The toggle is a <button>, the menu is a <nav>, and the open state lives in aria-expanded — which doubles as the CSS hook, so the visual state and the announced state cannot drift apart.

The four things to check on any menu

• Can you open it with the keyboard? Tab to the control, press Enter or Space.
• Does Escape close it, and does focus go back to the button? Without that, focus falls to the top of the document and the user has to tab all the way back.
• Does it survive a resize? Open the menu on a phone, rotate to landscape. A menu that is hidden by a media query while its button still says it is open is a common bug.
• Does hover work on touch? It does not. A hover-only dropdown opens on the first tap and will not close, which is why these pair hover with a click handler and disable hover under @media (hover: none).

If you have more than one <nav> on a page — a main menu and a footer menu, say — give each an aria-label. Otherwise a screen reader user cycling through landmarks hears "navigation" twice with no way to tell them apart.

Other categories