Example

The example below shows utility actions for Print, Email and RSS.

Available Actions

In Figma, use the toggle feature to select different utility actions.

Use cases

• Provide options for saving or sharing content: Offer users the ability to print, email, or download content so that users may refer to or share information from a web page or document.
• Subscribe to content updates: When users want to stay informed about new content on a website or blog, providing an RSS feed allows them to easily subscribe and receive notifications of new posts or updates.
• Highlight updates on relevant information: Use the "what's new" feature to keep users informed about the latest developments, changes, or additions to your website. Note: the "what's new" feature is limited to sites using the Medicare Design System.
• Examples:
  • Enabling users to print search results (Medicare - Care Compare)
  • Enabling users to email or print important information (HealthCare - Find Local Help or When can you get Health Insurance?)

Guidelines

• Utility actions are ghost buttons for available actions that do not take priority over primary or secondary call-to-actions (CTAs).
• Placement should be in the page header and top, right aligned.
• Include no more than 3 utility actions on a page to prevent cluttering the user interface (UI) and distracting the user.
• When pairing 2 or more utility action buttons, the preferred action goes on the left.
• Be consistent with the inclusion of utility actions and their order across pages and products.
• Follow any additional governance established by your UX and content lead for which utility actions to include.

When to consider alternatives

• If an action (e.g. printing or emailing) is a critical call-to-action on a webpage, consider using a solid or outlined main button.
• If the utility action is opening a link in a new webpage versus triggering an action, refer to guidance on links.
• Carefully consider which utility actions are used on mobile (since space is a premium.)

Component behavior

• Hover state: A subtle highlight or change in color to indicate interactivity.
• Focus state: A border or outline, to show that the button is focused.
• Click/tap behavior: Execute the intended action (e.g., open print terminal, copy a link, etc.)
• Accessibility: Ensure that utility actions are accessible to users with disabilities, including providing appropriate ARIA attributes and keyboard navigation.

Accessibility

Accessibility Guidelines

• Always include both the icon and label in utility actions to meet accessibility standards.
• Don't create CTAs that duplicate utility actions on a page. Having multiple "print" actions on a page can hinder accessibility for screen reader users.
• Consider using ARIA labels.

Accessibility testing

General

• Each utility action should have a unique, accessible name. Get details on accessible names and descriptions

  You are leaving design.cms.gov.

  You're about to connect to a third-party site. Select CONTINUE to proceed or CANCEL to stay on this site.

  Learn more about links to third-party sites.

  ContinueCancel
  .
• The purpose of the utility action should be clear in the context of the whole page.

Keyboard testing

• Use the tab key to move the focus between elements on the page. The focused element should be visually indicated by a design-system-standard colored outline.
• Navigate to each utility action button and ensure that it can be focused and activated using the tab key.
• If any keyboard shortcuts are associated with utility actions, test that they work as expected.
• Ensure that the focus moves through the elements in a logical order, preventing users from getting stuck in unexpected places.
• Verify that all actions can be completed using the keyboard, without requiring a mouse or touchpad.

Screen reader testing

When using a screen reader (NVDA, JAWS, VoiceOver, TalkBack):

• Ensure that screen reader software can accurately read the labels associated with utility action buttons. The labels should clearly convey the purpose and functionality of each button.
• Check that appropriate ARIA attributes (e.g., role, aria-label) are used to provide additional context and information to screen reader users.

Code

• Implementing this pattern requires importing at least 2 components from the Design System:
  1. Button component, and
  2. The specific icon you wish to display (Email icon for example). Get icon component details.
• The Button component should wrap the icon and be set to the ‘ghost’ variation.
• Changing the size of the Button via the size prop will also change the size of the icon. For more control of the icon size refer to class names from our font size utilities.

Style customization

Color: Use only primary or secondary colors for each product theme. Style changes not allowed.

Icon size: Can be customized. Get details on changing icon size.

Analytics

This component has analytics tracking available via analytic properties exposed on the Button component. Get details on analytics for buttons.