Skip to main content

Navigation Patterns

Navigation is how users find their way through your product. Good navigation feels obvious; bad navigation creates confusion and frustration. This document covers common navigation patterns, when to use them, and how to implement them accessibly.

Last updated: April 2025

Primary navigation​

Primary navigation provides access to the main sections of a site or application.

Horizontal top navigation​

Description: Navigation items arranged horizontally, typically at the top of the page.

When to use:

  • Sites with 4-8 primary destinations
  • When horizontal space is available
  • Desktop-focused experiences

Accessibility requirements:

  • Use <nav> element with aria-label="Main navigation"
  • Links should have clear, descriptive text
  • Current page indicated visually and programmatically (aria-current="page")
  • Keyboard navigable with visible focus states

Considerations:

  • Items should fit comfortably; don't overflow or truncate
  • Keep items scannable—avoid long labels
  • Most important items typically placed first (left in LTR languages)

Vertical sidebar navigation​

Description: Navigation items stacked vertically in a sidebar.

When to use:

  • Applications with many navigation items
  • When items have sub-navigation
  • When navigation needs to remain visible during tasks

Accessibility requirements:

  • Same as horizontal navigation
  • Expandable sections need proper ARIA: aria-expanded, aria-controls
  • Consider aria-hidden for collapsed sections

Considerations:

  • Sidebar width affects content area—balance accordingly
  • Deep nesting (more than 2 levels) gets confusing
  • Consider collapsible state for more content space
Skip links

Always provide a skip link that lets keyboard users bypass navigation and jump to main content. Place it as the first focusable element: "Skip to main content."

Mobile navigation​

Mobile screens require different navigation approaches due to limited space.

Hamburger menu​

Description: Navigation hidden behind a three-line icon that reveals a menu on tap.

When to use:

  • Mobile viewports where horizontal navigation doesn't fit
  • When you have more than 4-5 primary destinations

Accessibility requirements:

  • Button must have accessible label: aria-label="Open menu"
  • State must be communicated: aria-expanded="false" (or true when open)
  • Menu must be keyboard navigable
  • Focus must be trapped within open menu
  • Focus should return to trigger when closed
  • Escape key should close the menu

Considerations:

  • "Hamburger blindness"—some users don't recognize or notice it
  • Important actions may be better placed outside the menu
  • Opening animation should be quick (under 300ms)
  • Consider showing 2-3 key items even on mobile

Bottom navigation (mobile)​

Description: Fixed navigation bar at the bottom of the screen with icon+label items.

When to use:

  • Mobile apps with 3-5 primary destinations
  • When users switch between sections frequently
  • When thumb reachability matters

Accessibility requirements:

  • Icons must have text labels (icon-only is insufficient)
  • Current section indicated visually and programmatically
  • Touch targets at least 44×44 pixels

Considerations:

  • Limits content area—use when navigation is truly primary
  • Don't include too many items (5 maximum)
  • More/overflow menu can handle additional items

Tab bar​

Description: Segmented control allowing switching between views at the same level.

When to use:

  • Switching between related views of the same content
  • When users need to compare between tabs
  • Filtering/viewing options at the same hierarchy level

Accessibility requirements:

  • Use role="tablist", role="tab", role="tabpanel"
  • aria-selected indicates current tab
  • Keyboard: Tab to enter, arrow keys to switch, Tab to move to panel

Considerations:

  • Tabs shouldn't navigate to new pages—that's what nav does
  • Content should relate to the same thing, just different views
  • Avoid scrolling tab bars when possible

Secondary navigation​

Description: Trail showing the user's location in the site hierarchy.

When to use:

  • Sites with hierarchical structure
  • When users arrive via search or deep links
  • When users need to navigate up the hierarchy

Accessibility requirements:

  • Use <nav aria-label="Breadcrumb">
  • Structured list (<ol>) with proper markup
  • Current page should be text, not a link
  • Current page indicated with aria-current="page"

Considerations:

  • Show the path, not history (Back button handles history)
  • Keep item names concise—full page titles may be too long
  • Truncate middle items if path is very deep

In-page navigation / Table of contents​

Description: Links to sections within the current page.

When to use:

  • Long-form content with distinct sections
  • Documentation and reference material
  • When users need to jump to specific content

Accessibility requirements:

  • Links should match heading text exactly (or clearly relate)
  • Headings must have proper IDs for anchor links
  • Consider aria-label="Table of contents" for the nav

Considerations:

  • Keep visible on wide screens; collapse on mobile
  • Highlight current section on scroll
  • Place consistently—left sidebar is common for docs

Mystery meat navigation​

Icons without labels that don't clearly indicate their destination. Users shouldn't have to guess what will happen when they click.

Fix: Always include text labels, or at minimum tooltips that appear immediately.

Hover-dependent navigation​

Navigation that only appears on hover fails for touch users and many assistive technology users.

Fix: Ensure all navigation is accessible without hover.

Deep nesting​

More than 3 levels of navigation hierarchy causes disorientation. Users lose track of where they are.

Fix: Flatten information architecture. Reconsider structure if you need more than 3 levels.

Inconsistent placement​

Navigation that moves between pages breaks spatial memory. Users expect navigation in predictable locations.

Fix: Keep navigation in consistent positions across pages.

Overcrowded navigation​

Too many items overwhelm users and make scanning impossible.

Fix: Prioritize ruthlessly. Use progressive disclosure. Consider a search-first approach for large item sets.

Responsive navigation transitions​

Breaking points​

Plan how navigation transforms:

Desktop (over 1024px): Full horizontal navigation visible

Tablet (768–1023px): May need to reduce items or switch to hamburger

Mobile (under 768px): Hamburger or bottom navigation

Graceful degradation​

Don't just hide navigation on mobile—provide an appropriate alternative:

  • Hamburger menu with full navigation
  • Bottom bar for key destinations
  • Search as an alternative to browsing

Testing transitions​

Test at breakpoint boundaries. Navigation often breaks at exactly the wrong widths during responsive transitions.

How many items should primary navigation have?

5-7 is often ideal for horizontal navigation. More than 7 becomes hard to scan. Fewer than 3 may not justify dedicated navigation—consider alternatives.

Should I use icons in navigation?

Icons can help recognition but shouldn't replace labels. The combination of icon + label is most effective. Icon-only navigation only works when icons are universally understood (rare).

Hamburger or visible navigation?

Visible when space allows. Hamburger menus reduce discoverability—usage typically drops. On mobile, visible bottom navigation often outperforms hamburger.

How do I handle mega menus accessibly?

Use proper ARIA for expanded states, trap focus within the open menu, allow Escape to close, and ensure all items are keyboard accessible. Test with screen readers—mega menus are complex.

Should navigation be sticky/fixed?

It depends. Sticky navigation provides constant access but uses screen space. Consider sticky on long pages, but not at the expense of content area—especially on mobile.

Related resources