Buttons are used to initiate actions within an application, website, or other digital experience. Their labels clearly describe the action they trigger.
| PublishedElement can be used in production | |
| PublishedElement can be used in production | |
| PublishedElement can be used in production | |
React | In progressElement design and development in progress |
Documentation | PublishedElement can be used in production |
The button component has been redesigned to the updated font ramp and color palette, in addition to accessibility enhancements, and now includes four sizes.
Buttons are clickable interface components that initiate an action or trigger a change in state. They are not decorative elements. Instead, they direct users to complete important goals within an experience.
| Component | Use case |
|---|---|
| Button | Use to trigger an action on a page or to complete tasks in other components, such as forms and modals. Exception: “Back” and “Next” buttons may be used to navigate a guided experience. |
| Link | Use to navigate a user to another page or website, another place on the same page, or to open a link in a new tab. |
Buttons can contain up to three elements:
A single screen in an application or web experience can include more than one button. Let the desired action determine the button usage and combinations.
Buttons are often used to trigger additional elements or work flows, such as modals and drawers.
A primary button labeled “Sign In” and a secondary button labeled “Create an Account.”
Settings allow users to configure the appearance or actions in an application to better suit their needs. Buttons are used to save and apply configurations for accounts, users, and notification preferences.
Multi-page forms and experiences necessitate more than a “Submit” button. Users need the ability to navigate the entire form and save progress. Multiple buttons may be shown at the same time, such as “Next” and “Back”, with a primary button used to denote the desired user action. Less critical actions may be shown as secondary or tertiary buttons.
A single screen in an application or web experience can include more than one button. To help users clearly understand primary, secondary, and tertiary actions, use caution in button placement. Let the action you want to trigger determine the correct button to choose.
| Kind | Use case |
|---|---|
| Primary | Save primary buttons for the most important call-to-action (CTA), usually related to the user’s main goal. Aim for one primary action per screen, section, or container to eliminate confusion. |
| Secondary | Secondary buttons are for regular, nonprimary actions. You may use several per screen. |
| Tertiary | Also called ghost buttons, tertiary buttons have the least emphasis and should be used for the lowest-priority actions. Often used in a group of three buttons where tertiary is the lowest priority, or paired with a primary button to indicate an optional action, such as “Save” (primary) and “Edit” (tertiary). |
There are three options for placing icons within buttons. Use only one icon per button. Note that text within a button will expand to the right, even with the icon-left button.
With icon, right : Use when the icon implies that pressing the button will bring the user forward, such as “Next.”
With icon, left: Use when the icon implies that pressing the button will bring the user backward, such as “Back.”
Icon-only: Use only when the user’s action is very clear and doesn’t need explanatory text. Examples include down and next arrows.
Button colors are limited to defined semantic usage, including default (blue), editorial (neutral light and dark), transactional (green), and destructive (red). Other color palettes are not available for use with buttons. Remember that color is not a universal experience, and usage should not rely on color alone to convey meaning. Use clear, concise labels or icons to improve recognition and understanding of the action a button triggers.
Buttons are available in four semantic colors: default, destructive, transactional, and editorial.
| Color | Use case |
|---|---|
| Default | Use a default button (Blue 600) in most cases, especially when brand alignment is warranted. This button is used for form submissions and most primary calls-to-action. Default buttons can be used throughout any experience and have multiple instances. |
| Destructive | Destructive buttons (Red 600) signal alarm. Use them to indicate that the action the user is about to take will remove content or otherwise result in data loss that cannot be reversed, such as “Delete.” |
| Transactional | Use a transactional button (Green 600) when presenting a choice or decision related to money or purchasing, such as “Add to Cart” or “Checkout.” Transactional buttons should be used sparingly and as an action to complete a transactional task flow. |
| Editorial | Use an editorial button (Gray 900 or White) alongside graphical content and colored or textured backgrounds where contrast could be an issue, such as part of a call-to-action or in banners or cards. |
The editorial button has light and dark modes to account for various background colors, patterns, and textures. Do not mix these modes.
Dark: The dark editorial button creates contrast against a light background.
Light: The light editorial button creates contrast against a dark background.
Buttons come in four sizes: large, medium (default), small, and mini. Buttons should match in size and match the relative width of the experience.
Keep in mind, buttons are responsive and will resize when transitioning from one breakpoint to another. Recommended breakpoint guidance for each button size applies to all grid densities and button variants.
| Size | Use case |
|---|---|
| Large | Use this size with larger viewports or heroes that need to draw attention to a call-to-action. Recommended breakpoints: L-12 and larger |
| Medium | This default size can be used in most cases, as long as you can maintain visual balance. Recommended breakpoints: M-6, L-12, XL-12 |
| Small | Use small buttons in compact areas where a default button would not fit, such as a small component. Recommended breakpoints: M-6 and smaller |
| Mini | Use mini buttons exclusively in tables to maximize horizontal space in cells. Recommended breakpoints: all table pixel ranges (review the sizes section on the table component page) |
Button groups are aligned according to their context. For most use cases, horizontally aligning button margins to the grid gutter will suffice. In general, button groups are left-aligned to follow content such as a block of text. For empty states, they are center-aligned. Use right alignment inside container components such as dialogs, popovers, or cards.
In most full pages or views, the primary button is on the left. This conventional placement in left-to-right languages helps the user anticipate the button’s location as they move through the page. In modals or multi-page forms, the primary button should be placed on the right, suggesting to the user that they are about to progress through a series of steps.
Full-page view with a left-aligned primary button.
Buttons can be implemented in two styles of responsiveness: flex and block.
Block: Block buttons are a static size and can be fixed to a certain width within a container, for instance, “Next” and “Back” buttons.
Flex: Flex buttons are fluid and resize responsively to match the width of the text.
When grouping buttons, the recommended space between each button should be a multiple of 4 pixels, horizontally and vertically (read more about the baseline grid on the grid foundations page). Specified margins for each button size are shown below. All units of measurement are in pixels. Between grouped or stacked buttons, the space between buttons is 20 pixels for large, 16 pixels for medium, 12 pixels for small, and 8 pixels for mini.
A group of small buttons with 12 pixels of padding.
A group of medium buttons with 16 pixels of padding.
A group of large buttons with 20 pixels of padding.
A stack of small buttons with 12 pixels of padding.
A stack of medium buttons with 16 pixels of padding.
A stack of large buttons with 20 pixels of padding.
Buttons are impacted by user interaction and show visual changes depending on the status of the interaction. Buttons communicate five states: rest, hover, press, inactive, and focus. The button state is reflected in its color and opacity.
| State | Behavior |
|---|---|
| Rest | When a user has not interacted with the button it will appear in its default, rest state. |
| Hover | When a user hovers their cursor over the button’s active area, the button changes color, indicating that it is able to be pressed. |
| Press | When a user presses the button, the button changes color, indicating the button is in the act of being pressed. |
| Inactive | Inactive buttons are displayed with 40% opacity, indicating the option exists but is not available to the user. |
| Focus | A blue outline appears around a button when a user tabs or uses keyboard controls to navigate. Focus states do not appear on inactive buttons. |
Do not mix the usage of buttons and links
Follow the guidance above regarding when to use each. Remember buttons are for triggering actions, not navigating. Misuse causes confusion for keyboard and screen reader users, who may hear them announced by the wrong role.
Make sure button labels are unique and descriptive
Labels like “Click Here” and “Read More” don’t provide context. In addition, some screen reader users also navigate through a list of all the buttons on a page or screen. Therefore, all button labels should provide an indication of what will happen if activated. For examples of acceptable labels, see the content standards section on this page.
WCAG 2.1: 1.3.1 Info and Relationships
Icon-only buttons should be used carefully and only after checking for accessibility
The meaning of the icon must be visually self-evident (easily and universally understood). In addition, a programmatically associated semantic label (such as an aria-label attribute) should be added so it can be read by screen readers. If you’re in any doubt that an icon-only button will be understood, use accompanying text in your button label.
WCAG 2.1: 1.3.1 Info and Relationships
All buttons except tertiary should have a contrast ratio of 3:1 or greater against the background, regardless of breakpoint or orientation (except if inactive)
Providing good contrast ratio on buttons ensures that anyone with low vision can see them and perceive their function. If the button variant doesn’t achieve adequate contrast with the background when viewed at a specific breakpoint, and/or in a particular orientation, either change the background or consider using a different button variant. The tertiary button is an exception and should have a 4.5:1 contrast with its background at all times.
WCAG 2.1: 1.4.11 Non-text Contrast
Tertiary buttons require a 4.5:1 contrast ratio against the background
Greater contrast is required because the text is the only part of the button that is visible. These buttons are therefore considered similar to text and will require a higher contrast ratio.
WCAG 2.1: 1.4.3 Contrast (Minimum), 1.4.11 Non-text Contrast
When possible, use medium or large variant buttons, rather than small
Small buttons (24-pixel height) meet the minimum touch target requirements to ensure adequate accessibility for people with fine motor control difficulties or limited dexterity. Medium buttons (40-pixel height) are much closer to the recommended size of 44px-by-44px, and large buttons (48-pixel height) exceed it. The easier touch targets these larger sizes present for are therefore preferable.
WCAG 2.2 (Proposed): 2.5.8 Target Size (Minimum)
Button labels
Button text should clearly explain the action users will take once selecting the button. Avoid ambiguity. This is important for accessibility, UX, and SEO.
Do: Learn About Services
Don’t: Learn More
Word length
Keep text succinct, fewer than three words, if possible.
Capitalization
Use title case and capitalize the first letter of each word except for articles and prepositions.
Do: Take a Product Tour
Don’t: Take a product tour
Use verbs first
Buttons trigger actions so start button labels with verbs. Exception: “Next” or “Back.”
Do: View Product Details
Don’t: List of Details
One action
Buttons should initiate only one action per label. Do not combine actions in a label.
Do: Save
Don’t: Save and Exit
Punctuation
Don’t include punctuation on button text.
Special characters
Don’t use special characters as part of button text.
Common button text for actions:
Add to Cart
Search
Cancel
Save
Exit
Edit
Delete
Continue
Next/Back
Submit
Select
Sign In/Sign Out
View Details
Okay/Cancel
Close
Keep keywords in mind when writing button copy to improve SEO, particularly for product pages.
Example: Shop Latitude Laptops
This demo lets you interact with the component and view the code. To see other interactive examples of this component or for additional developer documentation, visit Storybook.
<button class="dds__button">Shop All Deals</button>