Overview
A button communicates an action that happens in the current context. Its label should set a clear expectation of the result.
Default button
Use the filled variant for the primary action in a focused area.
Choose button emphasis based on action priority, not visual preference. Most surfaces need one primary action and a small number of supporting actions.
Anatomy
A button has a container, an action label, and optional supporting icons. The label is always the accessible name.
- 1ContainerRequired
Defines emphasis, boundary, target size, and interaction states.
- 2Leading icon
Optional symbol that reinforces the action. Never replaces the label.
- 3LabelRequired
Uses a short verb phrase that describes the outcome.
- 4Trailing icon
Optional directional cue for progression or disclosure.
When to use
Use a button for clear, immediate actions that operate within the current task or surface.
Recommended
- Submit or confirm a task
Save a form, create an item, apply changes, or confirm a decision.
- Reveal an interface
Open a dialog, menu, drawer, file picker, or another interactive layer.
- Trigger an operation
Refresh data, export a report, run a check, or retry a failed request.
When not to use
Choose a more specific control when the interaction is navigation, selection, or a persistent setting.
Avoid
- Do not use for navigation
Use a link when people move to another page, route, or external destination.
- Do not use as a checkbox or switch
Use a selection control when the interface must communicate a persistent value.
- Do not overload a surface
Too many competing buttons hide priority. Move secondary actions into menus or quieter controls.
Variants
Variants create an intentional hierarchy. Select the quietest treatment that still communicates the action’s importance.
Emphasis hierarchy
Filled is highest emphasis; text is lowest emphasis.
Filled
Primary action in a focused area. Usually one per section or decision point.
Outlined
Supporting action that needs a visible boundary without competing with primary.
Tonal
Moderate emphasis for common actions on neutral surfaces.
Text
Low-emphasis action used in compact or content-heavy contexts.
States
States provide immediate feedback about availability, focus, progress, and completion.
Operational states
Loading blocks repeated actions; success confirms completion; disabled communicates unavailability.
| State | Trigger | Visual response | Interaction |
|---|---|---|---|
| Default | No interaction | Base container and label colors | Ready to receive focus or activation |
| Hover | Pointer rests over button | State layer increases emphasis | Cursor indicates an actionable control |
| Focus | Keyboard or assistive input | High-contrast focus ring | Enter or Space activates the action |
| Pressed | Pointer or key is held | Pressed state layer | Action fires once on release |
| Loading | Action is in progress | Spinner replaces or accompanies content | Repeated activation is blocked |
| Disabled | Action is unavailable | Reduced emphasis | Removed from activation behavior |
Behavior
Button behavior must remain predictable across input methods, async actions, and responsive layouts.
Activation
Fire one action per click, tap, Enter, or Space activation. Prevent accidental double submission.
Async actions
Show loading immediately, preserve the label context, and block duplicate activation until completion.
Responsive width
Keep intrinsic width by default. Use full width for narrow forms and stacked mobile actions.
Focus continuity
Keep focus on the button after non-navigational actions unless a new modal context requires focus transfer.
Accessibility
Buttons use native button semantics so keyboard, screen-reader, and alternative-input behavior works consistently.
| Key | Action |
|---|---|
| Tab | Moves focus to the button when it is available. |
| Enter | Activates the focused button. |
| Space | Activates the focused button on key release. |
- Use a visible text label that describes the outcome.
- Keep decorative icons hidden from the accessibility tree.
- Preserve a visible focus ring in every visual variant.
- Do not communicate state through color alone.
- Use disabled only when the action truly cannot run.
- Announce async completion or errors in the surrounding workflow when needed.
Content guidelines
Button labels should be concise, specific, and written from the user’s point of view.
Start with a verb
Describe the action directly instead of naming the object alone.
Create project
Name the outcome
Use specific labels when generic words could make people hesitate.
Send invitation
Use sentence case
Capitalize the first word and proper nouns. Avoid title case and punctuation.
Save changes
Keep labels stable
Loading feedback should preserve enough context to identify the action in progress.
Saving changes
Examples
Compose icons, state, and width only when they improve comprehension or fit the surrounding workflow.
Product actions
Realistic actions across creation, export, progression, and async feedback.
Responsive form action
Full-width buttons work well at the bottom of narrow forms.
Props / API
Button extends native button attributes. Forward event handlers, data attributes, and ARIA attributes as needed.
Props