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.
Anatomy
Section titled “Anatomy”- Bar container
- Status message
- Action button
When to use it
Section titled “When to use it”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.
Properties
Section titled “Properties”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.
Platform considerations
Section titled “Platform considerations”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.
Best practices
Section titled “Best practices”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.
Content guidelines
Section titled “Content guidelines”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.
Styles
Section titled “Styles”<div class="surface-default" style=" border-top: 1px solid var(--tng-color-border-contrast-default); "> <div class="p-xl fg-error-default"> <div class="tng-flex flex-wrap gap-2xl align-items-center justify-content-space-between" > <p class="flex-grow-5 | tng-text-body pb-md"> Something went awefully wrong. Please try again. </p> <button class="flex-grow-1 | tng-button">Oh well</button> </div> </div></div>Something went awefully wrong. Please try again.
Recipes
Section titled “Recipes”Sticky Bottom Bar
Section titled “Sticky Bottom Bar”Accessibility
Section titled “Accessibility”For Design
Section titled “For Design”- DOM Order — Ensure the bar is placed after the form content in the HTML structure. This ensures a logical tab order where users navigate through inputs before reaching the actions.
- Error Announcements (ARIA Live) — The status message area should use
aria-live="polite"orrole="status". This allows screen readers to announce errors automatically without interrupting the user’s current task. - Avoid Obstruction — Don’t let the bar hide the last field of your form. Add a
padding-bottomto your main container equal to the height of the sticky bottom bar. - Button Status — If a button is disabled, it won’t receive keyboard focus. Show a clear error message upon clicking, explaining why the form cannot be submitted yet.
For Dev
Section titled “For Dev”- DOM Order — Ensure the bar is placed after the form content in the HTML structure. This ensures a logical tab order where users navigate through inputs before reaching the actions.
- Error Announcements (ARIA Live) — The status message area should use
aria-live="polite"orrole="status". This allows screen readers to announce errors automatically without interrupting the user’s current task. - Avoid Obstruction — Don’t let the bar hide the last field of your form. Add a
padding-bottomto your main container equal to the height of the sticky bottom bar. - Button Status — If a button is disabled, it won’t receive keyboard focus. Show a clear error message upon clicking, explaining why the form cannot be submitted yet.
Do
Use it for critical editing workflows where users need to save changes frequently to prevent data loss, for dynamic feedback when displaying global validation errors or loading states while users interact with fields far from the bottom of the page, and for mobile optimisation — it improves ergonomics by placing primary actions within the thumb zone.
Don't
Don’t use it for short forms where all fields and the Submit button fit within a single viewport (it adds unnecessary visual clutter), don’t add it inside modals — they usually have fixed footers already and the combination causes scroll-jacking and a cramped UI — and don’t use it for informational content where there are no data-entry actions.
Application Examples
Section titled “Application Examples”Error Status
Section titled “Error Status”When there is an error on the current step, display an error message.
Multistep Forms
Section titled “Multistep Forms”Use this component together with the Stepper component.
Long Forms
Section titled “Long Forms”Use this when the content exceeds 150vh (one and a half times the screen height).
Best Practices
Section titled “Best Practices”Submit button should have a primary style; there can be secondary buttons but these have not yet been discussed. Keep status messages concise.
Responsive Behaviour
Section titled “Responsive Behaviour”When using the component across all breakpoints, the structure remains the same apart from the mobile breakpoint, which uses a one-column layout instead of a two-column layout.