Buttons are interactive elements which allow our users to perform an action. Multiple types are available for various use cases.
Depending on the device type buttons are generally fixed and right-aligned for desktops, and fluid on mobile screens. A fluid button has a larger selectable area and fills the width of its container. Fluid buttons exist as part of complementary components like forms or modals.
Each variant of the button serves a function and must be implemented consistently so that users know which action needs to be taken.
Buttons come in four different sizes: extra-small, small, medium (default) and large.
By default, the icon is placed to the left of the label. Alternatively, it can be placed to the right.
Button text should be concise. Use between one and four words, with fewer than 20 characters and spaces. Don’t use punctuation marks such as full stops or exclamation marks.
Button text should always be in sentence case. Never capitalise letters to emphasise a specific button.
A button represents an action, so its label needs to be a verb to reflect what the button will do. Be specific rather than generic. Labels written as nouns or adjectives can be unclear and confusing.
Ensure that a button label is precise about the outcome of the action it represents. Be consistent with the word or phrase used on button labels throughout.
Tooltip when a label is hidden When the button label is hidden, show a tooltip that displays the label text on hover.
When the button text is too long for the horizontal space, it wraps to form another line.
Medium-sized buttons are the most frequently used option. Use the other sizes sparingly to create a hierarchy of importance within the page. Touch screens Use large buttons to increase the tappable area.
Aim to create a visual order between buttons. Using a single high-emphasis button communicates that other buttons are less important in the visual order. A single high-emphasis button focuses maximum attention from your users.
Use medium and low-emphasis buttons to initiate less significant tasks, and pair them with a high-emphasis button. Only complement CTAs if there is a striking relationship between them.
Use for banner CTAs, in-page forms, and nested buttons in components such as cards.
Use for inline alerts, inline field buttons, progressive forms, wizards, data tables and modals.
Use full-span buttons when width is limited, and/or to increase the interactive area, for example in drawers, modals and cards.
Shell DS components are programmatically determinable with appropriate semantic markup and are designed to meet colour contrast requirements. If you’re not using Shell DS code, you will need to cover the accessibility considerations for each component in this pattern.
Button labels must be clearly identified by words which make sense to screen reader users.
All users must be able to use the keyboard to press buttons via the enter or space keys.
Every effort has been made to ensure that the Shell Design System follows accessibility best practice.
The Shell DS React framework incorporates keyboard operation to support the widest variety of assistive technologies and devices. For any future frameworks other than React, accessibility will need to be reviewed.
Help us to help you by contacting the Accessibility team for support and information regarding any questions relating to accessibility.
Is this page useful for you?
Your feedback helps to improve our documentation.