Buttons

Updated May 23, 2026

Overview

A button allows the user to perform a single action such as Save, Edit, Export, Delete, or Cancel.
Some buttons trigger a popover menu to present more than 1 action.
All buttons should have a short label that clearly indicates the action they will trigger.

Button icon placement

Icons can be placed either to the left or to the right of the button label.

Left (default)

Right

Warning

Accessibility considerations If the icon is purely decorative (a visual cue like a magnifying glass for "Search"), place it on the left. If the icon is meaningful or accessible (it contributes to the button’s label or function), place it on the right. Do not place it alone or on the left, as this can interfere with speech recognition software. Users relying on speech input may be forced to guess or say the icon’s name to trigger the button (for example, "Click arrow" instead of "Submit"). Instead, place the icon after the label (on the right) or ensure the button has a clear accessible label (for example, aria-label="Submit").

Icon-only buttons

Only a few universally recognized icons can be used alone without impacting accessibility. For example, the Home icon or the Close icon (X) in modals.
For all other icons, always include a clear label or accessible text to ensure usability for all users.
See the Accessibly tab for more information on Best Practices for Icon-Only Buttons.

Button: icon-only

Action popover: icon-only

Toggle group: icon-only

Component	Use when	Behavior	Best for
Action popover button	You want to offer contextual actions related to a specific item or element, without navigating away.	Clicking the button opens a small overlay (popover) with related actions positioned near the triggering element.	Providing contextual choices without disrupting the main flow or taking up layout space.
Multi-action button	You want to present 2–5 equally important, related actions in a compact format.	Clicking the button reveals a list of equally weighted options, there’s no default or primary action.	Scenarios where users must actively choose from a set of related actions, and space is limited.
Split button	One action is clearly the primary or most commonly used, but you want to give users access to secondary actions.	The left side triggers the primary action immediately; the right-side dropdown arrow reveals additional options.	Saving time by exposing a default action, while still offering alternatives.

Action popover menu example: right and left-aligned

Edge case example: menu opens upward

Button layout

In general, buttons should be laid out from left to right (or top to bottom) in the following order:

Lowest emphasis buttons first.
Highest emphasis buttons last, where possible.
For example, when a form has a 'Cancel' and a 'Save' button, 'Cancel' comes first as a low emphasis button, followed by 'Save' as a high emphasis button.

Horizontal

Vertical

Dos and don'ts

Labels

State what happens

A button label should indicate the action that happens when users select the button. Use the same word or phrase found in other parts of the experience.

Be concise, but prioritize clarity

Make button labels as short as possible without compromising clarity.

Use 1-2 words, and no more than 3 words, if possible.
Don't use punctuation, such as periods, exclamation points, or commas.
Avoid unnecessary words and articles, like the, an, or a.
Use fewer than 20 characters, including spaces.

In other words, make every character audition. If the meaning is still clear without a word, phrase, or punctuation mark, don't include it. If you need to add something back to bring back clarity, that's okay. Clarity always trumps brevity.

Consider translation

Find the maximum number of characters that can be displayed and make sure the English label leaves enough space for longer languages.

Communicate the restrictions to translators.

Use sentence case

Always use sentence case capitalization, which means capitalize only the first letter of the first word, except for proper nouns like trademarks and place names. Never use all caps for emphasis.

Make the first word a verb

Button labels should always lead with a strong verb that indicates what happens when users select the button.

Note: Because Draft is more commonly used as a noun, using it as a verb could create confusion for English readers as well as for translation teams. The Draft with Copilot pattern is an exception

Use the right tone

Avoid emojis and exclamation points to keep buttons as functional and scannable as possible. This helps minimize distractions for users.

Use consistent terminology

Use consistent button labels across products.

OK and Done

It's best to avoid using OK or Done except in a few use cases.

You can use OK when the only action is to read and dismiss the message.
You can use Done when a series of steps is complete or when agreeing to terms.

Requirements

Best Practices for Icon-Only Buttons

Provide a Descriptive Accessible Label
Use aria-label, aria-labelledby, or visually hidden text (.sr-only) to describe the button’s purpose.
Example:

...

Do Not Rely on Tooltip
Tooltips (like title attributes) are not consistently supported across assistive tech or touch devices.
Always use a screen reader-friendly label.
Use Semantic Elements
This ensures keyboard and screen reader compatibility out of the box.
Avoid using or as buttons unless absolutely necessary and enhanced with proper ARIA roles and keyboard support.
Ensure Focus Visibility
Apply a clear focus style to make the button visually identifiable when using a keyboard.
Maintain Sufficient Color Contrast
The icon and any visible borders must meet WCAG contrast guidelines (typically 4.5:1 for normal text and UI components).
Support Keyboard Interactions
Users should be able to operate the button with the keyboard (Tab, Enter, and Space keys).
This is handled automatically with , but must be manually implemented if using non-semantic elements.
Indicate State and Behavior Clearly
If the button toggles something (e.g., mute/unmute), use aria-pressed, aria-expanded, or appropriate state indicators.
Example:

...

Use Consistent and Recognizable Icons
Use familiar icons (e.g., a magnifying glass for search) to reduce cognitive load.
If custom icons are used, ensure users understand their meaning.

Date	Changes
March 2026	Add additional guidance on when a menu could appear above a multi action button or action popover.
Jul 2025	Added new Multi-action button.Added comparison table for action button with options menu.Added guidance on button icon placement.
May 2025	Added a dedicated paragraph on Icon-only buttons under the 'Button Types' section.
March 2025	Updated FAB button related content.Updated FAB button page.
February 2025	Created Button overview page.Made other button-related pages subpages within the overview.Merged Button: layout page into the Button page.