Button

A button initiates an action when clicked, like redirecting to a new page or submitting a form. It's a key element for interaction and action.

UsageCodeAccessibility

Button

<sl-button fill="solid" variant="primary" size="md">Button</sl-button>

When to use

Buttons should be used in user interfaces when you want to provide users with a clear and actionable way to interact with a webpage, application, or device. Here are some common scenarios when you should use buttons:

To Initiate Actions

Buttons are used to trigger specific actions or functions. For example, you can use a "Submit" button in a form to send user input to a server, or a "Save" button to save changes in an application.

When not to use

When creating a navigation menu, such as a dropdown menu or a side menu, using text links or icons is typically more common and efficient. Buttons can make menus look bulky and less streamlined.

Anatomy

ItemNameDescriptionOptional
1Text labelA button's text label acts as a concise but powerful message, informing users of the action triggered by a click or tap. It serves as the button's voice, delivering clarity and guidance in a few well-chosen words.yes
2ContainerThe container of a button is its home, providing structure and placement within the user interface. It ensures the button is visually pleasing, strategically positioned, and accessible to users.no
3IconThe icon of a button is like a visual cue, conveying meaning and enhancing user understanding. It's a compact symbol that complements the button's text, adding an extra layer of context or functionality.yes

Types

Solid

Solid (Essential)

Solid buttons are essential; they're necessary to move forward in the user flow. They emphasize critical actions, ensuring users respond quickly and understand what to do.

Outline

Outline (Important, but not essential)

Outline buttons are important, but not essential in a user interface. Unlike solid buttons, outline buttons are optional in a user flow; they draw attention to certain actions but don't block progression.

Ghost

Ghost 👻 (Suggest)

Ghost buttons discreetly suggest actions or options in a user interface. They're employed for advanced functionality, offering choices or recommendations without being essential or distracting from the user flow. Ghost buttons are ideal for suggesting secondary actions or guiding users to less emphasized but relevant interactions.

Link

Link buttons are there to help users find more information or related content without being intrusive. They're great for actions like "Read More" or "View Details" when you want to provide extra details without cluttering the interface. They enhance user exploration while keeping the interface clean and minimalist.

Variants

Take a look at our button options designed for different user needs and situations. They enhance user experiences for everyday actions and critical decisions. Check out our default, primary, success, warning, and danger button variants in our overview.

Primary

Primary

Primary buttons are like the interface's guiding stars, drawing immediate attention to critical actions. They're best used for the primary user flow, making them stand out for important tasks.

Default

Default

These buttons stand below the primary button in the hierarchy. They serve well in secondary user flows on a page, such as adding an extra timeslot, or additional feedback when marking students' work.
When there is no clear hierarchy in user flows on the page (for example a dashboard or overview page) this is your go-to button.

Success

Success

Success buttons act as digital applause, marking successful task completion and enhancing the user experience. This addition can effectively communicate achievement and contribute to overall user satisfaction.

Warning

Warning

A warning button signals the need for careful consideration and double-checking. Its purpose is to prevent unintended actions and confirm the right choice.

Danger

Danger

The danger button is a clear warning of risky actions, typically associated with irreversible outcomes or significant data loss

Types vs Variants

This table provides guidance on when to use each button variant (Solid, Outline, Ghost, and Link) for different button types, considering their specific characteristics and purposes in user interface design.

VariantsSolidOutlineGhostLink
PrimaryUsed to move forward in a primary (the most important) user flow.For secondary actions related to the primary user flow.To give suggestive actions related to the primary user flow.To give information related to the primary user flow.
DefaultUsed to move forward in a secondary user flow or when there is no specific user flow.For secondary actions related to the secondary user flow.To give suggestive actions related to the secondary user flow.To give information related to the secondary user flow
SuccessFor actions confirming successful operations.For secondary actions related to the successful operation.To give suggestive actions related to the successful operation.To give information related to the successful operation.
WarningFor actions requiring caution or user confirmation.For secondary actions related to the warning.To give suggestions related to the warning.To give information related to the warning user flow.
DangerFor actions confirming potentially negative consequences.For secondary actions related to potentially negative consequences.To give suggestions related to potentially negative consequences.To give information related to potentially negative consequences.

Example

Here's an example that explains which button to use in different scenarios:

  1. The "Remove" button should be Danger-Outline; it's a secondary action and not part of the main user flow on this page.
  2. The "Upload CSV" button should be Default-Outline; although it's not part of the main user flow, it requires emphasis.
  3. The "Confirm Participants" button should be Primary-Solid; it represents the next step in the user flow and the primary reason the user is on this page.
  4. Add a "Cancel" or "Back" button, which should be Primary-Outline; it's part of the main user flow but a secondary action.

Figma Options

With these options you can tweak the appearance of the button in Figma. They are available in the Design Panel so you can compose the button to exactly fit the user experience need for the uses case you are working on.

ItemOptionsDescription
Typesolid outline ghost linkThere are four button types to choose from so you can differentiate between buttons, depending on how essential they are.
More info about button types
Variantdefault primary success warning danger infoIndicates the variant of the button.
More info about button variants
Sizesmall medium largeThe button is available in three sizes. If not specified the default value is medium.
Iconstart endIndictes the position of the icon.
LabeltextValue of the button.
Icon onlybooleanIndicates if it is an icon only button.

Behavior

Mouse Interaction

Users can activate a button by clicking anywhere within the button container.

