Properly used accordion menus reduce scrolling and help users accomplish tasks more efficiently by giving a quick overview of what topics are available. The user can choose to expand the content that interests them and ignore the rest.

However, poorly implemented accordions increase interaction cost by adding extra, unnecessary clicks and hiding useful content. If all or most of the content is important to the user, then an accordion is not a good design option. Accordions can also hinder the ability of users to print the webpage.

Use a primary button for the most important action on a page. Limit the number of primary buttons on a page.

Use a secondary button for actions that are secondary to the primary call to action. This is the default button that should be used in most cases.

Use a tertiary button for non-critical actions. While the tertiary button visually looks like a link, it should be used as a button. Tertiary buttons should always be paired with another button.

To disable a button, simply add the class .is-disabled.

The default buttons work well on light-colored backgrounds, but get lost against darker colors. When using a button on a dark background add the class .Button--white.

A full-width button inherits the width of its parent container. This allows you to align the button with relevant content on the screen. To make a button full-width, add the class .Button--full.

Buttons are limited to a max width of 600px to avoid losing context.

The text within a button must clearly indicate what happens when it’s clicked. Text should be written in title case.

A button or button group should be right aligned in a form.

Buttons can be grouped together when there are multiple actions a user can take. In order to guide the user and not overwhelm, it’s recommended that a group be limited to a maximum of four buttons.

There should be 8px of padding between buttons.

A button group should be stacked vertically when:

• full-width buttons are put together to form a group
• an inline button group starts to break to two lines

Stacked button groups should be always be full-width. This allows the group to appear consistent, regarless of text lenght in each individual button. (so there aren’t varying widths of buttons regardless of text length)

Mixing buttons allows you to emphasize important functions.

Buttons should appear in order of importance, with the most important action closest to the user.

For inline groups, the most important button is on the right.

For stacked groups, the most important button is on the bottom.

When necessary, use aria-label, aria-labelledby or aria-described to describe a button with short context. When there are multiple instances of the same button text on the page, visually hidden labels can enhance a users experience and help guide their decision and navigation. If a button doesn’t contain any useful verbale content, labeling the button can also help the user understand what’s going on. For example, an X or icon to close a modal is not be informative enough and needs a hidden or aria label.

A card must include:

• Title
• Description text (a short summary)
• Interactive content – a button or link to more detailed content

Optional card elements:

• Illustration
• Meta data such as date, timestamp, tags, etc.
• Social or share links

Cards work best for content that:

• Has multiple types of data
• Doesn’t require direct comparison (a table may work better in this case)
• Is highly variable in length
• Needs to be organized into digestible groups or sections

When multiple cards are used together, it’s recommended that all cards be the same height and width. If a button or link is placed at the bottom of a card, it should be in the same location on all cards.

There should be a minimum of 16px between cards, and it’s recommended that flex be used to create a unifom layout.

A checkbox list works best for allowing the user to make a selection from a range of options. It is recommended to use checkbox lists when there are 7 or fewer options.

Lists can be created by wrapping checkboxes in a .Field-group container.

To disable a checkbox, add the class .is-disabled to the .Field container. You will also need to add the attribute disabled to the input type="checkbox".

The input field label informs users which fields are required or optional.

One way to designate a field is required is to add a single asterisk (*) next to the input field label. When using this option, there must be an additional label stating "* Required field" under the fillable form.

Alternatively, a text label can be used showing which field(s) are required or optional.

• If there are more optional fields than required fields, add the text "(required)" next to the input field label.
• If there are more required fields than optional fields, add the text “(optional)” next to the input field label.

By adding .is-invalid to the .Field container, the checkbox list will be marked as invalid and the .Field-error element will appear.

Form components require semantic information to help people using assistive technology understand the structure and information conveyed in the form field.

While not required, it’s recommended to add the attribute aria-describedby=“checkbox-legend” to each checkbox element and the .Field container. Other states that can be utilized are aria-invalid, aria-required and aria-labelledby. See www.w3.org for more information.

