Overview
Introduction
The component and pattern library behind the Cayuse research administration suite. Every token, component and pattern on this site is generated from the Cayuse DS Figma file, so what you build matches what was designed.
Figma source: COVER ↗Components and patterns are not the same thing
The distinction runs through the whole of this site, and it is the one thing worth understanding before anything else.
A component is a single interface element with its own states and properties — a button, a checkbox, a status pill. It answers “what does this control look like and how does it behave?” Components live in Components.
A pattern is a complete design solution assembled from components. It answers “how do I solve this whole problem?” The Dialogs pattern does not describe a new control; it tells you when a modal is right and a drawer is wrong, and how the components you already have combine to make either. Patterns live in Patterns.
If you are asking “which do I use?”, start with a pattern. If you are asking “what does its disabled state look like?”, go to the component.
How the tokens are layered
The Figma file has four variable collections, and they form a strict hierarchy. The CSS mirrors it exactly.
| Layer | Figma collection | Example | Who consumes it |
|---|---|---|---|
| 1 · Primitives | color-primitives, text-primatives, spacing | --color-blue-300 | Only the semantic layer |
| 2 · Semantics | semantics | --button-primary-background | Component CSS |
| 3 · Components | component CSS | .cds-button--primary | Product code |
A component rule must never reach past the semantic layer. Writing
background: var(--color-blue-300) instead of
var(--button-primary-background) works today and breaks the moment the
brand colour changes — you would have to find every component that hardcoded blue
instead of editing one alias. The 104 semantic tokens exist precisely so that
re-theming touches one file.
Using the CSS
Three stylesheets, loaded in order. Products ship the first two; the third styles this documentation only.
<!-- Layer 1 + 2: primitives and semantic aliases -->
<link rel="stylesheet" href="css/tokens.css">
<!-- Layer 3: the components themselves -->
<link rel="stylesheet" href="css/components.css">
<!-- Lato and IBM Plex Mono -->
<link href="https://fonts.googleapis.com/css2?family=Lato:wght@400;700&display=swap" rel="stylesheet">Class names follow a BEM-ish convention: .cds-block__element--modifier.
The cds- prefix keeps the library from colliding with the product styles it
is dropped into.
A note on the .is-* classes
Components respond to real CSS states — :hover,
:focus-visible, :disabled. The parallel
.is-hover and .is-focus classes exist so this documentation
can pin a state open for display. Never ship them. If you find
.is-hover in product code, it is a bug: it will look hovered to everyone,
forever.
Accessibility baseline
The target is WCAG 2.1 Level AA. Three commitments hold across every component:
- Everything reachable by keyboard. If a mouse can do it, Tab and Enter can do it, in an order that matches the visual layout.
- Focus is always visible. A single shared focus treatment — 2px, offset 2px — appears on every interactive element.
- Colour is never the only signal. Status pills carry a label,
errors carry text, required fields carry an asterisk and a programmatic
required.
An audit of the shipped tokens found four combinations below the AA threshold, including the link hover colour, which is less readable than the resting state. They are listed with measured ratios and suggested fixes on the Color page. Each affected component page carries the same warning inline.