...
Buttons are used to help the users carry out important actions.
Types of buttons
There are four types of buttons: (1) primary-default, (2) secondary, (3) tertiary , and (4) icon-only. If there are multiple instances of the same button type (primary, secondary, tertiary) make sure to use clear and distinct labelling i.e. "save inspection data" instead of just "save". Make sure you use buttons and their types consistently throughout the entire application.
Primary-default
A solid system button that is and destructive. It’s important to remember that a button represents an action, whereas links navigate the user somewhere. Use of buttons, labels and their types should be consistent throughout the entire application. It’s important to note that buttons are not the same as links. For more information on button labels, see the section on buttons in the article on Content writing.
Types
Primary
Primary buttons are the main call-to-action (CTA) on a page. They are strategically positioned and visually distinct to help guide users toward the important action or way forward on a page. Primary buttons use the primary brand colour of the application that meet WCAG colour/contrast requirements. This button should include an icon as well as text as best practice, however it is not required in all situations. E.g. buttons like ‘update', 'cancel', 'submit' wouldn’t have icons, whereas 'edit', 'save', 'delete', 'print' should. Primary buttons feature a default, hover, and focused state (use the default browser focus attribute). Avoid using disabled buttons - use error validation instead.
There is only one primary button per button group. When positioned with a secondary button, the primary button appears on the left. On smaller devices (screen size of 320px), primary buttons become block-level elements and primary button appears on top. Avoid using multiple primary buttons on one page unless the page has equally important calls to action.
| Info |
|---|
Note that "cancel" or "exit" buttons should always be styled as Tertiary buttons (see below). |
...
Because of this, there should only ever be one primary button per page.
For a detailed explanation of how to use primary buttons, please see the Primary buttonsarticle.
Secondary
Secondary buttons are used for alternative, less important actions such as "previous/next" buttons or sub actions that are nested within the main operation. Secondary buttons in a form or the “cancel” button in a modal. They may be used more than once per button group. Secondary buttons use a more muted colour than primary buttons to deemphasize them. Secondary buttons need default, hover, and focused states.
| Note |
|---|
Exception: When using buttons for pagination − the "Next" button is considered the primary action button and appears on the right of the page but should still be styled as a secondary button. |
When positioned with a primary button, the secondary button appears on the right. On smaller devices, secondary buttons become block-level elements and appear below the primary button.
Be cautious when using multiple secondary buttons so the user is not confused about what they should do next. Instead, consider breaking up the content so that it doesn’t need multiple secondary buttons or use spacing/grouping to make it clearer for the user.
...
then once per page and are often paired with primary buttons.
For a detailed explanation of how to use secondary buttons, please see the Secondary buttons article.
Tertiary
Tertiary buttons are used for reduced-importance actions (that are not essential to the main task, such as "Edit", "Cancel“Favorite” and ", "Delete"). Tertiary buttons may be used more than once per button group and more than one tertiary button can be used on a single page. Tertiary buttons are styled like a hyperlink but must be labelled as a button. Tertiary buttons need default, hover, and focused states.
| Info |
|---|
"Cancel" or "exit" buttons should always be styled as Tertiary buttons. |
...
Icon-only
Icon-only buttons must only be used for globally understood icons (see table below); must use [aria-label]; must have hover tooltip indicating the name of the button so when the icon in hover and/or focus state, the user knows that the icon will do.
Minimum target area (clickable area) for icons is 48px by 48px with 12px of padding left/right and top/bottom. Icon itself should be approximately 24px by 24px. On desktop when the mouse and keyboard are the primary input methods, you can scale the icon down to 20px by 20px.
For a detailed explanation of how to use secondary buttons, please see the Tertiary buttonsarticle.
Destructive
Destructive buttons should be used sparingly to warn users of irreversible actions such as deleting data or canceling a request. Their use is meant to help further communicate to the user the importance of considering whether to proceed with the action they represent.
For a detailed explanation of how to use destructive buttons, please see the Destructive buttons article.
Icons
Icons can enhance the usability of buttons, making it easier to scan a page. They should only be used for common actions like save, print, or delete. It's important to choose globally recognized icons to ensure clarity. Research has shown the solid or filled icons are easier for users to recognize.
Icons should always be placed on the left of button text. Maintain a consistent button size of around 24px by 24px, with 12px padding. A great resource for free icons is the FontAwesome icon library. Another popular icon family is from Google’s Material Design. You can use other icon font families as long as the symbol clearly indicates the action. If in doubt, test with users or ask the design community.
Common Icons
Action | Icon | Example |
|---|---|---|
Save | Floppy disk |  |
Delete | Trash can |  |
Printer |  | |
Download | IT appliance with down arrow |  |
Upload | IT appliance with up arrow |  |
Sort in ascending/descending order (this icon should only be used directly beside a column header so users know what they are sorting e.g. Date) | Up/down arrows together |  |
Edit | Pencil and card |
...
 | ||
Filter | Funnel/ filter |  |
Home | House |  |
Settings | Cog/ gear |  |
Profile | Silhouette of a person |  |
Comment | Speech bubble |  |
Menu | Set of 3 horizontal lines |  |
Responsive design
In order to be inclusive to all users, we need to consider how our applications behave on smaller viewports. (For more information on viewports, see The viewport is the window to your site – Digital.gov.) While designing and building using responsive design principles will allow you to create an optimized layout for users accessing your application on smaller viewports, this is not the only benefit. This will also ensure you are supporting users with low vision who need to enlarge text by using the browser’s zoom function.
To help ensure the responsiveness of your applications, consider the following points when designing buttons:
Preservation of content - Content shouldn’t be removed or changed to view an application on a smaller screen size. Don’t change or remove the icons and/or text of a button when changing the size of the viewport.
Reflow strategy - Determine the breakpoints at which buttons will reflow and a strategy to maintain consistent placement across the application. For example, a button grouping with a primary and secondary button should reflow from being side-by-side on larger viewports to being stacked on smaller viewports. When side-by-side, the secondary button should be to the left of the primary. When stacked, the primary should be on top of the secondary.
Size - Buttons must maintain a minimum width of 160 px regardless of screen size. Increasing the width of buttons may make them easier to interact with on smaller viewports. To prevent text wrapping and ensure buttons don’t exceed the screen width, keep button text short and to the point. 25 characters or less is recommended.
Padding - Buttons must maintain sufficient padding. When positioned side-by-side on a large viewport, a minimum of 32 px of padding should be used. When stacked on a smaller viewport, a minimum of 24 px of padding should be used.
Once your design has been implemented, it’s important to test the functionality in various different viewports.
Technical specifications
Width of the button (minimum 160px) should be the size of the text label with additional padding:
24px internal padding on right and left sides of button text
16px internal padding on the top and bottom of button textUse 32px of horizontal spacing (white space) between buttons for desktop
Use 24px of vertical spacing (white space) between block-level buttons for mobile
All button text should be written in sentence case
Use a max of 25 characters with spaces
| Info |
|---|
It is important to consider the French translation when designing and placing buttons on an interface since French uses approximately 2.2x more characters than English. |