Button

The when, how, and why to use buttons.

Buttons should be used in situations where users might need to:

• Submit a form
• Begin a new task
• Trigger a new UI element to appear on the page
• Specify a new or next step in a process

Using the design system Button Component will ensure you’re button looks like a button. Applying the appropriate label is also important in making sure the user has a clear understanding of what the action will do.

• Use clear and concise wording.
• Avoid contractions or colloquialisms. Keep the language approachable but not personal.
• Ensure your button label matches the route destination.

Buttons are unique components since their alignment depends on where they appear (drawers, modals, etc.). Buttons should always be where the user most expects it. In general, follow this guide on how to align buttons in most use cases.

Button types may be applied in various combinations, however they should always be ordered by order of importance and in relation to their alignment: Primary first, followed by Secondary, then by Default.

The HTML elements for buttons and links (a.k.a. anchors) describe a very specific type of action that is going to be taken when they are used. It is important you know when to use which, as the distinction matters:

• Use a link when you’re navigating to another place, such as: a "view all" page, "Jane Chen" profile, a page "skip link" etc.
• Use buttons when you are performing an action, such as: "submit," "merge," "create new," "upload," etc.
• An action almost always occurs on the same page

Cancel buttons enable users to exit out of or dismiss the current screen in order to go back to the previous one. Having an explicit way to cancel provides a fallback to safety as it helps discard any unwanted changes.

Cancel buttons should be presented in the default button styling. The neutral appearance signifies the non-committal action. Visually emphasizing the cancel button should be avoided to minimize user confusion.

Toggle buttons are used either to switch between two states, such as checked and unchecked, or to trigger two actions like on or off.

Icon buttons have an a11yTitle, aria-label or button label that describes the action that the user will be performing when using screen readers.

Best Practices:

• Limit to 2-3 descriptive words.
• Use verbs first to describe the action such as “Hide/View”, "Switch/Unswitch", “Favorite/Unfavorite”, "Light/Dark" or “Like/Dislike".
• Use sentence case capitalization.
• Words such as “the” and “a” should be avoided.

For Buttons with Icons ONLY, it is important that you show the two following elements:

1. Show the current state of the button through the use of an icon.

2. Inform the user of what will happen when the button is clicked by including a11yTitle or aria-label.

If pressing a Button results in a new URL, or the resultant UI makes sense as "a new browser tab", that is a link <a>. Everything else is a <button>.

The distinction is important to screen reader users to know what's going to happen next. Will I navigate somewhere or will something happen on the page? So it's important to choose the right HTML element for the job.

There are a couple "flavors" of button depending on use case.

Used for key actions on the page. Primary Buttons can also be referred to as “Brand” or “CTA (Call to Action)” and should only be used once per page. All other supporting actions should use Default Button. Consider that the 80% use case for some pages is visualization and not action. In cases like these, a call to action is inappropriate and a secondary button can be used.

Secondary buttons are used to represent calls to action that are either in support of the primary call to action or stand-alone. There can be multiple secondary buttons per page. However, a default button should be used for any navigation-type actions.

Toolbar buttons are used when buttons are placed in a row with other toolbar controls.

A common use case would be when creating a filtering experience. In this situation, a search input, filter button, and action menu are presented as a unified set of controls. The intent is to present each control with equal prominence.

To implement, apply kind="toolbar" to Button or Button-based components like Menu.

This is the default appreance and behavior of button. The majority of buttons on your page should use this form of button. If you are designating a primary call to action, use a primary button. If you are designating a secondary call to action, use a secondary button.

When looking to accent an interaction or for special use cases that require more importance than a default button, the Color Button can be used to support an HPE sub-brand when appropriate or a serious action (i.e. using red for a destructive task).

Icons may be incorporated into buttons, either inline with text or as an icon only. When using icon only buttons, the dimension of the clickable area should be kept in mind for its use on mobile devices. Areas too small lead to errant clicks, and as result, poor experience.

A button's visual state may be specified as appropriate in the application's context. For example, using "active" for the current item or "disabled" until a set of criteria are met. However, use of disabled controls is discouraged because it tends to elicit a "why?" response from users. It is better to leave buttons active and use messaging upon click to indicate that criteria have not been met. Buttons that do not apply (for reasons of context or permissions) should not be shown at all, rather than being shown as disabled.

Button label text size may be specified. Padding and rounding scale proportionately to the label size. The default size is medium.

Ensure you are always being mindful of our responsive page layouts when designing user experiences. Even if you don’t anticipate your users leveraging mobile or tablet devices, they may be reducing/expanding browser widths, zooming in on content, or manipulating the browser in unanticipated ways. As a best practice, always design for a usable UI on all browser widths and resolutions.

• Ensure the button label does not wrap, truncate, or alter the text content in any way when presented on smaller browser widths.
• Button label text should not scale down to fit on smaller browser widths.
• The minimum button width for any button should be 42px.

On screen widths of less than or equal to 576px (Grommet "small"), it is best to have buttons fill the full width of the container. Because press target size and an unclear visual hierarchy are key concerns at smaller resolutions, this utilizes available space to ensure users can easily identify and interact with the buttons.

For button groups on screen widths less than or equal to 576px (Grommet "small"), ensure each button within the group follows the established guidance for single buttons. If a button group is presented inline horizontally, rearrange the buttons vertically on smaller browser widths to ensure the proper full button widths can be achieved.