Anatomy
- Icon: The graphical symbol that represents the action or function
Usage Guidelines
When to use this component
- When complementary actions need to be provided in interfaces where space is limited and icons can clearly communicate the desired action.
- In toolbars, headers, or dense layouts where text labels could create visual clutter but the action is easily recognizable through iconography.
- For secondary actions that support the main content.
- In repeated UI patterns like tables, lists or cards where consistent iconography helps users quickly scan and interact with multiple items.
When not to use this component
- As the primary call-to-action on a page or in critical user flows where the action must be immediately obvious to all users.
- When the icon meaning is ambiguous or not universally understood, requiring users to guess the action.
-
For complex actions that benefit from descriptive text labels to reduce cognitive load.
Best Practices
Use secondary as the default icon color for this component.
Do not use an icon that does not drive a clear and direct action.
Use it where text labels don’t fit. Remember always to add an aria-label.
Do not display more than 5 buttons in a row. Be conscious of the number of options and the space available. To avoid that cognitive load, use a Dropdown instead.
Don't modify the icon size and avoid combining Icon Buttons with different icon sizes. This is not supported in code and can generate inconsistencies in the interface.
States
There exist four different states for tabs:
- Default: The standard style when the Button is available for interaction
- Hover: Visual color feedback when users move their cursor over the button
- Active: Brief visual indication when the button is being clicked or tapped
- Focused: Visual indicator (focus ring) when the button receives keyboard focus
Where's the disabled button?
We have made the conscious decision to not provide a disabled button for now. We firmly believe that most of the solutions that use a disabled button can be solved in many other simpler ways, for instance, by using validation, progressive disclosure, or lowering the actions per page to reduce the cognitive load. We enforce this for a few reasons:
- Using disabled buttons makes us wonder why the button is not available and how to enable it. This requires explicit explanation and therefore increases the complexity of the screen (we cannot just forbid the action and not explain what is happening).
- Showing disabled buttons when they cannot be enabled in any way is frustrating. It clutters the interface and confuses us since a solution is not possible.
- Accessibility. It’s also a silent agreement that a disabled button has a very poor contrast. Disabled buttons could additionally be confused with secondary or plain buttons and just make the whole experience only accessible to the ones that can see the difference.
Styles
Default
Accent
Danger
Known Gaps
- Accessibility Guidelines
- To have disabled states or not to have disabled states