Navigation Patterns & Components

Interactive example · Navigation patternsSwitch the pattern, then interact

Top barSidebarHamburgerBottom tabsMega menu

Acme

Home

Mock page content

Top bar — best for a handful of top-level destinations on desktop/web. Always visible, low interaction cost.

The full lesson

Navigation is not decoration. It is the physical expression of your information architecture — the moment your mental model of content becomes something a user can see, tap, and move through. Get the IA right first, then pick the pattern that surfaces it. Reverse that order, and no navigation component can save you.

The research is clear: users abandon tasks when navigation is hidden, ambiguous, or inconsistent. Your pattern choice determines how fast users find content, how much they trust the product, and whether assistive-technology users can move through the site at all. This lesson maps the major patterns to the contexts where they work, covers the key decisions inside each one, and separates modern best practice from habits that data has since discredited.

Why Pattern Choice Precedes Visual Design

Before you decide between a tab bar and a side rail, answer three IA questions:

1. How many top-level destinations exist? Below five, almost any pattern works. Above eight, you need grouping, mega menus, or progressive disclosure (revealing content only when the user needs it).
2. How often do users switch sections mid-task? Frequent cross-section movement demands persistent, always-visible navigation. Occasional movement can tolerate a drawer or overflow menu.
3. What is the primary device context? Touch targets, viewport width, and one-handed reach all constrain your options.

Only after you answer those three questions does visual design of the component become useful work.

Persistent Top Navigation (Desktop)

The horizontal top bar is the default for content-dense desktop products and marketing sites. Done well, it is fast: users recognize it instantly, it stays in view at all times, and it takes up minimal vertical space.

When it fits: five to eight top-level sections, primarily pointer-driven (mouse) interaction, moderate content depth.

Anatomy of a solid top nav:

• Logo / home link anchored left
• Primary destinations as visible text links — never icons alone at this level
• Secondary actions (search, account, CTA) anchored right
• An active-state indicator that is not color-only (underline, weight shift, or background change)

Mega menus for large sites. When a site has dozens of sub-destinations, a simple dropdown becomes a wall of links. Mega menus solve this by revealing a two-dimensional panel — categories as columns, destinations as rows — on hover or focus. They are the right pattern for large e-commerce sites, enterprise products, and government portals. Keep panels scannable: group links under clear sub-headings, include a thumbnail or icon only if it speeds recognition (not for decoration), and make sure the panel closes on Escape and returns focus to the trigger.

Tab Bars (Mobile)

On small screens, the tab bar at the bottom of the viewport is the strongest navigation pattern available. It is always visible, it sits within thumb reach, and the icon-plus-label format communicates both what the destination is and which one is currently active.

When it fits: two to five primary destinations, native-feeling mobile apps or progressive web apps, bottom third of screen reachable one-handed.

Guidelines that are frequently violated in the wild:

• Use both an icon and a label. Icon-only tab bars score measurably lower on comprehension in usability tests — unless the icons are already universal (home, search, cart, profile).
• Do not exceed five tabs. A sixth destination creates a “More” overflow tab that defeats the purpose of a tab bar entirely. If you have six sections, restructure the IA before touching the nav.
• The active tab should use a filled icon variant (versus outline for inactive), a color shift that meets WCAG 2.2 AA contrast, and a text weight change. Never rely on color alone.
• Minimum tap target per WCAG 2.2 Success Criterion 2.5.8: 24 × 24 CSS pixels with adequate spacing. The recommended comfortable size is 44 × 44 px.

Side Navigation (Rail and Full Drawer)

Side navigation is the workhorse of enterprise dashboards, admin interfaces, and complex web apps. It scales to far more destinations than a top bar, and its vertical axis accommodates grouping headers naturally.

Side rail (collapsed): icon-only, 48–64 px wide. Useful when screen space is tight and the icon vocabulary is well-established in context. Always provide a tooltip with the label on hover or focus — icon-only navigation without labels is an accessibility failure waiting to be filed.

Full side drawer: labels and icons, 220–280 px wide. Hierarchical grouping with collapsible sections is fine, but cap nesting at two levels. Three levels deep in a side nav is a symptom of unresolved IA, not a navigation design problem.

Responsive behavior. On medium viewports, the side nav commonly collapses to a rail. On small viewports it moves off-screen and opens via a hamburger trigger. This is one of the few legitimate uses of the hamburger: the navigation already exists in a visible form at larger sizes, so hiding it on small screens is a space trade-off, not a discovery problem.

Breadcrumbs

Breadcrumbs are a secondary navigation pattern. They show the user where they are in a hierarchy and let them move upward through it. They do not replace primary navigation — they augment it.

When they earn their space:

