Card

Use cards when you need flexible tiles for related content, actions, and a consistent layout.

Live demo

Cards hold information related to a single concept or item. Visitors scan titles, optional imagery, and a primary action. Authors configure view, copy, colour, and links in the component dialog; visual designers align cards with Card deck or list patterns on the page.

Cards are designed to:

  • Surface a preview of content (article, program, service, profile)
  • Present multiple related items in a scannable grid or list
  • Combine image/icon + title + short description + action
  • Guide users from overview to a detailed page
  • Establish clear visual grouping

Cards are preview patterns — not containers for full content.

Behaviour

  • Cards can be linked as a whole and may include a button for the primary action.
  • Hover and focus styles indicate when the card is interactive.
  • Icon, image, and text views follow different dialog branches (see Code).

Anatomy

  1. Image (optional): Should be relevant and provide context for the card content.
  2. Category: Indicates the topic or theme of the card.
  3. Heading: A concise title summarizing the main content.
  4. Subtitle: Additional context or description.
  5. Date: Publication or event date.
  6. Description: Provides further details, limited to two or three lines.
  7. Call to action: Clear and actionable, guiding the visitor towards the next step.

Content guidelines

  • Images should match the destination; set alt text in DAM or dialog per deployment.
  • Category and date support scanning; avoid duplicating the full story in the card body.
  • Title: Should be concise and descriptive. It must stand alone without relying on the description.
  • Subtitle: Provides additional context. Keep shorter than the title.
  • Description: Briefly outlines the main idea. Limit to 2–3 lines. Avoid generic phrases such as “Learn more about…”
  • Call to Action: A card must contain a hyperlink.

Best practices

Do

  • Maintain consistent card styles within a deck.
  • Focus on one main message per card.
  • Add graphics only when they provide essential context.
  • Write clear, action-oriented button text.

Don't

  • Don't mix incompatible card styles in one deck without design approval.
  • Don't overload cards with long body copy; link to the full story instead.

When to use

Use the Card component to provide a snapshot of related content, encouraging users to click for more details.

Cards work best when:

  • There are 2 or more items
  • Each item shares a consistent content structure
  • The goal is exploration and comparison
  • Users are scanning and selecting

Cards are ideal for highlighting:

  • Services
  • Programs
  • Articles
  • Events
  • Profiles
  • Categories

When not to use

Avoid cards when:

  • There is only one item (use a hero, feature banner, or callout instead)
  • The content is long-form or editorial
  • The action is highly transactional (forms, complex workflows)
  • The page already contains heavy visual components competing for attention
  • The content does not require previewing (simple link lists may be better)
  • Simple link lists; consider Link list.
  • Single plain paragraph; WYSIWYG may be enough.

Patterns

Featured news, events, and publications: Cards often appear in a horizontal Card deck so visitors can compare items side by side with consistent styling.

Related

Resource
!FigmaCard in Figma
!AEMCard in AEM
!WCAGCard WCAG guidelines
Card deckResponsive grids of cards
IconIcon view and Material Symbols

Affordance & interaction guidance

Affordance must be clear before interaction. Cards rely on:

  • Grid repetition
  • Hover elevation tokens
  • Consistent spacing
  • Underlined links
  • Clear section framing

If using a single card on a page:

  • Provide contextual heading
  • Ensure sufficient whitespace
  • Avoid floating isolated placement

Users should understand: “This is selectable.”

Variants

The card component supports multiple layout views. Choose intentionally based on content type and scanning behaviour.

Default (image on top)

Best for:

  • News
  • Events
  • Programs
  • Services
  • Promotional content

Use when:

  • The image adds context
  • Strong visual hierarchy is needed
  • Cards appear in a grid

Avoid when:

  • The image is decorative only
  • Higher density is required

Inverted (image on bottom)

Best for:

  • Text-forward content
  • Situations where title and description are primary

Use when:

  • The visual is secondary
  • You want textual hierarchy first

Horizontal

Best for:

  • Search results
  • Resource listings
  • Directory views
  • Service inventories

Use when:

  • Information density matters
  • Users are scanning quickly
  • Image plays a secondary role

Thumbnail (Circular Image / Profile)

Best for:

  • Testimonials
  • Profile-based content

Use when:

  • Identity recognition is important
  • Portrait imagery is consistent

Avoid when:

  • Cropping cannot be controlled
  • The image is not person-focused

Default (image on top)

Best for:

  • Tools
  • Services
  • Categories
  • Action-based navigation

Use when:

  • The icon meaningfully represents the content
  • Images would feel decorative or inconsistent

Avoid overusing icons in dense grids.

Accessibility is crucial to ensure that all users, including those with disabilities, can interact with and understand the content of the Card component. Below are detailed accessibility considerations:

  1. Alt Text for Images:

    • Descriptive Alt Text: Provide clear, descriptive alt text for all images that convey the purpose and content of the image. For decorative images, use empty alt attributes (alt="").

  2. Color Contrast:

    • Ensure sufficient color contrast between text and background. Use tools like the WebAIM contrast checker to verify compliance with WCAG guidelines (minimum contrast ratio of 4.5:1 for normal text and 3:1 for large text).

  3. Keyboard Navigation:

    • Ensure that all interactive elements (links, buttons) are accessible via keyboard. Use proper HTML elements and ARIA roles to facilitate navigation.

    • Focus States: Clearly visible focus indicators should be present for all interactive elements to help users navigate through keyboard.

  4. ARIA Labels:

    • Use ARIA (Accessible Rich Internet Applications) attributes to provide additional information to screen readers. For example, use aria-label to provide context for links or buttons that may not be clear from the text alone.

    • Example: <a href="/link-url.html" aria-label="Read more about Title" class="btn c-card__btn btn-ghost-dark">Read More</a>

  5. Semantic HTML:

    • Use semantic HTML elements to ensure the content is structured correctly and meaningfully. Headings (e.g., <h3>) should be used for titles, and <p> for paragraphs.

    • Example: <h3 class="c-card__title c-card__title--black">Title</h3>

  6. Readable Text:

    • Text should be easily readable, using a legible font size and line height. Avoid using all caps for long blocks of text, and ensure text is left-aligned to improve readability.

Testing

TestStatus
Default stateTested
Advanced stateTested
Keyboard navigationTested
Screen readerManually tested

CRXDE Lite query

Use this query in CRXDE Lite to find instances of this component.

/jcr:root/content//*[@sling:resourceType = 'concordia/components/card']

Implementation

ItemLocation
Componentapps/concordia/components/card/ (JSP, views under cardViews/)
Stylesetc/designs/concordia/clientlibs/card/less/card.less (and related imports)

Views: Dialog View selects templates such as default, Icon (iconCard.jspf), and image-led layouts; see component scripts for the full list.

Clientlibs: Card and card-deck styles ship under the card clientlib category used by pages that include cards.