Button

Buttons signal actions: something will happen when people activate the control. Use them to make primary and secondary tasks obvious on pages, cards, heroes, and in overlays. People should always understand what happens next from the label and the visual weight of the control.

On many pages, controls that look like buttons are implemented as styled links when the action is really navigation to another URL. Native button behaviour still applies where the platform uses real buttons for submit, search, tabs, or accordions. The important distinction for authors and designers is outcome: navigation versus an action on the current screen (see Links and buttons below).

Primary actions should stand out; secondary and tertiary actions should look quieter so people can choose quickly without competing noise. Focus must stay visible for keyboard users on every style.

Controls that navigate should behave like links (including predictable destination, open-in-new-tab only when clearly intended). Controls that submit or toggle something on the spot should behave like buttons. Do not mix these meanings with misleading labels.

1. Label: the words (or accessible name) that describe the action.
2. Surface: solid, outline, or minimal text treatment that shows emphasis.
3. Optional icon when the pattern calls for a quick visual cue.

Replace with primary, secondary, and ghost examples.

• Use verb-first labels: Apply, Download, Register, Sign in.
• Use sentence case unless the label is a proper name.
• Match the destination or outcome: the label should fit what people see or experience after they activate the control.
• If the visible label is short, add a clearer accessible name only when screen reader users would lack context (see Accessibility).

We sometimes style an anchor like a button so it matches the rest of the UI. It still navigates like a link. A real button is for actions on the current page (submit a form, open a panel, run a control). If the only job is to go somewhere else, a text link or standard link styling may be clearer than a loud button.

• Calls to action on pages, cards, heroes, and modals when the task is clear.
• Form submission, search, or continue steps when emphasis should match task priority.

• Long lists of navigation destinations; use Link or link lists so the page does not look like a wall of buttons.
• When a quiet text link is enough for secondary navigation.

Do

• Aim for one primary button per screen or modal when possible.
• Group related actions; separate unrelated actions with spacing or layout.
• Give external or unfamiliar destinations clear visible text; add extra context in an accessible name only when the visible label cannot stand alone.
• On narrow screens, stack actions instead of squeezing many buttons in one row.

Don't

• Use a button look for pure in-page navigation when a link is more honest.
• Choose style based only on label length; match importance of the task.
• Place more than three competing actions in a tight row on simple flows without testing mobile.