Mobile Bottom Nav with Active Icon Lift

Mobile bottom navigation is useful when an app has a small set of equally important top-level destinations, such as Home, Search, Saved, and Profile. The active icon lift in this example is deliberately a secondary cue: the label, color, focus treatment, and semantic state do the essential wayfinding work.

What the active icon lift communicates

When a user selects a destination, its icon moves upward by a few pixels and receives a contrasting background shape. The movement creates a small sense of arrival, while the persistent label makes the destination identifiable at a glance. Keeping the lift subtle matters on mobile: a large jump can make the navigation feel unstable, especially when users switch destinations repeatedly.

Do not use the lift as the only active-state indicator. People who are sensitive to motion, people viewing the interface in a reduced-motion mode, and people who cannot see the animation still need an unmistakable state. In a production component, use a meaningful current-location attribute such as aria-current="page" on the active link and provide a visible difference through color, shape, weight, or an indicator line.

Self-contained SVG and CSS demo

The following demo shows Home as the current destination. It uses ordinary links, inline SVG icons, CSS transitions, and a media query that removes the lift when the user has requested reduced motion. The links are intentionally static so the example remains self-contained and does not depend on JavaScript or a framework.

For a real application, the routing layer should update aria-current when the destination changes. The CSS selector then follows the semantic state rather than a separate styling-only class. That reduces the risk of the visual and accessible states drifting apart.

Copy the implementation

This shortened listing contains the core structure and styling. The production version should replace the fragment links with real routes and preserve the labels that match the destination names used elsewhere in the interface.

<nav class="bottom-nav" aria-label="Primary">
  <a class="bottom-nav__link" href="/home" aria-current="page">
    <svg class="bottom-nav__icon" viewBox="0 0 24 24" aria-hidden="true">
      <path d="M3.5 10.5 12 3l8.5 7.5"></path>
      <path d="M5.5 9.5v10h13v-10"></path>
      <path d="M9.5 19.5v-5h5v5"></path>
    </svg>
    <span>Home</span>
  </a>
  <!-- Repeat links for Search, Saved, and Profile. -->
</nav>

.bottom-nav__link[aria-current="page"] .bottom-nav__icon {
  transform: translateY(-0.3rem);
  color: #173bce;
}

@media (prefers-reduced-motion: reduce) {
  .bottom-nav__icon {
    transition: none;
    transform: none;
  }
}

The SVG paths are intentionally simple. They use a shared currentColor stroke, so the icon inherits the link’s state color without duplicating color declarations for every path. Keeping icons inline also makes the example easy to adapt, although an icon library may be preferable when a product already has a tested, consistent symbol set. MDN’s SVG documentation is a useful reference for view boxes, paths, and presentation attributes.

Keyboard and screen-reader behavior

Use links when each item takes the user to a destination. Native links are keyboard reachable, work with browser history, and expose their names from the visible text. Avoid replacing them with clickable non-semantic containers. If an item opens an action rather than navigates to a page, use a button instead and give it an accessible name.

Each link should have a sufficiently large touch target and should remain distinguishable at high zoom. The demo uses visible labels rather than icon-only controls. The inline SVGs are marked aria-hidden="true" because the adjacent text supplies the accessible name; announcing both the icon and the label would usually be redundant. If an icon conveys information not present in the label, revise the accessible name and test it with a screen reader.

The active link uses aria-current="page". Apply it to exactly one item for the current page, and update it as part of navigation. Do not announce the lift as a separate status message: the state itself is the useful information. A visible keyboard focus outline is also required; the demo keeps focus styling separate from the active styling so keyboard users can tell which item will receive input.

Reduced motion and visual restraint

The prefers-reduced-motion media query disables both the icon transition and the upward transform. This preserves the active color, background, label, and semantic state while removing nonessential movement. The same principle should apply if the component later gains a bounce, scale, spring effect, or route-change animation. WCAG guidance on animation from interactions recommends giving people a way to avoid motion that can distract or cause discomfort; honoring the operating-system preference is a practical baseline.

Keep the lift short and reserved for a state change. Avoid continuously floating icons, repeated pulses, or motion that competes with the page content. If the bar is fixed to the viewport, account for the device’s bottom safe area and ensure it does not cover form controls, dialogs, browser UI, or important content.

Rendering and performance considerations

This pattern has a small SVG surface area: four simple icons, no filters, no masks, and no continuously running animation. The state change animates transform and color rather than changing layout dimensions. That is a sensible starting point for a compact navigation component, but it is not a substitute for testing the complete page on representative devices.

Do not infer performance from this snippet alone. Check the finished navigation alongside real fonts, shadows, route transitions, analytics, and other animated elements. Look for dropped frames during repeated tab changes and verify that a fixed bar does not trigger unnecessary style or layout work. The web.dev animation guidance provides a framework for choosing properties and investigating rendering behavior. If the design grows more elaborate, compare a CSS-only solution with a timeline library only when the extra coordination is genuinely needed.

When this pattern is a good fit

Use an active icon lift when the navigation has three to five stable destinations, the bar remains visible, and the motion reinforces a state change. It is less suitable for a large information architecture, long labels, or navigation that changes frequently based on user permissions. In those cases, a conventional top bar, drawer, or clearly labeled tab system may be easier to scan.

For related wayfinding patterns, see Search Trigger with Magnifier Handle Extend, Breadcrumb Chevron Motion on Route Change, and Sidebar Section Indicator with Vertical Path Fill. These should complement—not replace—the current-location label and semantic navigation structure.