Skip to content

Sticky Bottom Bar

Sticky bottom bars anchor primary actions to the bottom of the viewport so they remain reachable regardless of scroll position — most commonly used for checkout-style flows and long forms.

The Sticky Bottom Bar is a persistent UI element at the bottom of the viewport. It keeps primary actions — like saving progress or submitting data — always accessible regardless of how far the user has scrolled. The pattern improves mobile usability by anchoring primary actions inside the thumb zone.

Add a phone number to continue.

  1. Bottom Bar
  2. Status message
  3. Action button

Use the Sticky Bottom Bar when:

  • The page involves high-volume scrolling and the user needs constant access to primary actions.
  • You need to display real-time global feedback or validation errors while the user interacts with fields far from the bottom of the page.
  • The content exceeds 150vh (one and a half times the screen height), such as long forms.
  • You want to improve mobile ergonomics by placing primary actions within the thumb zone.

Avoid the Sticky Bottom Bar when:

  • The page is static and the user isn’t inputting or saving data.
  • All fields and the submit button fit within a single viewport — the bar adds unnecessary visual clutter.
  • The component would sit inside a modal — modals already contain their own button bar, and adding a sticky bottom bar leads to scroll-jacking and a cramped UI.
  • There are no data-entry actions — the bar serves no purpose and distracts the user.

Appearance

Three appearance states map to the form’s status: Empty form (buttons appear disabled), Error message (a concise red message appears beside the buttons on tablet/desktop, above them on mobile), and Successful form (the primary action becomes active).

Status message

Inline text used for global validation feedback. Renders inside a polite live region so screen readers announce updates without interrupting the user’s current focus.

Action button

A primary Button-Main at LG size. Secondary buttons may appear alongside the primary, but the submit verb should always read as the primary action. Disabled buttons should not receive keyboard focus — surface a clear error on click instead.

Desktop

The bar spans the viewport width with the status message and button(s) arranged on a single row. Keep the bar’s elevation distinct from the page surface so it reads as a separate layer.

Tablet

Same one-row layout as desktop. Make sure the page content has bottom padding equal to the bar’s height so the last form field isn’t hidden behind it.

Mobile

The bar reflows to a one-column layout — status message above, buttons below. The thumb-zone position is the whole point of the pattern at this size.

Use the bar as a workflow tool — it should help users finish, not chase them down the page.

Do

Use it for critical editing workflows where users save changes frequently, lean on it for dynamic feedback when validation messages need to be visible from anywhere on the page, place primary actions in the thumb zone on mobile, and add bottom padding to the main container equal to the bar’s height so the last field never hides beneath it. Pair it with the Stepper for multi-step forms, and use it when content exceeds 150vh.

Don't

Don’t use it for short forms that fit in one viewport, don’t nest it inside a modal that already has a fixed footer, and don’t include it on pages without data-entry actions — the bar serves no purpose and distracts the user.

Submit button labels should name the action the user is about to take (“Save”, “Continue”, “Submit”) rather than generic verbs. Keep status messages concise and specific — name the field or rule that needs attention so the user can act (“Add a phone number to continue”) instead of restating that something’s wrong. When the form has multiple steps, the bar’s wording shouldn’t change between steps — predictability is the point.