Short answer
Keep components on semantic tokens and let each brand supply only its base palette plus a small mapping. Then generate, rather than hand-pick, the dependent colours — on-colours, hover steps, dark-mode siblings — from rules based on lightness, and test every brand's semantic pairs automatically. The rules matter more than the brands: a system that says 'buttons use the brand step at L* 44 or darker' works for any hue; one that says 'buttons use the brand colour' works only for the brands that happen to be dark enough.
A multi-brand or white-label system serves several products, clients or sub-brands from one component library. The components, spacing, type scale and interaction patterns stay fixed; the brand supplies identity, mostly through colour and sometimes typography. In token terms, each brand provides a base palette and maps a handful of semantic roles — action-primary, accent, perhaps a tinted surface — to it. Everything else (neutrals, status colours, focus ring) usually stays shared, both because it rarely needs to vary and because status and focus colours must keep their meaning across brands. The fewer roles a brand controls, the fewer ways a new brand can break accessibility.
Given one brand primary, a system needs its on-colour (text on the brand fill), hover and pressed steps, a pale tint for selected backgrounds, and dark-mode equivalents. Hand-picking these per brand does not scale and drifts. Rules do: choose the on-colour by comparing the fill's contrast with black and white; generate hover by a fixed lightness step in OKLCH; take tints from fixed L* targets. The table applies the simplest rule — pick whichever of black or white contrasts more — to four example brand primaries. Every one gets a passing label, but two of the four primaries fall below 3:1 as a control boundary on a white page, so an outlined button in those brand colours would fail 1.4.11 even though the filled one is fine. The rule has to cover every use of the colour, not just the one designers look at first.
Rather than accept any hex value, a mature multi-brand system validates brand input: it checks the primary against the rules, and if the colour cannot meet them, it derives a compliant sibling for the roles that need contrast and keeps the original for identity roles such as illustration or a header band. Google's Material system goes further with dynamic colour, generating whole tonal palettes from a single source colour — including a user's wallpaper — in its HCT space, where tone is CIELAB L*, so contrast between roles is controlled by tone rather than by the chosen hue. The general lesson is that robust theming sets lightness by rule and lets the brand choose hue and chroma.
A system with four brands, light and dark modes and a high-contrast option has sixteen themes, and each has perhaps a hundred semantic foreground–background pairs. Nobody checks 1,600 pairs by eye. Contrast tests belong in the token build: resolve every semantic pair in every theme, compute WCAG ratios and fail the build below the role's target. Visual regression screenshots per theme catch what numbers miss, such as a brand tint that makes a status banner look like a selection. And keep a record of which brand colours were modified for compliance, so brand teams understand why their colour appears as a sibling in some places.
| Brand primary | Higher-contrast label colour | Primary against white page (3:1 for borders) |
|---|---|---|
| Brand A (teal) #008080 | #FFFFFF — 4.77:1 | 4.77:1 |
| Brand B (tomato) #FF6347 | #000000 — 7.12:1 | 2.94:1 (below 3) |
| Brand C (slate blue) #6A5ACD | #FFFFFF — 5.30:1 | 5.30:1 |
| Brand D (goldenrod) #DAA520 | #000000 — 9.38:1 | 2.23:1 (below 3) |
Why: Its primary is too light for a 3:1 border on white; only filled buttons were checked.
Fix: Validate every role the brand colour fills and derive a darker sibling for borders and text.
Why: Brands were allowed to override status roles.
Fix: Keep status and focus roles shared across brands.
Why: Contrast is checked manually on one theme.
Fix: Compute contrast for every semantic pair in every theme in the token build.
Each statement is labelled by kind — established fact, a standard’s requirement, observed market data, a convention, or Colourwise’s own interpretation or analysis — with the strength of the evidence behind it.
Colourwise analysisStrong evidence
Choosing black or white text by whichever has higher contrast gives every one of four example brand primaries a label above 4.5:1, but two of the four fall below 3:1 against a white page and so could not serve as a control boundary there.
Based on: Computed by Colourwise with the WCAG 2.2 formula using CSS named colours as example brand primaries; see the table.
Source: Web Content Accessibility Guidelines (WCAG) 2.2; CSS Color Module Level 4
FactModerate evidence
Google's Material Color Utilities generate tonal palettes and colour schemes from a source colour using the HCT space, in which tone corresponds to CIELAB L*, to support dynamic colour that adapts to themes and contrast preferences.
Source: Material Color Utilities (HCT colour space, tonal palettes, dynamic colour)
Colourwise interpretationModerate evidence
In a multi-brand system, fixing lightness by rule and letting each brand choose hue and chroma is a more reliable way to keep every theme accessible than validating hand-picked colours one by one.
Based on: Follows from WCAG contrast depending only on luminance (and so on L*), shown in the building-a-colour-scale topic, and from how tonal systems such as Material's are built.
Reviewed 29 September 2026. Colourwise summarises its sources in its own words and does not reproduce standards text or proprietary colour data. Spotted an error? Tell us.