Button
Buttons communicate actions that users can take throughout your portal which can be used in places such as modals, forms and cards
Example
Default button
Variants
primary
to quickly created styled buttons. Some of the outline buttons, btn-outline-light
in particular, should be used on a darker background for sufficient color contrast.Sizes
btn-sm
if you want to use the small sized button.Block buttons
Disabled buttons
disabled
class to created disabled buttons.Icon buttons
Anatomy
- Icon (situational): Serves to give more context to the button. E.g a plus icon to indicate addition or creation.
- Text: Serves to tell users what the button is being used for. Length of the text is expandable.
- Container: Takes on the length of the text within the button while maintaing spacing of the overall button.
Spacing
Within the button
Ensure that there is a min of 8px vertical spacing and 16px horizontal spacing within the button.
Base height
Button size | Height | Button class |
---|---|---|
Small | 38px | .btn-sm |
Default | 48px | .btn
|
Large | 58px | .btn-lg |
Usage guidelines
Best practices:
- Fluid components like button never exist in isolation. They are always part of another component, like modal or form.
- Use a visual hierarchy to differentiate between primary actions (e.g., "Submit"), secondary actions (e.g., "Cancel"), and tertiary actions (e.g., "Learn more").
Buttons should be used when:
- Initiating an action: Use buttons for actions such as submitting a form, saving data, or navigating to another page. Buttons signal that user interaction is required to complete a task.
Buttons should not be used when:
- The purpose is purely to navigate to another page or section, use a hyperlink instead of a button. Links are better suited for navigation, while buttons are for actions.
- There are too many buttons on the screen, it can overwhelm users.
Usability guidelines
Use primary buttons for actions that go to the next step or for submission
This makes it clear to the user that a action will happen when they click on the button.
Use outline or secondary buttons for secondary actions
This will help differentiate it from primary action buttons.
Ensure buttons look clickable
Do ensure that hover and active states are clear to the user from its static state.
Avoid using too many buttons
Buttons should be reserved mainly primary actions the users is supposed to take within a page.
E.g on a form you may use 3 buttons, 1 primary and 2 secondary but text links for actions within the page.
Keep text within button short
Text should be as short as possible and with action text to allow the user to easily understand what will happen when the button is clicked.
E.g Submit, Next or Download.
Behaviour
Ensure button’s hover, active and disabled states are clear to the user from its default state.
Accessibility guidelines
Aria attributes
-
The
button
has an accessible label. By default, the accessible name is computed from any text content inside the button element. However, it can also be provided witharia-labelledby
oraria-label
. -
If a description of the button's function is present, the button element has
aria-describedby
set to the ID of the element containing the description.
Keyboard accessibility
Users should be able to navigate between buttons using standard keyboard controls:- Tab or Shift-Tab to navigate between buttons.
- Enter or Space to activate button.
Focus indicator
- Provide a clear visual indication when the button is focused, such as using the focused state.
- Ensure that the button receives focus when the page loads or when it becomes visible.
- Button is to be included in the natural tab order of the page and can be focused using the keyboard.
Button design tokens
Last updated 02 October 2024