An alternative approach to checkbox groups that is more accessible, would be to wrap your checkbox group in an unordered list. Point the group label at the unordered list with aria-labelledby and wrap each checkbox in a list item. This will provide your list with more helpful explanation as to what's going on and how many options the user has to choose from. See example for alternative approach.

Definitions help users understand industry terms and rules without requiring them to leave the current screen. When the user clicks on an underlined term or question mark icon, the definition panel opens. Users can dismiss the panel by clicking outside of the definition, or by clicking on the ‘X’ icon.

Definitions should clearly define a term in a concise manner.

• Try to limit text to 280 characters or less
• Use sentence case
• Consider your audience. Use plain English and avoid industry jargon and highly-technical words

A Feature Box is a container that highlights a section of content on a page. It visually contains different elements about a single subject and separates them from the rest of the content on the page.

Feature boxes include:

• Spot Illustration (Optional)
• Title - Required
• Other types of basic content such as paragraphs, images, and links

Feature boxes work well for:

• Important information that needs to be highlighted
• Useful information that supplements the page's main content

A Feature Box should include content about a single topic. The layout of the content inside the feature box can be up to three columns wide.

Global messaging is reserved for notifications that effect the entirety of a site or application. The global message bar appears at the very top of the page and pushes down the rest of the page‘s content. It does not stick when scrolling or float above content.

Global messaging can contain a single hyperlink. It should not prompt dialogs or other notifications to appear. The bar can be closed by the user by clicking the “x” icon. Once the user has chosen to close a particular global message, that message should not reappear, even if the user navigates to another page or if they return to the site at a later time.

Depending on the type of message, there are two different styles of global messaging bars:

Informational messages notify users of news or changes that may be of interest to them.

Examples include:

• Natural disasters, mass shootings, and deaths of individuals significant to the company
• Upcoming scheduled service outages
• System updates

Global messages should be concise.

• Write full sentences and use end punctuation
• Consider your audience. Use plain English and avoid highly-technical words

Inline messages are versatile and can be used in forms, page content, and inside other components. They alert the user to new, important information related to an action they have just taken, or are about to take.

Inline messages are context-related and are placed in close proximity to where the user is interacting. Generally, other content is moved down to accomodate the appearance of a new inline message.

Depending on the type of message, there are four different styles of inline messaging:

Informational messages give the user additional information that may be of use to them. This information should be useful but not critical to the user's ability to complete their primary task.

Inline messages should be concise.

• Write full sentences and use end punctuation
• Consider your audience. Use plain English and avoid highly-technical words

Form inputs allow users to enter text.

The length of a form input should be appropriate for the amount of text the user needs to enter. If a field is too long or too short, users may wonder if they understood the label correctly.

The input field label informs users which fields are required or optional.

One way to designate a field is required is to add a single asterisk (*) next to the input field label. When using this option, there must be an additional label stating "* Required field" under the fillable form.

Alternatively, a text label can be used showing which field(s) are required or optional.

• If there are more optional fields than required fields, add the text "(required)" next to the input field label.
• If there are more required fields than optional fields, add the text “(optional)” next to the input field label.

Form components require semantic information to help people using assistive technology understand the structure and information conveyed in the form field.

The class .Field-label should be associated with the label element. This helps identify what information each input is collecting. If a label is not needed for any reason, use CSS to move it out of the visual range of the user leaving it for screen readers to see. The class .Field-detail gives further instruction when needed. Aria-describeby should be used and pointing at the .Field-detail node's ID for the best experience. Label for, Input id can be changed to meet your needs, but must match. Input aria-describedby and Field Detail id can be changed, but must match as well.

When a link is outside a copy block, use a link element. A carrot is added to the text, indicating movement to another page within the site.

Link text helps the user understand where the link is taking them.

• Write in title case
• Make it clear and descriptive
• Keep it short and to the point

