Button bar

A button bar displays possible actions for users to take when they reach the end of a task. You can use it to provide consistent design when implementing actionable interactions within pages or dialogs across your applications.

Example button bar, with CTA to the left then primary, on the right side there are two secondary buttons

Use the pattern when the user needs to perform actions after reaching the end of a task in a page or a dialog. Some examples include going to previous or next steps, submitting a form and canceling changes.

Core actions:

  1. Use the stack layout component to group your buttons together. This forms the core set of actions.
  2. Ensure that the stack layout has the direction property set to row.

Secondary actions (optional):

  1. If your design requires a secondary set of actions, use another stack layout with button components as above.
  2. Combine the core and secondary stack layouts within a split layout to position them at the ends of the container.
    • Assign the left buttons to the split layout startItem property.
    • Assign the right buttons to the split layout endItem property.
Example button bar, with CTA to the left then primary, on the right side there are two secondary buttons

There are three button variants to choose from. Choosing the correct button depends on the context and is ultimately the choice of the application team. However, we recommend following these guidelines for consistent design:

Call to Action (CTA)

  • Use for the most desired path you intend the user to take.
  • In almost all cases, your scenario should have one CTA so the desired path is clear.
  • This is commonly an affirmative action allowing users to proceed or complete the task, such as Next, Save or Submit.


  • Use for the alternate path you're offering the user.
  • There can be multiple equally weighted paths, resulting in more than one primary button in a scenario.
  • You can use it as a dismissive action alongside the affirmative (CTA) action, such as Cancel or Dismiss.


  • Use for the tertiary path you're offering the user.
  • There can be multiple equally weighted tertiary paths resulting in more than one secondary button in a scenario.
  • This is commonly a related task or function that’s lower priority for the task, such as Import or Export.
  • You can also use it to signify a destructive action that may result in a permanent loss of data. This is commonly followed by user confirmation, e.g., a dialog. Examples include Delete or Reset.

Remember to use a hierarchy when making your button choices, much like following a type ramp. In Example 1 below, Cancel is the alternate path and uses a primary button because there are only two options. However, in Example 2, Cancel uses the secondary button because three actions are available to the user, with this one being tertiary and the least desired option.

  • The Submit primary action uses the CTA button
  • The Cancel alternate action uses the primary button
Example showing button bar with submit button on left as CTA, and cancel as primary to the right of submit
  • The Next primary action uses the CTA button
  • The Previous alternate action uses the primary button (order follows sequential forms).
  • The Cancel tertiary action uses the secondary button.
Example showing button bar with next button on right as CTA, previous as primary to the left of next, and cancel as secondary to the left of cancel
Best practices
  • Provide only one CTA button for a given task—the action that allows the user to complete the task.

The container and the type of scenario determine the position of actions (CTA, primary and secondary buttons).

  • Groups core actions on the left.
  • Follows an F-pattern reading model, allowing users to scan down quickly.
Example showing default button bar order, submit CTA on the left and cancel primary to the right of submit
  • Groups core actions on the right.
  • Always positions Next right of Previous and Cancel to reflect the direction of the steps.
Example showing form with button bar underneath and core actions on the right.
Example showing a dialog with a form and button bar underneath. The core actions are on the right.
  • Always displays core actions on the right.
  • Follows a Z-pattern reading model, where actions are the last focal point in the dialog.
Example showing a form with two buttons that fill the width.
  • Provides the option for actions to fill the width for a cleaner layout if button width doesn’t need to increase drastically.
Best practices
  • Group core onward actions for the form to ensure they remain accessible on browser zoom (e.g., Previous, Next, Cancel or Submit).
  • You should display secondary actions that aren’t core to the workflow at the opposite end of the button bar.

There are two ways to position the button bar:

Fix the button bar at the bottom of the viewport when:

  • A user can proceed (or step back) regardless of task completion.
  • The task is in a wizard.

If content overflows, the button bar uses a secondary border style.

Example showing a form overflowing behind a button bar. The button bar has a top border.

When fields overflow behind the button bar, a border should indicate if more fields are available.

Example showing the end of a form. The button bar has no top border.

Hide the button bar border if content is no longer overflowing (i.e., the user has reached the bottom of the form or the form is entirely above the fold).

The button bar is located at the end of the task when:

  • The user needs to complete the entire task before proceeding, for example, if there are mandatory fields in a form.
  • The system needs the user to acknowledge all information on the page.
Example showing an overflowing form.

When the button bar is at the end of the task, the button may not be visible when the user is at the top.

Example showing the bottom of a form with buttons.

The button bar is visible when the user scrolls to the bottom of the task.

Buttons can display text or icons (or both) to describe the action.

Best practices
  • Always use verbs that emphasize the action the button carries out.
  • Be succinct. Avoid having more than two or three words in a button label.
  • For example, use Create instead of Ok to create a profile, or Save/Discard instead of Yes/No to save changes.

For improved usability at smaller screen or app resolutions, we recommend responsively stacking the button bar when it reaches a specific viewport width or application breakpoint.

We recommend stacking at the xs breakpoint by default. Buttons will expand to fill the full width of the button bar when stacked.

Order of stacked buttons: In a stacked button layout, we recommend buttons stack in order of importance from the top down.

Example button bar, vertically stacked
Best practices
  • Enable the stacked layout when you have longer button labels that may not fit within the horizontal layout at smaller button bar widths.
  • If users will access your application on a mobile device, use a stacked button layout to ensure an adequate touch-area for the buttons.
  1. Build a button bar following the foundational guidelines provided earlier in the documentation.
  2. Adjust the direction property on both stack layout and split layout (if used) to {{xs: "column", sm: "row"}}. This responsive setting arranges the buttons into a column for extra small (xs) screens and a row for small (sm) screens and upwards. This ensures a responsive layout that adapts to the viewport width.
  3. When the button bar has core actions on the right, you'll need to configure an alternative stack layout.
    • Reverse the buttons in this layout to ensure that the core actions are at the top.
    • Employ Salt's responsive design utilities to render this alternative layout at the desired breakpoint. You can find an example of this behaviour here.
Diagram showing how to build a stacked button bar.

If you need to expand the pattern or share feedback with us, please contact the team.