Buttons allow users to perform an action or to navigate to another page. They have multiple styles for various needs, and are ideal for calling attention to where a user needs to do something in order to move forward in a flow.
All buttons require a label for accessibility. Unlike action buttons, these buttons should never be icon-only.
The call to action button communicates strong emphasis and is reserved for actions that are essential to an experience. There should only be one visible call to action button per section. There is no quiet style for this button because it is meant to be intentionally prominent.
The primary button is used for medium emphasis. It should be used in place of a call to action button when the action requires less prominence, or if there are multiple primary actions of the same importance on the page.
The secondary button is for low emphasis. It is meant to be paired with other button types to surface less prominent actions, and should never be the only button in a group.
The negative button is for emphasizing actions that can be destructive or have negative consequences if taken. It should be used sparingly.
When a button needs to be placed on top of a colored background or a visual, use the over background button. This button appears in static white regardless of color theme. Make sure the background offers enough contrast for the button to be legible.
Icons can be used in buttons when additional clarity is required. Icons should not be used for decoration.
Buttons come in four different sizes: small, medium, large, and extra-large. The medium size is the default and most frequent option. Use the other sizes sparingly; they should be used to create a hierarchy of importance within the page.
By default, buttons have a visible stroke. Quiet buttons do not have this visible stroke and should only be used for secondary actions within a button group. An exception to this is the call to action variant, which does not have a quiet style because it is meant to be intentionally prominent.
A button in a disabled state shows that an action exists, but is not available in that circumstance. This state can be used to maintain layout continuity and to communicate that an action may become available later.
From the design point of view, each component has a number of options. These options and their names are platform agnostic, and each implementation should adapt these to fit into their framework.
call to action / primary / secondary / negative / over background
|call to action|
icon / nothing
small / medium/ large / extra-large
yes / no
yes / no
A button can be navigated using a keyboard. The keyboard focus state takes the button’s visual hover state and adds a blue ring to the button in focus.
The width of a button automatically adjusts to fit the text. The padding on each side of the button is equal to half its height.
Standard buttons have a minimum width of 2.25× the height of the button. This guarantees that small buttons retain an identifiable shape. Quiet buttons do not have a minimum width; their width depends exclusively on the length of the text.
When the button text is too long for the horizontal space available, it wraps to form another line.
In Windows high contrast mode, buttons should be displayed using the high contrast theme-specified colors for buttons. By default, borders should be same as the button text color. In hover and keyboard focus states, a border should display as the button border color. In the disabled state, border, and text color should display as the disabled color.
Button text should be concise: 1 or 2 words, no longer than 4 words, with fewer than 20 characters including spaces. Don’t use punctuation marks such as periods or exclamation points.
Button texts should be clear about the outcome of the action. Most buttons should start with a verb. For example, use “Agree” instead of “Yes” in a dialog or use “Sign Up” instead of “Submit” in a form.
Button text should always be in sentence case. Capitalization should never be used to give more prominence to a specific button.
Do not use custom colors for buttons. The colors of different button variations have been designed to be consistent and accessible.
Icons can be used in buttons when additional clarity is required and the icon is highly relevant to the action. Icons should not be used for decoration.
In some instances, it is possible to have a call to action button display a popover (or tray) to feature subsequent options for the action. These options should extend a single action, and should not contain arbitrary menu items.
For RTL (right-to-left) languages, the layout of the button is mirrored. The icon is placed on the right side of the text.
|Space or Enter||Executes the button action. The focus remains on the button except if the button opens or closes the current container. In this case, the focus moves to the target or back to the caller.|
|Sep 29, 2020||5.3.0|
|Apr 29, 2020||5.2.0|
|Apr 13, 2020||5.1.1|
|Aug 22, 2019||5.1.0|
|Jul 31, 2019||5.0.2|
|Jun 13, 2019||5.0.1|
|Apr 20, 2019||5.0.0|
Includes all interactive states that are applicable (hover, down, focus, keyboard focus, disabled).
Works properly across all four color themes (lightest, light, dark, darkest).
Includes a desktop scale (UWP, macOS, web desktop) and a mobile scale (iOS, Android, web mobile).
Color is not used as the only visual means of conveying information (WCAG 2.0 1.4.1).
Text has a contrast ratio of at least 4.5:1 for small text and at least 3:1 for large text (WCAG 2.0 1.4.3).
Visual information required to identify components and states (except inactive components) has a contrast ratio of at least 3:1 (WCAG 2.1 1.4.11).
UI language and information design considerations have been incorporated into component design.
Includes relevant options (variant, style, size, orientation, optional iconography, decorations, selection, error state, etc.)
Includes guidelines for keyboard focus, layout (wrapping, truncation, overflow), animation, interactions, etc.
Includes a list of dos and don'ts that highlight best practices and common mistakes.
Includes content standards or usage guidelines for how to write or format in-product content for the component.
Works properly across various locales and includes guidelines for bi-directionality (RTL).
Follows WCAG 2.0 standards for keyboard accessibility guidelines and includes a description of the keyboard interactions.
All design attributes (color, typography, layout, animation, etc.) are available as design tokens.
Includes a downloadable XD file that shows multiple options, states, color themes, and platform scales.
Includes a downloadable XD file, generated by code using design tokens defined in Spectrum DNA, and shows multiple options, states, color themes, and platform scales.
Component is included in the Spectrum for Adobe XD plugin.