Use buttons to trigger actions and links. Buttons should include text and can include an icon for support.
- Ensure button labels are as short as possible while explaining what happens when the button is selected.
- Button labels should be no longer than three words.
- To help keep label length reasonable, consider adding descriptive copy prior to the action.
Do: Be clear and descriptive
Don't: Use ambiguous labels
- Always use sentence case and start with a verb wherever possible. Avoid title case and all caps.
Do: Use sentence case
Don't: Use title case or all caps
Buttons should be aligned depending on context:
- For single page forms, left-align buttons and sort by importance from left to right.
- When using buttons to help a user move through a series of stepped screens, right-align the primary button to visually support the intended direction.
- When using buttons in a warning, confirmation, or other modal context, right-align the primary button.
- Buttons may be placed to the right of single-input forms including forgot password and subscription sign up.
Do: Left align the primary button on single action forms
Do: Right align the primary button on multi-step forms
- Buttons should be wide enough to accommodate the label while maintaining consistent label padding. Exceptions to this rule are block-level buttons and when buttons are stacked.
- Stacked buttons should always be the same width, regardless of the label.
Do: Ensure stacked buttons are the same width
Don't: Use varying widths when buttons are stacked
Use this strong button to highlight primary actions on a screen, like the ‘submit’ button on a form, or other actions that are critical in a workflow or process. There should only be one primary button per screen but not every screen requires a primary button.
Use this standard button in most cases where a button is required and especially where there are likely to be multiple buttons on a screen and/or when a primary button isn’t required.
Secondary outline button
Use this outline button in isolation, for less prominent actions, or paired with a primary or secondary button. Use of a secondary outline button assumes that the screen already has a primary or secondary button.
Use this button for non-essential actions or where the styling of the secondary outline doesn’t work. This button should not be paired with the primary or secondary buttons.
Use link buttons to navigate to another page or screen where a button is too strong or doesn’t fit. These buttons can also be used to represent the opposite action of a primary or secondary button, like ‘Cancel’ on a form or modal.
Use the default size in most cases. Use small buttons in tables and/or for supplemental actions. Use large buttons only on larger, isolated screens where a single element (like an image) dominates the viewport. Add
.btn-sm for these additional sizes.
A block-level button uses 100% of the available width of the container or parent element. A block-level button is used for visual prominence and is especially effective on mobile views. Create block level button by adding
Buttons with icons
Add the class
icon-link to your button or link to add icons to your buttons. Icons should only be used as support.
Do: Accompany icons with labels
Don't: Use icons without labels
An exception to the above is the search icon, which can be used on a button without a label when combined with a search field.
.btn classes are designed to be used with the
<button> element. However, you can also use these classes on
<input> elements (though some browsers may apply a slightly different rendering).
When using button classes on
<a> elements that are used to trigger in-page functionality (like collapsing content), rather than linking to new pages or sections within the current page, these links should be given a
role="button" to appropriately convey their purpose to assistive technologies such as screen readers.
Buttons will appear pressed (with a darker background, and darker border) when active. There’s no need to add a class to
<button>s as they use a pseudo-class. However, you can still force the same active appearance with
.active (and include the
aria-pressed="true" attribute) should you need to replicate the state programmatically.
Disabled buttons communicate the possibility of action and should be the default on all forms until all required inputs have been completed.
Make buttons look inactive by adding the
disabled boolean attribute to any
Disabled buttons using the
<a> element behave a bit different:
<a>s don’t support the
disabledattribute, so you must add the
.disabledclass to make it visually appear disabled.
- Some future-friendly styles are included to disable all
pointer-eventson anchor buttons. In browsers which support that property, you won’t see the disabled cursor at all.
- Disabled buttons should include the
aria-disabled="true"attribute to indicate the state of the element to assistive technologies.
Link functionality caveat
.disabled class uses
pointer-events: none to try to disable the link functionality of
<a>s, but that CSS property is not yet standardized. In addition, even in browsers that do support
pointer-events: none, keyboard navigation remains unaffected, meaning that sighted keyboard users and users of assistive technologies will still be able to activate these links. So to be safe, add a