Button

Primary buttons visually guide users to the primary action we want them to take. Only one primary button should be used in a message.

Secondary (a.k.a., "standard") buttons are for less important or desirable actions or when multiple actions have equal importance or desirability.

If there are multiple buttons on a message, only one should be primary. All the rest should be secondary. In a form or flow, secondary buttons should be used for actions that apply to the entire screen, such as canceling changes a user has made.

• To trigger an action, such as screen navigation.
• For the most important actions you want users to take, such as "Save" or "Log in."

• Do not use in body copy. Use links instead.

• Text for button labels should use sentence case. For example, "Get a quote."
• Button labels should clearly describe a single event or action that will be triggered when the button is used.
• Button labels should be as short as possible and include "trigger words" that clearly explain what will happen when the button is used, such as "Download" or "View."
• Consider making the first word of a button label an action verb. For example, use "File a complaint" instead of "Complaint filing."
• Keep button labels short, because:
  • Users may not recognize the screen component as a button (and instead see it as a header or other inactive screen component)
  • On smaller devices, button labels may need to look different than other buttons when using a smaller font size or multiple lines of text (making the button look different from what users expect a button to look like)

• Use a secondary button for an action that applies to other screen components.
• Screens may have a primary action button to visually guide them to the action we want them to take. Using the Enter key on a (virtual) keyboard should be the same as using the primary action button, unless the Enter key can be used for line breaks while editing a text area.
• The primary action button in a modal window should always lead to the least harmful consequences. In other words, it should be the button that requires the least amount of effort to correct if it's used by mistake. Using the Enter key on a (virtual) keyboard should be the same as using the primary action button, unless the Enter key can be used for line breaks while editing text.
• For buttons that trigger an action but don't navigate to another screen, such as "Download" or "Remove," consider adding an icon to the left of the button's label.
• Icon buttons should use icons that are recognized by the general public. An icon is easily understood by an average user if it has been widely standardized, such as the icons used for airport and subway signs.
• Do not disable a button if there's even a small chance users do not understand what to do in order to enable it. For example, allow users to always use a continue button in a button bar to trigger any error messaging explaining why they cannot navigate to the next screen.

When using the button on background colors, ensure there is proper contrast.

• Button text to button background must meet 4.5:1 contrast ratio.
• AND, the button border to container background must meet a 3:1 contrast.
• If neither meets, then another background color should be chosen.

Messaging components have been reviewed for compliance with visual accessibility guidelines, but accessibility tool (AT) testing should be performed by those implementing them in code.