Colour roles for a SaaS landing page
Think in roles, not swatches
A landing page palette is easier to build and maintain when each colour has a job. The common roles are: a page background; a surface for cards and sections; primary text; muted text for secondary copy; a primary action colour for the main call to action; an accent for highlights; a border or divider colour; and status colours for success, warning and error. Most of these are neutrals. A palette that looks colourful usually has only one or two chromatic colours doing real work, with everything else a tinted grey.
The most useful rule for conversion-minded pages is one dominant action colour. If the button, links, badges and illustrations all use the same saturated hue, nothing stands out. Reserve the primary colour for the one thing you want clicked, and let the accent be quieter. The Brand and System navigators generate sets of four and five coloured roles that you can preview on a UI mock, and the mood chips such as trust or cool help narrow the hue before you refine it.
Contrast targets for text, buttons and UI parts
Three WCAG 2.2 thresholds cover most of a landing page. Text, including button labels, needs 4.5:1 against its background at normal size under SC 1.4.3 (3:1 for large text). The visual parts of controls, such as an input's border, an icon that carries meaning or a focus indicator, need 3:1 against adjacent colours under SC 1.4.11, Non-text Contrast. And colour must not be the only way to convey state under SC 1.4.1, so an error needs an icon or message as well as red. Disabled controls and logos are exempt from the contrast requirements.
The mistake the table below shows is a common one: a friendly mid-blue or green button with a white label. It looks right and fails at roughly 3.3–3.7:1. The fix is rarely a different hue; it is a lower OKLCH lightness for the fill. Because OKLCH lightness tracks perceived brightness, you can step the button darker and keep its hue recognisable. Check any pair in the contrast checker, and browse examples in the contrast library.
Hover, active and focus states in OKLCH
Interactive states are where ad-hoc palettes drift. A reliable approach is to define the resting colour once and derive the others by changing OKLCH lightness while holding hue and chroma, for example a step darker for hover and another for active on a light theme. Because the steps are perceptually even, the same offsets work for the primary, the success colour and the error colour. Re-check the label contrast on every state, not only on the resting one, since a hover that gets lighter can drop below 4.5:1. The guide to building OKLCH scales walks through generating a ramp with sensible chroma, and the OKLCH picker lets you nudge lightness directly and watch the sRGB gamut.
Dark mode is a second set of tokens, not an inversion
Simply inverting a light theme usually produces glare and muddy accents. A dark variant works better as its own mapping: a dark but not pure black background, a slightly lighter surface for cards, off-white text, and an accent whose lightness is raised so it still reads against the dark surface. Saturated colours also tend to look harsher on dark backgrounds, so lowering chroma slightly often helps. Muted text should be checked again, because a grey that passes on white may not pass on slate. The dark mode colour guide covers the trade-offs in detail.
From palette to design tokens
Once the roles are settled, write them down as tokens rather than scattering HEX codes. In plain CSS that means custom properties such as --color-bg, --color-text and --color-primary on :root, overridden for dark mode under a class or a prefers-color-scheme media query. In Tailwind CSS v4 the same names go in an @theme block, for instance --color-primary: oklch(0.55 0.2 260), which generates utilities like bg-primary and text-primary. Using oklch() values keeps the lightness steps readable in the source. The pairs navigators on this page can copy CSS variables or @theme tokens, and Studio extends a chosen set into full product scales. For gradients behind a hero, the OKLCH gradient tool avoids the grey midpoints that appear when blending complementary colours in sRGB.
Using APCA as a second opinion
WCAG 2.x ratios are what audits and procurement checklists use, so they are the requirement. APCA, the Accessible Perceptual Contrast Algorithm, is a candidate for a future WCAG 3 and is not a requirement today. It is still a useful sanity check because it accounts for polarity and gives a signed Lc value, which often explains why a pair that passes the ratio still feels weak, particularly light grey on a dark surface. Treat APCA as a way to catch borderline pairs, not as a replacement for the ratio. The WCAG vs APCA guide compares them on real colours. The sibling pages for business cards and presentations apply the same checks to print and to slides, and the blue hub is a good place to look for a trustworthy primary.