Color

Palette

The base palette provides raw color values organized by function. Each group spans 10 shades from darkest (900) to lightest (50), used to differentiate contrast levels and visual hierarchy.

• Primary — Dark anchors for headings, text, and UI structure
• Accent — Brand blue for interactive elements, links, and focus states
• Info — Softer blue for informational feedback, distinct from brand accent
• Neutral — Gray scale for text hierarchy, borders, and surfaces
• Green / Yellow / Red — Status colors for success, warning, and error states

Why info is not accent

Both are blue, and separating them costs a whole palette group. The reason: on a transfer screen, accent blue means you can act on this and info blue means the system is telling you something. When they were the same hue, users tapped informational banners expecting them to do something. Info was pulled toward gray-blue (#3B82B8 at 600) until the two read as different roles at a glance.

Status colors are deliberately muted

Status values are one to two steps softer than their conventional equivalents — green-600 is #22915A rather than a saturated #16A34A, red-600 is #BB4A4A rather than #DC2626.

A transfer app shows status constantly. Every pending transaction, every rate alert, every verification step carries a status color. At full saturation the dashboard reads as an emergency. Muted status colors let a genuine error — a failed transfer, a rejected document — actually stand out, because it is not competing with eleven other colored chips.

All muted values were re-verified against AA after toning down. Softening never came out of the contrast budget.

Two neutral steps are off-ramp

Placeholder contrast is the most common AA failure in shipped design systems, and it is invisible in review because the reviewer knows what the field is for. Fixing it in the palette means no component can reintroduce it.

Semantic usage

Components reference semantic tokens, not raw palette values. This indirection allows theme switching and ensures consistent intent across the system.

Surface layering model

Senco stacks at most three surface levels. The model is defined here once so that a card inside a sheet inside a dialog does not become an improvised gray.

Rules:

• Level 1 is raised by shadow in light mode, by lightness in dark mode. Light mode uses --ds-shadow-xs on white; dark mode cannot use shadow on near-black, so #1E293B sits above #0F172A by value instead.
• Never stack two level-1 surfaces. A card inside a card means the inner one should be a level-2 inset or a divider.
• Borders do the work shadows cannot. At level 2 and in dark mode, --ds-border separates surfaces. Elevation alone is not sufficient in dark mode and never in high-contrast mode.
• --ds-white is a semantic token, not a color. In dark mode it resolves to #1E293B. Anything that means literal white uses #FFFFFF directly — which in practice is only --ds-on-accent.

Feedback colors

Each feedback state uses a set of background, border, text, and icon tokens for consistent signaling:

Warning text uses the 900 step where the others use 800. This is a visual weight decision, not a contrast one: yellow-800 (#854D0E) measures 6.46:1 on yellow-50 and passes AA comfortably. At 800 the warning text read lighter than the success and error text beside it in a stacked notice list, so it takes one more step down.

An earlier version of this file justified the 900 step by claiming 800 measured 4.3:1 and failed. It does not. The claim was plausible — yellow is the hue where AA is hardest — which is exactly why it survived unchallenged. Recording the correction here rather than quietly swapping the sentence.

For the full token architecture (base → semantic → state → component → platform → bridge), see Tokens.

Contrast verification

All color pairings are validated against WCAG 2.2 AA requirements: 4.5:1 for text, 3:1 for UI components. Every ratio below is computed from the token value that actually ships, not from a sampled screenshot.

Light mode (verified)

For dark mode contrast verification, see Themes.

Non-text contrast

Text is not the only thing that must clear a bar. WCAG 2.1 SC 1.4.11 requires 3:1 for UI components and meaningful graphics.

The four feedback borders are a known and accepted deviation. SC 1.4.11 governs boundaries that are the only indicator of a component's presence or state. A feedback notice signals itself with a tinted background, a 700-step icon, and a text label, all of which clear their own thresholds — the 400-step border is a refinement on an already-identified surface, not the thing that identifies it. Holding the border to 3:1 would push it to the 600 step, at which point the notice reads as an outlined alert box rather than a tinted one, and the muted-status decision above gets undone. The trade is recorded rather than carried silently.

The resting input border at 1.24:1 is a second known and accepted deviation. SC 1.4.11 applies to controls whose boundary is the only indicator of their presence. Senco inputs always carry a persistent visible label above the field and a 48px filled control area, so the field is identifiable without its border. Darkening the border to gray-400 was tested and made dense forms — the contact address form has nine fields — read as a cage. The deviation is recorded rather than silently carried.

Color is never the only signal

Triple signaling is mandatory for every status in the system: color + icon + text.

About 1 in 12 men has a color vision deficiency, and deuteranopia collapses exactly the green/yellow/red axis this app relies on. Under simulation, green-600 and yellow-600 converge to near-identical muddy tones. The icon and the label are what carry the meaning; the color is reinforcement. See Status indicators.

How contrast is verified

Verification is not a one-time audit. Every pairing in these tables is re-checked when a base token changes, because a single base edit cascades through the semantic layer into every component. Changing --ds-accent-600 invalidates the link, focus ring, primary button, and tip token rows at once.

Usage guidelines

• Always use semantic tokens in components — never reference base palette directly
• Pair color with icon + text for status indicators (never color alone)
• Focus: bordered controls turn the border --ds-focus and add a 20% halo; borderless controls take a 3px solid --ds-focus outline with a 2px offset. See Tokens
• Disabled states rely on both color and a visual cue, never color alone

Do and don't

The submitted-versus-completed rule is the one that matters most. Green in a money app is read as done, and in cross-border transfer a submitted payment can still fail two days later. Submitted is --ds-info-*; completed is --ds-success-*.

Color on dark surfaces

Fixed-dark surfaces — camera viewfinder, QR scanner — do not follow the theme. They stay #111827 in both modes and use hard-coded light values for their overlays. A viewfinder that inverts in light mode costs the user their frame of reference and gains nothing. This is the one documented exception to semantic theming; it lives in Tokens.

Known gaps