Overview

The Button component serves as a fundamental element in user interfaces, providing users with a clickable element to trigger actions or navigate within an application. It is essential for enhancing user interactivity and guiding them through the application flow.

Usage

Use the Button component whenever user interaction is necessary to initiate an action or navigate within the application. Examples include submitting forms, confirming actions, or navigating to different pages.

Guidelines

To effectively utilize the Button component, adhere to the following guidelines:

1. Clarity: Ensure the button text clearly indicates the action it performs.
2. Consistency: Maintain consistent styling and placement of buttons throughout the application.
3. Accessibility: Ensure the button is accessible to all users, including those who rely on assistive technologies.
4. Feedback: Provide visual feedback, such as hover effects or disabled states, to indicate interactivity.
5. Size and Placement: Choose an appropriate size and position for the button to ensure it is easily clickable and visible.

Objective

The Button component addresses the need for users to interact with the application by providing a clear and clickable element for initiating actions or navigation. Whether it's submitting a form, confirming a decision, or progressing through the application flow, the Button component plays a crucial role in enhancing user experience and facilitating smooth interaction.

Visual Representation

Layout (Spacing + Resize & Reflow)

Resize/Reflow

In UI design, a button is a basic, self-adjusting element that scales with its content but won’t shrink below a minimum size. Wireframes for resizing aren’t needed because it’s the responsibility of the higher-level layout to provide sufficient space for the button and the content responsibility to resize/reflow within the defined box.

States

Features/Configurations

The Button component is designed to be flexible and agnostic regarding the type of content placed inside it. However, we have tailored the component to seamlessly integrate with common scenarios, such as incorporating icons alongside text within the button.

The primary focus of the Button component is to ensure it functions effectively in various contexts. While other configurations may be necessary based on specific usage scenarios, they are often situational and closely tied to how the button is implemented within the application.

One notable configuration supported by the Button component is its adaptability to serve as a toggle button. This functionality can be achieved by orchestrating behaviors within the application according to the specific scenario. Our documentation portal provides comprehensive examples and guidelines on correctly implementing and orchestrating such scenarios, ensuring smooth integration and functionality within your application.

Use Cases

WCAG 2.1 AA

Our Button component is fully aligned with WCAG 2.1 AA accessibility standards through adherence to standard button aria roles.

By design, we have ensured that the Button component follows the requirements outlined for the button role without implementing any custom accessibility features specific to our design system.

This approach guarantees WCAG 2.1 AA compliance without compromising on accessibility standards.

Variants

Icon Filled Variant

The "Icon Filled" variant is designed for maximum visibility and immediate recognition, featuring a solid, usually brand-colored background with a contrasting icon.

This variant is most effective for primary actions or important interactive elements within an application, where it's crucial to draw the user's attention. The solid fill enhances the icon's prominence, making it an ideal choice for navigation elements, action buttons, or any interactive point that requires standout visibility and accessibility.

Refer to related specifications.

Round Filled Variant

Designed for scenarios where the button strictly contains icons, the round filled variant features a perfectly circular appearance. It aligns visually with the "filled"/"standard" variant, offering a distinct aesthetic for icon-centric buttons.

Refer to related specifications.

Outline Variant

Primarily used to signify secondary actions, particularly in contrast with the standard "filled" variant, the main distinction lies in the reduced visual prominence of this variant. It is best suited for scenarios where the standard filled accent is not optimal.

Refer to related specifications.

Icon Outline Variant

The "Icon Outline" variant combines the simplicity of icon-based interaction with the subtlety of an outlined appearance. It's tailored for secondary actions where visual prominence is required without overpowering the main content or actions.

This variant features an icon encapsulated within a thin border, maintaining clarity and recognisability without the visual weight of a filled background. It is particularly suited for interfaces that require a clean, minimal aesthetic while still offering intuitive and accessible interactive elements.

Refer to related specifications.

Round Outline Variant

Similar to the round filled variant, this variant is crafted for buttons consisting solely of icons. However, it adopts the circular design while aligning with the "outline" variant's visual style.

Refer to related specifications.

Text Variant

Similar to the outline variant but even subtler, the text variant eliminates wrapping borders. Despite this, it maintains clarity by employing forced all-caps text and colouring the text with a hue of the brand color. This variant exists mainly for legacy reasons and could be replaced with typography links/buttons. Use with caution.

Refer to related specifications.

Icon Variant

The Icon Variant is akin to the Text Variant but tailored specifically for scenarios where the content consists solely of a single icon. This variant serves a highly specialized purpose, addressing a limited scope of use cases. It should only be employed under strict adherence to these specific requirements for optimal functionality and visual coherence within the interface.

In contrast to the Text Variant, the Icon Variant automatically calculates internal spacing to ensure icons are centered within the button's bounding box. This feature mitigates potential overlap issues, particularly evident in the focus state, where the hosted icon remains visually distinct and aligned.

Refer to related specifications.

Round Icon Variant

Similar to the Icon Variant, the Round Icon Variant is designed for buttons containing single icons, ensuring visual coherence and optimal functionality. It should be used in specific scenarios to maintain consistency within the interface.

This variant automatically centers the icon within a circular bounding box, minimizing overlap issues, especially in the focus state.

Refer to related specifications.

Pitfalls & Common Misconceptions

Addressing common errors or misunderstandings related to the component's use or implementation is crucial for ensuring smooth integration and compliance with accessibility standards.

Toggle Scenarios and WCAG 2.1 AA Compliance

One common pitfall arises when implementing toggle functionality with the Button component. To ensure WCAG 2.1 AA compliance, application developers must provide correct supporting aria attributes, particularly the aria-pressed attribute. This attribute should be dynamically updated to reflect the current state of the toggle (pressed or not pressed), enabling screen readers and assistive technologies to accurately convey the state of the toggle button to users with disabilities.

Icon buttons - Mandatory Aria-Label

Button that contains strictly graphic must always be accompanied by a separate aria-label due to its non-textual, image-based visual label. Failure to provide a dedicated aria-label results in screen readers not announcing anything, significantly impairing accessibility.

Label vs Aria-Label and Action Clarity

When using a textual Button variant in web development, it's crucial to provide dedicated aria-labels when the visual label alone is insufficient to convey the action's intention and consequences to non-visual users, particularly those using screen readers. In such cases, application developers must ensure that a separate aria-label is provided, distinct from the visual label, to ensure clear communication of the button's purpose and functionality.

Reference

Usage Guidelines
Basic Keyboard Functions
WCAG Success Criterion for Target Size (Minimum)
View Code on Storybook