Brief: Cards v. 0.1[Block]

Cards group information into flexible containers to let users browse a collection of related items and actions.

Usage

Use When 

• You have multiple summaries of like topics. Cards are never shown by themselves, always within lists.

Don’t Use When 

• You only need a simple call to action. Use a CTA Block instead.

• You need sequential text elements. Cards should be independent in nature and make sense in isolation.

• You only want to ‘decorate’ something to look like a card.

Related/Similar Components 

• Cards are

• X 

Anatomy

Open

Cards are modular and flexible and consist of a mix of various flexible elements.

• The card container holds the content, can be interacted with can adopt a change in elevation.

• Imagery - either a foreground or background image (or in future, both).

• Overline text - not MVP (effectively categories)

• Title

• Description

• CTA

Cards can exist in different sizes and layouts (vertical only in MVP).

Open

An example of variation in size and layout

Cards can have visual boundaries or not (adjusting subtlety)

Key Content  

 *Some non-content items such as links (e.g. a product card links to its product page, an article card links to its article page)

Behaviour 

• Interactive cards include a default, hover and active state. (visited state is TBC).

• Where cards have a single focusable element, the whole card (container) links to the primary link destination and any CTA is effectively decorative. Read more on Inclusive Components.

• Where cards have more than one focusable element (not expected within MVP) this creates an additional tab stop and is also addressed with recommendation on Inclusive Components.

Editorial 

• Titles and descriptions will pull from “short description” content by default.

• If manual content is ever allowed (eg. a custom built card, keep copy short and concise).

Accessibility 

• Please ensure you read Hayden Pickerings' Inclusive Components documentation of best practices for card accessibility. This includes key concepts such as titles/headings leading the content of each item, irrespective of what the content looks like.

• We must observe the logical focus order for card elements. Where the entire container is a singular link, this forms no issue, but within a card if we have multiple focusable elements in future (e.g. add to wishlist, reviews, etc) those elements need to meet a logical focus order.

• Best practices need to be reviewed in terms of HTML semantics. Like accordions, there may be some tensions to navigate. When cards are in a list then <li> markup could be valid. The card items themselves are semantically <article> which can aid with programmatic heading logic. There may be more depending on what the card content itself actually is (for example if FAQs were presented in cards rather than accordions, underneath it would still effectively be a definition list.

• Some systems go so far as to divide card content into <header> and <footer> areas within the <article> sectioning element.

Analytics & Data 

• Most requirements are covered under lists.

Future Expansion 

• Card content will ultimately expand to include more use cases, one example is “eCommerce product cards” which may include pricing information, direct add to card, variant selection, etc. These more complex elements are where focus order becomes more relevant.

Wider Conversations that may impact this 

• Heading Control: Can we programmatically determine headings so that the content is properly headless.

• Item: Description 

Inspiration from elsewhere 

• Adobe Spectrum Cards

• Inclusive Components: Cards

• Cards & Composability in Design Systems

• Material Design Cards

Examples

Insert here

Useful links