When linking to an external site, add the attribute target=“_blank”. This opens the site in a new tab, preventing users from losing their place.

For greater accessibility, it is recommended you include some text to indicate the link will open in a new viewport; this can be safely hidden from view by using the classname .u-hiddenVisually. It is also recommended you add the attribute rel=“noopener”, to safeguard from “Tabnabbing”.

A loader should be a general indication of the time it takes to load content. It doesn’t represent real time loading and should not be confused with a progress bar. If page content takes longer than a few seconds to load, consider improving page performance.

When placing a loader inside a button, the loader icon should have a width and height of 20.

When using a loader as a placeholder for content, the icon should have a width and height of 60.

When a loader is needed on a dark colored background (for example, within a primary button), add the class.

Multiselects allow users to select one or multiple options from a contained list.

It is recommended that multiselect be used as infrequently as possible when designing and building for accessibility. Users may not know to use CTRL/Command or Shift + click to select multiple items. A set of check boxes can provide similar, yet more accessible functionality.

The input field label informs users which fields are required or optional.

One way to designate a field is required is to add a single asterisk (*) next to the input field label. When using this option, there must be an additional label stating "* Required field" under the fillable form.

Alternatively, a text label can be used showing which field(s) are required or optional.

• If there are more optional fields than required fields, add the text "(required)" next to the input field label.
• If there are more required fields than optional fields, add the text “(optional)” next to the input field label.

By adding .is-invalid to the .Field container, the multiselect will be marked as invalid and the .Field-error element will appear.

Form components require semantic information to help people using assistive technology understand the structure and information conveyed in the form field.

When using helper text or invalid states, make sure to use aria-labelledby to convey the additional information to the user.

When using mulit-selects without a label, include the attribute aria-label="Your Label Here" to describe what the select element is asking for. See www.w3.org for more information.

Overlays obsures the main page to present the user with additional information. It’s recommended that overlays be intitiated by the user to ensure the content is relevant to the task at hand. The goal is to provide the least amount of disruption to the user’s flow as possible.

When an overlay is open, a user cannot interact with or scroll within the main window. It can be dismissed using the close button, the Escape key, or clicking outside the overlay.

It’s important to consider whether an overlay is the best way to present the content. There should be a compelling case for why the content shouldn’t be presented within the page.

Copy should be short and not require scrolling within the overlay.

Dialogs (sometimes called “modals”) are actionable overlays. They are used for critical messages requiring an immediate answer from the user. They should only be used when the flow is dependent on the user’s response.

Dialogs must have at least one action. A user can close a dialog by selecting one of the actions or clicking outside the box. Clicking outside the box is the equivalent of “cancel”.

Pagination is a component that allows the user to see which page is currently in view, how much content exists, and navigate across multiple pages. It is used when a user needs to find a particular item from a large data set. A common example is a search page which commonly returns dozens or more results.

The recommended items per page is 10. This number could be adjusted to meet the needs of the projects for optimized performance and better experience. Items requiring less space may have more items per page. Items requiring more space may have fewer items per page.

Standard pagination includes four buttons: "First", "Last", "Prev", "Next", and one page indicator "Page X of Y". All buttons should be included whenever the pagination is used.

• Disable "First" and "Prev" when user is on the first page.
• Disable "Last" and "Next" when user is on the last page.
• Disable ALL buttons when there's only one page of content.

Disable the buttons by using a span or similar non-interactive element with the "is-disabled" class (ex: "First" and "Prev" in the example), or by using the "disabled" attribute on the anchor or button element(ex: "Next" and "Last")

Pills should be used as a visual aid to indicate status/categorization. They are not clickable or interactive.