• Deep hierarchies (three or more levels) where users may land on an interior page from search, email, or social media
• E-commerce product and category pages
• Documentation sites with nested sections

Implementation details that matter:

• The current page should appear as the last crumb but should not be a link — it is where you are, not where you go. Use aria-current="page" on the final item.
• Wrap the list in a nav element with aria-label="Breadcrumb" so screen readers announce it distinctly from primary navigation.
• On narrow viewports, truncate middle crumbs (show root and last two) rather than wrapping to multiple lines or hiding entirely. A single ellipsis crumb that expands on tap is better than horizontal scroll.
• Schema.org BreadcrumbList structured data improves Google rich-result eligibility — a low-effort SEO win.

Pagination and Infinite Scroll

Both are navigation patterns for moving through long lists or result sets. The choice has downstream effects on accessibility, performance, and URL structure.

Dimension	Pagination	Infinite Scroll
URL / shareable state	Each page has a stable URL	Single URL; state lost on reload
Keyboard / AT access	Native link / button controls	Requires custom focus management
Footer reachability	Always reachable	Footer never reached
Task type fit	Search results, data tables, known-item lookup	Feed consumption, social, exploration
Load-more hybrid	N/A	Best compromise: explicit “Load more” button

For task-oriented interfaces — search results pages, admin tables, filtered product grids — pagination wins. For consumption-oriented feeds where users scroll without a specific target, infinite scroll is acceptable only with a “Load more” button that users can trigger deliberately. Pure infinite scroll with automatic loading traps keyboard users and removes all sense of progress.

Contextual and In-Page Navigation

Not all navigation is site-level. Inside a long article, dashboard, or multi-step flow, users need orientation and shortcuts to sub-sections.

Sticky table of contents (article / docs): a fixed-position list of section headings on the side or top of long-form content. Highlight the active heading as the user scrolls using an IntersectionObserver. This is one of the highest-value additions to a documentation or blog layout — reading comprehension tests show that users with a visible table of contents complete comprehension tasks faster and report higher confidence.

Stepper / wizard navigation: multi-step flows (checkout, onboarding, form completion) need a progress indicator. Show all steps, mark the current step, and allow backward navigation to completed steps. Never hide the step count — users need to know how much work remains. WCAG 2.2 criterion 3.3.7 (Redundant Entry) requires that information entered in a prior step does not need to be re-entered in a later step of the same process.

Tabs within a page: do not confuse these with browser tabs or tab bars. Page-level tabs divide content into parallel panes. Use the ARIA Tabs pattern: role="tablist", role="tab", role="tabpanel", aria-selected, and aria-controls. Arrow keys move between tabs; the Tab key moves into the active panel. Do not use page tabs for sequential content (use a stepper instead) or for content that benefits from comparison (show both panels side by side instead).

Accessibility Requirements Across All Navigation

These apply to every pattern you choose — no exceptions:

• Focus management: when a menu or drawer opens, move focus into it. When it closes, return focus to the trigger. Use the inert attribute (now widely supported) to trap focus inside modals and prevent background content from receiving keyboard input.
• Skip link: a visually hidden, focus-visible “Skip to main content” link should be the first focusable element on every page. It lets keyboard users bypass repeated navigation on every page load.
• Visible focus: WCAG 2.2 Success Criteria 2.4.11 (Focus Not Obscured, Minimum) and 2.4.12 (Focus Not Obscured, Enhanced) require that the focused component is not entirely hidden by sticky headers or overlays. If your sticky nav covers focused elements, use scroll-margin-top to compensate.
• Landmark roles: wrap your primary nav in a nav element. If there are multiple nav elements on a page, each needs a unique aria-label so users can distinguish them when navigating by landmark in assistive technology.

Choosing the Right Pattern: A Decision Framework

Context	Recommended pattern	Avoid
Desktop, 5–8 sections, content site	Horizontal top nav	Hamburger on desktop
Desktop, 8+ sections, e-commerce / enterprise	Top nav + mega menu	Long single-column dropdown
Desktop, dense app / dashboard	Side drawer or rail	Top nav (steals vertical space)
Mobile, 2–5 primary destinations	Bottom tab bar	Hamburger (hidden navigation)
Mobile, deep hierarchy	Hamburger + side drawer	Bottom tab bar (too shallow)
Deep content tree, mid-page entry	Breadcrumbs	Breadcrumbs on flat sites (noise)
Long result sets, findability task	Pagination	Infinite scroll
Long feed, consumption / discovery	Load-more infinite scroll	Pure auto-loading infinite scroll
Long article / documentation	Sticky in-page ToC	No orientation aid

This framework is a starting point, not a rule. Run tree tests on your IA before finalizing the pattern — the navigation will only be as good as the structure it exposes.