Sticky Bottom Bar
The Sticky Bottom Bar is a persistent UI element located at the bottom of the viewport. It ensures that primary actions — like saving progress or submitting data — are always accessible, regardless of how much the user has scrolled. This approach improves mobile usability by keeping primary actions within easy reach.
When to use it (and when not to)
Section titled “When to use it (and when not to)”Use it 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 using it when:
- The page is static and the user is not inputting or saving data.
- All fields and the submit button fit within a single viewport — the bar adds unnecessary visual clutter.
- The component would be placed inside a modal — modals already contain their own button bar, and adding a sticky bar can lead to scroll-jacking and a cramped UI.
- There are no data-entry actions — the bar serves no purpose and distracts the user.
Quick summary of accessibility & consistency
Section titled “Quick summary of accessibility & consistency”- The bar must be placed after the form content in the DOM to ensure a logical tab order where users navigate through inputs before reaching the actions.
- The status message area should use
aria-live="polite"orrole="status"so screen readers announce errors automatically without interrupting the user’s current task. - Do not let the bar hide the last field of your form. Add a
padding-bottomto your main container equal to the height of the sticky bar. - If a button is disabled, it should not receive keyboard focus. Show a clear error message upon clicking, explaining why the form cannot be submitted yet.
- Maintain consistent spacing, elevation, and layout across breakpoints.
Properties
Section titled “Properties”Appearance : Empty Form
Section titled “Appearance : Empty Form”On the empty form, the buttons will look disabled.
Tablet / Desktop
Sticky Button Bar
Error message: false
Device: Tablet
Button-Main
Depends on: Button-Main
Type: Primary
Size: LG
State: Disabled
Has border: true
Has icon left: false
Has icon right: false
Mobile
Sticky Button Bar
Error message: false
Device: Mobile
Button-Main
Depends on: Button-Main
Type: Primary
Size: LG
State: Disabled
Has border: true
Has icon left: false
Has icon right: false
Appearance : Error Message
Section titled “Appearance : Error Message”This state is triggered when a user attempts to submit the form with invalid or missing information. It includes a concise string of text appearing to the left of the buttons (on tablet/desktop) or above them (on mobile).
Tablet / Desktop
Sticky Button Bar
Error message: true
Device: Tablet
Error Message
Text color:
color-foreground-error-default#cc0000color-foreground-error-default#cc0000Button-Main
Depends on: Button-Main
Type: Primary
Size: LG
State: Disabled
Has border: true
Has icon left: false
Has icon right: false
Mobile
Sticky Button Bar
Error message: true
Device: Mobile
Error Message
Text color:
color-foreground-error-default#cc0000color-foreground-error-default#cc0000Button-Main
Depends on: Button-Main
Type: Primary
Size: LG
State: Disabled
Has border: true
Has icon left: false
Has icon right: false
Appearance : Successful Form
Section titled “Appearance : Successful Form”If there are no errors and the user is able to continue, the primary action will become active.
Tablet / Desktop
Sticky Button Bar
Error message: false
Device: Tablet
Button-Main
Depends on: Button-Main
Type: Primary
Size: LG
State: Rested
Has border: true
Has icon left: false
Has icon right: false
Mobile
Sticky Button Bar
Error message: false
Device: Mobile
Button-Main
Depends on: Button-Main
Type: Primary
Size: LG
State: Rested
Has border: true
Has icon left: false
Has icon right: false
Styling
Section titled “Styling”Colors
Section titled “Colors”| Name | Applied as | Applied to |
|---|---|---|
color-surface-neutral-default | Background color | Sticky Button Bar |
color-surface-neutral-default | Background color | Sticky Button Bar |
color-border-contrast-default | Border color (top) | Sticky Button Bar |
color-border-contrast-default | Border color (top) | Sticky Button Bar |
color-foreground-error-default | Text color | Error Message |
color-foreground-error-default | Text color | Error Message |
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 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 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.
Guidance on how to use a component.
- Critical Editing — Use for workflows where users need to save changes frequently to prevent data loss.
- Dynamic Feedback — Use when you need to display global validation errors or loading states while the user is interacting with fields far from the bottom of the page.
- Mobile Optimization — Improves ergonomics by placing primary actions within the “thumb zone.”
Guidance on what to avoid when using a component.
- Short Forms — If all fields and the “Submit” button fit within a single viewport, a sticky bar adds unnecessary visual clutter.
- Modals — Modals usually have fixed footers already. Adding a sticky bar inside one can lead to “scroll-jacking” and a cramped UI.
- Informational Content — If there are no data-entry actions, the bar serves no purpose and distracts the user.
Application Examples
Section titled “Application Examples”Guidance on where this component has been used
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”Guidance on where this component has been used
- 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”Guidance on where this component has been used
- 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.