Pill backgrounds can be either solid fill or white with an outline using any color in the Design System, as long as the color contrast between the background and the pill text is at least 4.5:1. Pill label text should be either White (#FFFFFF) or GrayDarkest (#222222).

Pill Text

Pill text should be short and clear.

To disable a radio button list, add the class .is-disabled to the .Field container. A single radio should never be disabled.

The input field label informs users which fields are required or optional.

One way to designate a field is required is to add a single asterisk (*) next to the input field label. When using this option, there must be an additional label stating "* Required field" under the fillable form.

Alternatively, a text label can be used showing which field(s) are required or optional.

• If there are more optional fields than required fields, add the text "(required)" next to the input field label.
• If there are more required fields than optional fields, add the text “(optional)” next to the input field label.

By adding .is-invalid to the .Field container, the radio button list will be marked as invalid and the .Field-error element will appear.

Form components require semantic information to help people using assistive technology understand the structure and information conveyed in the form field.

Radio button lists can be used to enhance the user experience. By wrapping a group of radio's in an unorder list, you can convey label and count to the user. The following example has more information about how to execute this. See www.w3.org for more information.

The input field label informs users which fields are required or optional.

One way to designate a field is required is to add a single asterisk (*) next to the input field label. When using this option, there must be an additional label stating "* Required field" under the fillable form.

Alternatively, a text label can be used showing which field(s) are required or optional.

• If there are more optional fields than required fields, add the text "(required)" next to the input field label.
• If there are more required fields than optional fields, add the text “(optional)” next to the input field label.

Form components require semantic information to help people using assistive technology understand the structure and information conveyed in the form field.

When using helper text or invalid states, make sure to use aria-labelledby to convey the additional information to the user.

When using selects without a label, include the attribute aria-label="STRING" to describe what the select element is asking for. Other states that can be utilized are aria-invalid, aria-required, and aria-labelledby. See www.w3.org for more information.

Text areas are taller versions of input fields and wrap overflow text to a new line. They allow users to input free-form text.

The length of a text area should be appropriate for the amount of text the user needs to enter. If a field is too long or too short, users may wonder if they understood the label correctly.

A text area label should make it clear what the user should enter into the field. For legibility, keep the label short and limit to a few words.

To disable a text area, add the class .is-disabled to the .Field container.

The input field label informs users which fields are required or optional.

One way to designate a field is required is to add a single asterisk (*) next to the input field label. When using this option, there must be an additional label stating "* Required field" under the fillable form.

Alternatively, a text label can be used showing which field(s) are required or optional.

• If there are more optional fields than required fields, add the text "(required)" next to the input field label.
• If there are more required fields than optional fields, add the text “(optional)” next to the input field label.

By adding .is-invalid to the .Field container, the text area will be marked as invalid and the .Field-error element will appear.

Form components require semantic information to help people using assistive technology understand the structure and information conveyed in the form field.

The class .Field-label should be associated with the label element. This helps identify what information each input is collecting. If a label is not needed for any reason, use CSS to move it out of the visual range of the user leaving it for screen readers to see. The class .Field-detail gives further instruction when needed. Aria-describeby should be used and pointing at the .Field-detail or .Field-error node's ID for the best experience.

There are no explicit declerations that are needed for textareas. Options that exist are role=“textbox” and aria-multiline can be used if you are not using semantic markup.

Most tables should have a header row to give context about each column. Headers should have short, clear labels for columns or rows.

One way to make tables more legible is to add a zebra stripe. A gray background is applied to every other row, guiding users as they move their eye across the table. This aids in scannability and prevents users from getting confused about which row they’re looking at.

To create zebra stripes, add the modifier .Table--striped to the tbody rows.

For tables that have a lot of columns, it can be helpful to highlight a row when the user hovers over it. This allows the user to focus on a specific row as they move across the table. Hover can be used on table with or without zebra stripes.

To add a row highlight on hover, add the modifier .Table--hover to the tbody row.

A column highlight can be added to emphasize important content. This can help distinguish one column from the rest of the table. It can also draw the user's attention to the most important information.

To highlight a column, add the class .is-highlighted to the cell element.

When space is limited or the table requires a large amount of content, consider using a condesed table. It can help display more items without making the user scroll.