Tooltip When Label is Hidden

When the button label is concealed, a tooltip appears on hover, revealing the label text and, when applicable, a keyboard shortcut.

Transition

Hover and Active State Transitions: When users hover over a button or the button is in an active state, the background color and/or border color smoothly transition to provide visual feedback.

DefaultPrimarySuccessWarningDanger
<sl-button fill="solid" size="md">Default</sl-button>
<sl-button fill="solid" size="md" variant="primary">Primary</sl-button>
<sl-button fill="solid" size="md" variant="success">Success</sl-button>
<sl-button fill="solid" size="md" variant="warning">Warning</sl-button>
<sl-button fill="solid" size="md" variant="danger">Danger</sl-button>

API

The SL Design System button can be used to replace the default HTML button. We've tried our best to mimic all the behaviours and options you get when using a standard button. But this one looks a lot nicer!

Properties

NameAttributeTypeDefaultDescription
disableddisabledboolean | undefinedWhether the button is disabled; when set no interaction is possible.
fillfill'solid' | 'outline' | 'link' | 'ghost' | undefinedsolidThe fill of the button.
shapeshape'square' | 'pill' | undefinedsquareThe shape of the button.
sizesize'sm' | 'md' | 'lg' | undefined'md'The size of the button.
typetype'button' | 'reset' | 'submit' | undefinedbuttonThe type of the button. Can be used to mimic the functionality of submit and reset buttons in native HTML buttons.
variantvariant'primary' | 'secondary' | 'success' | 'info' | 'warning' | 'danger' | 'inverted' | undefinedsecondaryThe variant of the button.

Slots

NameDescription
defaultText label of the button. Optionally an <code>sl-icon</code> can be added
Exploring essential accessibility considerations for buttons: ensuring an inclusive user experience.

Content

Having an accessible application is not only achieved by writing good code, but also (maybe even MORE so) by writing good copy. To make sure buttons and their actions are clear for all users make sure to keep these points in mind:

Concise Clarity

Button text should be brief, ideally 1 or 2 words, and at most 4 words with fewer than 20 characters, spaces included. Avoid punctuation like periods or exclamation points.

Action-Centric

Buttons should express actions, using verbs in their labels and a bare infinitive conjunction. This approach enhances clarity and user orientation.

Clear Outcomes

The button's label should unmistakably convey the action's result, mirroring the wording elsewhere in the experience.

Sentence Case

Always use sentence case for button text; capitalization should not be used for emphasis.

Mindful Tone

Buttons serve a functional purpose, so emojis and exclamation points should be left behind. Keep labels as plain text, free from extra punctuation or embellishments.

Keyboard Interaction

When the button has focus:

  • Space: Activates the button.
  • Enter: Activates the button.
  • Following button activation, the focus is set depending on the type of action the button performs. For example:
    • If activating the button opens a dialog, the focus moves inside the dialog.
    • If activating the button closes a dialog, focus typically returns to the button that opened the dialog unless the function performed in the dialog context logically leads to a different element. For example, activating a cancel button in a dialog returns focus to the button that opened the dialog. However, if the dialog were confirming the action of deleting the page from which it was opened, the focus would logically move to a new context.
    • If activating the button does not dismiss the current context, focus typically remains on the button after activation, e.g., an Apply or Recalculate button.
    • If the button action indicates a context change, such as move to next step in a wizard or add another search criteria, then it is often appropriate to move focus to the starting point for that action.

WAI-ARIA

In the component itself we use multiple aria-attributes to assure the component works well with a range of assistive technologies. For some attributes however it is not possible for the Design System to add a meaningful value, because it relies on the context or way a component is used.

Attributes that we recommend you add in certain scenarios are mentioned below.

AttributeValueDescription
aria-labelledbystringWhen different element serves as the label, for example in the case of an icon-only button that has a label outside the button, this property can be set to the id of that element
aria-labelstringTo be used when the button is icon-only
aria-describedbystringWhen the button needs extra explanation or description you can reference this element here by the id. See [Note 1] below for more explanation.
aria-disabledbooleanAnnounces the button as disabled with a screenreader. See [Note 2] below for more explanation
aria-pressedbooleanWhen the button is used as a toggle and is toggled on, the value of this state is true, and when toggled off, the state is false.

Notes:

  1. There is a subtle difference between aria-labelledby and aria-describedby; a label should be concise, where a description is intended to provide more verbose information. A description can for example be "Items in the trash will be permanently removed after 30 days." to explain what (delayed) effect a "Move to trash" button has.

  2. The aria-disabled="true" attribute should not be used as a one-for-one replacement for the disabled attribute because they have different functionalities.

    Both:

    • visually dim the button
    • prevent actions (click, enter/space) on the button
    • announce the button as 'dimmed' or 'disabled' in a screenreader

    However, there are some differences:

    • disabled takes the button out of the tab-focus sequence, aria-disabled does not
    • disabled disables all pointer events, aria-disabled does not

    The difference can be useful when you want to combine a disabled button with a tooltip. In that case you want the button to be focusable (so you can hover or tab to it) but you also want it to be dimmed and not clickable. In that case you would use aria-disabled instead of disabled.

    When disabled is added to a button there is no need to also add aria-disabled; Everything aria-disabled does, disabled does as well.

    You can read more on the difference and in which scenarios which option might be preferable on the MDN page about aria-disabled

Interactive example