Card

Anatomy

1. Card Container: This rectangular container is the fundamental part of this component. It is styled with Canvas Tokens to ensure the background color, corner radius, depth, and outline stroke are coherent as a basis with cards within workday. This can be used as the basis for creating more tailored card types.
2. Title (Optional): The title explained
3. Paragraph (Optional): The Paragraph explained

Usage Guidance

• Cards hold a variety of content types, such as a combination of text, icons, imagery and actions related to a single topic.
• Cards should be easy to digest, providing relevant information and available actions.
• Text and visual elements should be placed in a way that clearly indicates hierarchy.
• Cards should be placed inside a layout grid to help with alignment and sizing.
• Most cards are created and maintained by specific product teams. The Canvas card is a generic container which you can leverage when creating new cards. Check out the Canvas Kit card container to see what’s available in Canvas now.

When to Use

• Use Cards when you need to group information in a digestible form.
• Use Cards when you need to offer a short entry point that is linked to more detailed content or a complex task.
• Use Cards to lay out single or multiple sets of related information in the same region of the page. Cards may include an image, a text summary, pills, and actions. Cards typically have similar widths, but heights should accommodate varying content.

When to Use Something Else

• When you need to show unrelated content types or actions in a single container.
• When you need to show content in multiple columns.
• When you need to display content in a table format.

Examples

Basic Example

Card includes a container Card component and the following subcomponents: Card.Body and Card.Heading.

Depth

Card extends from Box so it supports all of Box's style props. This includes depth, which changes the Card's perceived "height" above the page surface by adjusting its box shadow. Card has a default depth of 1.

Here's an example of a Card with a increased depth of 2.

Padding

Set the padding prop of the Card (again, supported via Box) to adjust its padding. Card has a default padding of l.

Here's an example of a Card with a reduced padding of xs.

Component API

Card

Usage

Card is a container component that holds a Card.Body and an optional Card.Heading. Card wraps a non-semantic div element. The element can be replaced using the as prop, or a role or other aria-* attributes can be added to give Card semantic meaning.

Props

Undocumented props are spread to the outermost element rendered by Card.

As mentioned earlier, Card extends from Box so it supports all of Box's style props.

Card.Heading

Usage

Card.Heading is an optional subcomponent that is meant to describe the Card. Since Card is a non-semantic presentational component, Card.Heading does not automatically have any semantic meaning. If your use case requires the Heading to label the Card, you must do so manually.

For example, Modal (which uses a Card) adds an aria-labelledby and a role to the Card, as well as an id to the Card.Heading.

<Card role="dialog" aria-labelledby="card-heading">
  <Card.Heading id="card-heading">Card Title</Card.Heading>
  <Card.Body>Card Contents</Card.Body>
</Card>

Card.Heading defaults to an <h3> element, but it can be changed using the as prop.

<Card.Heading as="h1">

Props

Undocumented props are spread to the outermost element rendered by Card.Heading.

Card.Body

Usage

Card.Body is a non-semantic subcomponent that contains the body of the card. Attributes may be added to give Card.Body extra semantic meaning. If Card.Body is brief (like in a short dialog), it may be helpful to add an aria-describedby referencing the id of the Card.Body to the Card container.

Card.Body defaults to a <div> element.

Props

Undocumented props are spread to the outermost element rendered by Card.Body.

Like Card, Card.Body extends from Box so it supports all of Box's style props.

Accessibility Guidelines

• Semantic heading markup must be used for conveying the same non-visual sense of content structure.
• Heading level should match the heading’s visual importance.
• Skipping heading levels should be avoided.
• Where related items are grouped together, semantic list markup must be used for conveying the same non-visual sense of hierarchy.
• Graphics and icons that do not communicate any additional information beyond what is represented in text may be considered decorative and should not provide any text alternative.
• The button text and background color must meet the minimum contrast requirement.
• If an Icon Button is used, an accessible label must be provided that indicates the purpose of the control. Avoid using the words “image” or “icon” in the description label.

Content Guidelines

• When writing content for Cards, refer to our Content Style Guide