composite pattern · Structural containers and states
Card
A self-contained container that groups related content and optional actions into a recognizable rectangular surface, often with a header, body, and footer.
Decisive boundary
A Card is a container pattern, not a semantic surface like a Dialog. Do not confuse a clickable card with a button unless the entire region must remain operable as one control.
Definition and intent
What is a Card UI pattern?
Use the behavior, not the silhouette
A self-contained container that groups related content and optional actions into a recognizable rectangular surface, often with a header, body, and footer. The term is used here as a composite pattern made from multiple controls or regions that must work together. That distinction prevents a visual resemblance from silently deciding focus, keyboard, modality, or dismissal behavior.
Group and present related content in a digestible, scannable unit. A good implementation preserves that job while making the trigger, open state, close path, and responsive behavior observable to users.
Know when the label is wrong
The fastest way to identify a pattern is often to reject the nearest alternative. For Card, the boundary is: A Card is a container pattern, not a semantic surface like a Dialog. Do not confuse a clickable card with a button unless the entire region must remain operable as one control.
Do not implement it as Dialog or Drawer for embedded content, and Popover for permanent visible content blocks. If those requirements describe the real task better, use the related pattern page or the full Structural containers and states comparison before writing code.
Decision process
Decide before choosing a component
Record these requirements in plain language. A library component name is not a substitute for the contract.
Confirm the user job
Group and present related content in a digestible, scannable unit.
Define opening and closing
Always visible as a structural container; hover and focus effects are presentation, not triggers. Not applicable; a card is a persistent container, not a dismissible surface.
Specify access behavior
Cards that act as links should contain a single link or use a wrapping strategy; interactive cards must keep nested controls independently focusable. Inline controls follow normal tab order; link-only cards should expose a single tab stop.
Reject the near miss
Dialog or Drawer for embedded content, and Popover for permanent visible content blocks.
Behavior contract
What must survive the build
- trigger
- Always visible as a structural container; hover and focus effects are presentation, not triggers.
- dismissal
- Not applicable; a card is a persistent container, not a dismissible surface.
- modality
- Non-modal structural content.
- focus
- Cards that act as links should contain a single link or use a wrapping strategy; interactive cards must keep nested controls independently focusable.
- keyboard
- Inline controls follow normal tab order; link-only cards should expose a single tab stop.
- interactive
- May contain links, buttons, or form controls; the card itself can be interactive when it wraps one primary action.
- persistence
- Persistent until content changes, filtering, or navigation removes it.
- placement
- Typically arranged in a grid, list, or stack layout.
- mobile
- Cards often span the full viewport width; stacked layouts are preferred over dense grids on narrow screens.
Failure modes
Common wrong builds
- Nesting interactive controls inside a clickable card without managing focus.
- Using a card as a surrogate dialog.
- Omitting heading structure inside cards.
- Making every card the same visual weight regardless of content priority.
Observable checks
Verify the result
- The card has a clear heading where appropriate.
- Links and buttons are separately focusable.
- No text or control sits outside a meaningful landmark.
- Clickable cards expose one primary action.
- Mobile layout stacks cards legibly.
Coding-agent handoff
Implementation brief template
Pattern: Card Purpose: Group and present related content in a digestible, scannable unit. Trigger: Always visible as a structural container; hover and focus effects are presentation, not triggers. Dismissal behavior: Not applicable; a card is a persistent container, not a dismissible surface. Modality: Non-modal structural content. Focus behavior: Cards that act as links should contain a single link or use a wrapping strategy; interactive cards must keep nested controls independently focusable. Keyboard behavior: Inline controls follow normal tab order; link-only cards should expose a single tab stop. Interactive content: May contain links, buttons, or form controls; the card itself can be interactive when it wraps one primary action. Placement: Typically arranged in a grid, list, or stack layout. Mobile behavior: Cards often span the full viewport width; stacked layouts are preferred over dense grids on narrow screens. Do not implement as: Dialog or Drawer for embedded content, and Popover for permanent visible content blocks. Acceptance checks: - The card has a clear heading where appropriate. - Links and buttons are separately focusable. - No text or control sits outside a meaningful landmark. - Clickable cards expose one primary action. - Mobile layout stacks cards legibly.
Claim-level references
Sources, not a confidence score
Frequently asked questions
Card UI pattern questions
Direct answers based on the reviewed behavior contract above.
What is a Card in web UI?
A self-contained container that groups related content and optional actions into a recognizable rectangular surface, often with a header, body, and footer. In this reference set it is a composite pattern made from multiple controls or regions that must work together.
When should I use a Card?
Group and present related content in a digestible, scannable unit. The decisive boundary to confirm is this: A Card is a container pattern, not a semantic surface like a Dialog. Do not confuse a clickable card with a button unless the entire region must remain operable as one control.
What keyboard and focus behavior does a Card need?
Inline controls follow normal tab order; link-only cards should expose a single tab stop. Cards that act as links should contain a single link or use a wrapping strategy; interactive cards must keep nested controls independently focusable. These statements describe the reviewed expectation, but the final implementation still needs testing in the component library and browser you ship.
How should a Card behave on mobile?
Cards often span the full viewport width; stacked layouts are preferred over dense grids on narrow screens. Its modality is a separate requirement: Non-modal structural content.
How do I verify a Card implementation?
Start with observable checks: The card has a clear heading where appropriate. Links and buttons are separately focusable. No text or control sits outside a meaningful landmark. Then verify the remaining checks and compare the result with the linked source guidance.