Checkbox Card

Sizes

<CheckboxCard size="sm" label="Small" body="Body copy" />

<CheckboxCard size="md" label="Medium" body="Body copy" />

States

<CheckboxCard label="Rest" body="Body copy" />

<CheckboxCard label="Selected" body="Body copy" defaultChecked />

Disabled

<CheckboxCard label="Accept terms" body="Body copy" disabled />

<CheckboxCard label="Accept terms" body="Body copy" disabled defaultChecked />

With descriptor

<CheckboxCard label="Accept terms" body="You can withdraw your consent at any time." />

<CheckboxCard label="Accept terms" descriptor="Optional second line" body="You can withdraw your consent at any time." />

Hit target

<CheckboxCard label="Accept terms" body="Click anywhere on this card." />

When to use

Use a checkbox card when a single boolean choice needs more room to explain itself than a one-line checkbox label allows — a title, an optional second line, and a body line of context, all inside one clearly-bounded target.

Because the whole card is the hit target, it also suits layouts where the target needs to be comfortably large (pricing rows, plan choices, permission toggles) without losing the checkbox’s meaning.

When not to use

• A setting that applies immediately, with no save/submit step: use a switch card instead — its on/off framing implies the change has already taken effect.
• A short, self-evident label: use a plain checkbox. A card adds padding for no benefit when there is nothing to explain.
• Rich card content — links, buttons, images, anything interactive: not supported. The card is a single label/pressable, so nested interactive content would be invalid. The three text slots are strings for exactly this reason.
• A group of related options: compose several cards; a card-list component is not built yet.

Checkbox Card vs Switch Card

The two are the same card with a different control in the corner — same width, same two sizes, same text slots. Pick by what the choice means: a checkbox card is a value the user is confirming, a switch card is a setting that takes effect immediately.

Props

The card’s props are derived from CheckboxProps: it is Omit<CheckboxProps, 'label' | 'labelPosition' | 'aria-label'> plus the required label and body slots, so any prop Checkbox accepts — size, descriptor, id, name, value, required and the rest — is accepted here too, and a prop added to Checkbox reaches CheckboxCard without a second edit. labelPosition is omitted because the card owns the layout; aria-label (web) is omitted because the card composes the accessible name from label and descriptor.

Import

Web

import { CheckboxCard } from '@checkatrade/components-web';

Native

import { CheckboxCard } from '@checkatrade/components-native';

Basic usage

Controlled (both platforms):

const [accepted, setAccepted] = useState(false);
<CheckboxCard
  label="Accept terms"
  body="You can withdraw your consent at any time."
  checked={accepted}
  onChange={setAccepted}
/>;

Uncontrolled (both platforms):

<CheckboxCard label="Accept terms" body="Body copy" defaultChecked />

With the optional descriptor:

<CheckboxCard
  label="Accept terms"
  descriptor="Optional second line"
  body="You can withdraw your consent at any time."
/>

Platform status

The Figma source is marked Caution because the selected border resolves to a different value than Figma draws, and the rest stroke is ahead of Figma — see Token gaps below.

Accessibility

Web

• The card is a <label> wrapping the text block and the control, so the whole card is a click target — clicking the label, descriptor or body toggles the checkbox exactly once.
• The control is a real <input type="checkbox">, focusable and toggled with Space. The card does not add a second announcement.
• The accessible name is the label and the descriptor joined as "label. descriptor" — the same string SwitchCard produces for the same content. The body is exposed as the accessible description, not concatenated into the name — web has a description slot, so it uses it.
• The styled box is decorative (aria-hidden="true"); state lives on the input.
• The focused state is a 4px focus-ring outline drawn outside the card, and appears on keyboard focus rather than mouse click.

React Native

• The card’s root Pressable is not an accessibility node and is not a tab stop, so it adds no second announcement.
• The control keeps its own semantics: accessibilityRole="checkbox" with accessibilityState={{ checked, disabled }}.
• Native has no accessible-description slot, so the name is the label, descriptor and body joined with a full stop — e.g. "Accept terms. Optional second line. Body copy". A consumer accessibilityLabel overrides it outright.
• The text block and the body are visible but hidden from assistive tech on both native and the web surface, so the control stays the single source of the accessible name.
• The whole card is the tap target. Pressing the text or the body toggles the control exactly once.

Target size

The whole card is the target on both platforms, so the effective hit area is far larger than the 16–32px control at every size.

Token gaps

• Native Text cannot take the card’s label tokens. Web colours the label, descriptor and body from the selector label tokens in every state. Native Text has no colour escape hatch, so native keeps the default ink and dims a disabled card’s text instead.
• No surface-tone-aware card tokens. The card’s selector tokens have no inverse counterpart, so inside an inverse surface the card keeps its normal-surface colours. This applies to the control’s tokens too.
• The selected border is a close match, not an exact one. Figma draws it at #0036fa; the card binds --color-selector-border-selected, which resolves to #040154. The token is what the card uses — there is no literal — and the difference is a deliberate deviation signed off with Design.
• The native card and the web card are close but not identical. Fill, border, hover and the selected and disabled states match. Native cannot apply the label tokens, so its text does not recolour on hover or selection, and a disabled card dims its text instead.

No releases yet.