Colour and Theming

Status: normative foundation and engineering reference

Version: 0.1

This document defines how HIF specifies, derives, implements and verifies colour systems. Colour is simultaneously light, material, perception, information, identity and an implementation value. Treating it as a list of hexadecimal literals loses the conditions under which a colour has meaning.

Applied implementation: HIF Colour Lab generates and audits palettes under the constraints in this document. Its output is decision support and implementation material, not a conformance certificate.

1. Scope and governing principles

A conforming colour system MUST:

• begin with communication, task and environmental requirements;
• distinguish measured colour from appearance and named colour;
• assign semantics independently of current colour values;
• preserve meaning without colour alone;
• honour user and platform contrast settings before brand expression;
• declare colour spaces, reference whites, gamut and conversion policy;
• cover every state, mode, theme, medium and supported display class;
• expose traceable tokens rather than ungoverned literals;
• be tested as rendered, not approved from a palette sheet;
• retain source, licence and change provenance for every external asset.

Colour MUST NOT be used to manufacture urgency, conceal a consequence, make an unfavourable choice visually unavailable or imply a state the system has not established.

2. Colour is a human–physical relation

2.1 Vision and adaptation

Visible colour arises from the spectral distribution reaching the eye, the spectral sensitivities and adaptation state of the observer, and spatial and temporal context. A digital triplet is not an intrinsic description of appearance.

Design and evaluation SHOULD account for:

• display luminance, black level, flare and ambient illumination;
• chromatic adaptation and the surrounding field;
• size, spatial frequency and duration of the stimulus;
• simultaneous contrast and local background;
• ageing, visual impairment and colour-vision variation;
• display calibration, operating-system processing and viewing angle;
• the difference between emitted, reflected and transmitted light.

The same nominal colour can appear different on two devices or beside two surrounds. Conversely, different stimuli can be metameric for one observer and condition. HIF therefore uses numerical colour values as reproducible inputs, not as proof of identical perception.

2.2 Colorimetry

CIE colorimetry represents a spectral stimulus using tristimulus values for a defined standard observer and illuminant. A colour specification used for exchange MUST identify enough of the following to be unambiguous:

colour model or colour space
coordinates and alpha
transfer functions
RGB primaries, where applicable
reference white and adaptation
observer and illuminant, where applicable
encoding range and bit depth
ICC profile or equivalent output condition
rendering intent or gamut-mapping policy

Colorimetric equality is not a complete model of appearance, legibility, preference or meaning. Perceptual uniformity in Lab, LCH, Oklab or OkLCH is an engineering approximation, not a claim that equal numerical steps are equally visible in every context.

2.3 Additive and subtractive contexts

Displays create colour primarily by additive mixing of emitted primaries. Print and pigmented objects modify incident light through absorption, scattering and reflection; process printing is commonly controlled through CMYK separations, inks, substrate and an output profile.

RGB and CMYK values MUST NOT be converted by copying channel percentages. Production for print MUST define:

• output process and ICC characterisation/profile;
• substrate, ink set, total area coverage and black-generation policy;
• viewing illuminant and proofing conditions;
• spot colours and tolerances where brand matching requires them;
• overprint, transparency and trapping policy;
• an accessible non-colour representation when meaning is critical.

Screen simulation of print is a soft proof, not a press acceptance result.

3. Colour-space policy

3.1 Required distinctions

HIF distinguishes:

• device-dependent RGB: values interpreted through a specified device or profile;
• sRGB: the baseline web RGB space and fallback delivery gamut;
• Display P3: a wider RGB gamut with D65 white, available on capable platforms;
• CIE XYZ: a device-independent tristimulus reference;
• CIE Lab/LCH: approximately perceptual Cartesian/polar spaces tied to a reference white;
• Oklab/OkLCH: approximately perceptual spaces designed for improved hue and lightness behaviour in modern colour computation;
• CMYK/spot channels: output-process coordinates, not universal appearance coordinates.

HSL and HSV MAY be used as authoring controls where their interaction is understood, but MUST NOT be treated as perceptually uniform palette spaces. Their equal numeric steps do not produce equal perceived steps.

3.2 Working and delivery spaces

Each product MUST declare:

OkLCH is RECOMMENDED for controlled palette derivation because lightness, chroma and hue can be adjusted with fewer unwanted interactions than in HSL. It does not remove the need for contrast calculation, gamut mapping or visual testing.

3.3 Alpha and compositing

An alpha colour has no final appearance until composited. Contrast MUST be calculated from the resulting rendered foreground and background, including:

• every backdrop through translucent layers;
• gradients, images and video;
• blend and filter effects;
• antialiasing and text rendering;
• disabled, hover, focus and selected overlays.

A translucent semantic foreground SHOULD be replaced by an opaque derived token when predictable contrast is required. Opacity MUST NOT be the only means of communicating disabled or unavailable state.

4. Gamut and mapping

4.1 Gamut contracts

Every palette colour MUST be classified as:

• valid in the baseline sRGB gamut;
• enhanced in Display P3 with a specified sRGB fallback;
• output-specific and unavailable in a required medium; or
• invalid for that delivery contract.

Wide-gamut colour MUST be a progressive enhancement. The fallback MUST retain role, hierarchy, contrast and state distinctions; it need not preserve maximum chroma.

4.2 Mapping rules

Channel clipping can change hue and relations between colours. Conversion MUST use a declared, deterministic mapping appropriate to the content and medium. For individual CSS colours, follow the current CSS Color gamut-mapping requirements implemented by supported user agents. For imagery and print, choose rendering intent according to the need to preserve individual colorimetric values or relationships across the image.

The mapping record MUST contain:

source and destination spaces
algorithm and implementation version
white-point adaptation
rendering intent
out-of-gamut count or mask
maximum and distribution of colour difference
approved exceptions

Do not optimise only the nearest individual colour. Preserve ordered lightness, separability, contrast and semantic relationships after mapping.

5. Palette architecture

5.1 Four layers

measured or chosen source colours
→ primitive scales
→ semantic roles
→ component tokens
→ rendered combinations and states

Primitive names such as azure.60 MAY describe a scale. Product and component code MUST consume semantic roles such as colour.text.primary or colour.status.danger.background.

5.2 Deriving a primitive scale

A scale generator MUST accept at least:

• a seed hue or set of anchors;
• target lightness positions;
• chroma policy by lightness and gamut;
• neutral-axis policy;
• baseline and enhanced gamuts;
• minimum adjacent perceptual difference;
• rounding and serialisation precision.

Recommended procedure:

1. establish the role inventory and required contrast pairs;
2. choose neutral and chromatic anchors in the working space;
3. define monotonically ordered lightness targets;
4. constrain chroma so each result maps acceptably into required gamuts;
5. solve critical foreground/background pairs before decorative uses;
6. check adjacent steps using the declared colour-difference measure;
7. simulate colour-vision variations as a diagnostic;
8. render real components in every state and mode;
9. adjust the system, not isolated failing swatches;
10. freeze generated values with algorithm, version and test evidence.

Equal lightness increments are a starting model, not a sufficient scale. Near-black and near-white steps, small marks and low-chroma neutrals require rendered inspection.

5.3 Semantic role inventory

At minimum, define paired foreground/background and border roles for:

• canvas, base, raised, overlay and inverse surfaces;
• primary, secondary, disabled and inverse text;
• links and visited links where history is exposed;
• accent and focus;
• selection and current item;
• information, success, warning, danger and neutral status;
• controls in rest, hover, active, focus-visible, selected, disabled, read-only, invalid, busy and unavailable states;
• data visualisation categories, sequences and divergence;
• code, syntax and diff content where supported.

Status families MUST distinguish:

status semantic
× emphasis level
× foreground/background/border/icon
× interaction state
× colour mode
× contrast mode

5.4 Neutrals

“Grey” is not semantically neutral by itself. A neutral scale MAY be chromatic, but its hue bias MUST NOT make a surface appear to carry a status. Neutrals MUST maintain stable hierarchy under common display variation and forced colour replacement.

6. Contrast and standards status

6.1 WCAG 2.2

WCAG 2.2 is a W3C Recommendation and is the normative web baseline used by HIF unless a Product Profile adopts a stricter requirement. Apply its exact scope and exceptions:

• normal text: at least 4.5:1 under Success Criterion 1.4.3;
• large-scale text: at least 3:1 under 1.4.3;
• enhanced level: 7:1 normal and 4.5:1 large text under 1.4.6;
• information-bearing user-interface components and graphical objects: at least 3:1 against adjacent colours under 1.4.11;
• colour MUST NOT be the only visual means of conveying information or prompting a response under 1.4.1.

Use WCAG's sRGB-relative-luminance and contrast-ratio algorithm for conformance. Do not substitute Lab/Oklab lightness, a design-tool score, a screenshot eyedropper or APCA for a WCAG 2.2 claim.

Evaluate actual font size and weight, not token labels such as “large”. Text over gradients or images MUST pass at the least favourable required region or receive a reliable backplate.

6.2 APCA and WCAG 3

APCA is a developing contrast model associated with research towards future accessibility guidance. WCAG 3.0 is, at the date of this document, a W3C Working Draft rather than a W3C Recommendation. Neither APCA nor a WCAG 3 draft MUST be presented as replacement conformance to WCAG 2.2.

A team MAY calculate APCA experimentally if it records:

• algorithm and version;
• intended research question;
• text size, weight, polarity and context;
• differences from the WCAG 2.2 decision;
• a human evaluation plan;
• that the result is non-normative.

When standards mature, HIF MUST review the evidence and migrate explicitly; silent threshold replacement is prohibited.

6.3 Beyond pairwise ratios

Conformance ratios do not establish readability. Test:

• typeface, size, weight and rendering;
• glare, low luminance and high luminance;
• thin strokes and small icons;
• spatial separation and crowding;
• polarity and prolonged viewing;
• state-to-state and control-to-surround distinction;
• cognitive interpretation and non-colour cues.

7. Colour-vision variation

The design MUST remain operable and understandable with relevant red–green, blue–yellow and low-chroma discrimination limitations. Simulators are diagnostic transformations, not evidence that every observer will see the simulation.

For every material distinction, supply one or more independent cues:

• label or value;
• shape or icon;
• line style, texture or pattern;
• position or grouping;
• direct annotation;
• persistent state text.

Do not encode two independent variables through nearby hues alone. For categorical data, test pairwise distinction at the actual mark size and against the actual background. For status, test comprehension, not merely difference.

8. Modes and themes

8.1 Dimensions

Keep these dimensions independent:

• light/dark colour scheme;
• increased, reduced or custom contrast;
• forced colours;
• brand;
• platform;
• density;
• environmental mode;
• data-visualisation scheme.

A “dark brand” is not dark mode. A high-contrast theme is not a more saturated brand palette.

8.2 Dark mode

A dark theme MUST be designed as a new set of relationships, not an inversion. It SHOULD:

• control maximum luminance and large-area glare;
• preserve hierarchy without relying on shadows alone;
• reduce chroma where high chroma blooms against dark surrounds;
• avoid pure black/white dogma when other values test better;
• maintain familiar status meanings without forcing identical coordinates;
• retest images, syntax, charts, elevation and disabled states;
• declare color-scheme or platform equivalents where supported.

8.3 Forced colours and user contrast

In web forced-colours mode, user-agent and system colours normally replace author colours. HIF components MUST:

• use native semantics and system colour keywords where appropriate;
• retain visible focus, boundaries, selection and state;
• avoid background images as the only signifier;
• use forced-color-adjust: none only for a bounded element that implements an equivalent accessible mapping itself;
• test user-defined palettes, not only a vendor's default high-contrast theme.

forced-colors: active does not necessarily mean “more contrast”; it means a forced user palette. Do not infer preference beyond the media-query contract.

8.4 State matrix

Every interactive role MUST have a reviewed matrix:

Combinations such as focused+selected+invalid MUST be specified. The matrix MUST be tested in every supported mode; deriving states by fixed opacity is insufficient.

9. Colour in data visualisation

Select a palette by data semantics:

• qualitative for unordered categories;
• sequential for ordered magnitude;
• diverging for meaningful deviation around a defined centre;
• cyclic for periodic values where endpoints meet;
• highlight for context plus one or few focal values.

Requirements:

• lightness order MUST match ordered data where lightness carries magnitude;
• a diverging centre MUST correspond to a real analytical reference;
• qualitative colours MUST remain distinguishable at actual mark size;
• missing, filtered, estimated and out-of-range values need explicit roles;
• legends MUST use the same order and symbols as the plot;
• direct labels are preferred where they reduce lookup;
• redundant shape, line style, pattern or text MUST carry critical distinctions;
• palette size MUST be limited by demonstrated discrimination, not a brand colour inventory;
• WCAG non-text contrast applies to information-bearing graphics in its scope.

ColourBrewer schemes are research-grounded starting points, not automatic approval for a particular background, number of classes, display or print process. Preserve licence notices when an external palette is used.

10. Images, media and print

Raster and vector assets MUST have:

• an embedded or explicitly assigned colour profile;
• a defined conversion/export path;
• an approved baseline-gamut fallback;
• checks for alpha edges and compositing;
• print proofing where print is an output;
• alternative representation when colour carries information.

Brand spot colours MUST record the physical reference, measurement condition, allowable colour difference, substrate/process classes and approval authority. A single screen hex value is not a spot-colour specification.

11. Token and implementation contract

11.1 Token layers

colour.primitive.*
colour.semantic.*
colour.component.*

Each semantic colour token MUST record:

identifier and description
value by mode, gamut and platform
expected foreground/background partners
permitted components and prohibited uses
minimum WCAG requirement
non-colour cue requirement
fallback and forced-colour mapping
source, algorithm and version
owner and review date

Token aliases MUST be acyclic and type-correct. A build MUST fail on missing mode values, unresolved aliases, invalid syntax, out-of-contract gamut or a known contrast failure.

11.2 CSS delivery example

:root {
  color-scheme: light dark;
  --colour-surface-base: #ffffff;
  --colour-text-primary: #1f2328;
  --colour-focus: #0969da;
}

@media (prefers-color-scheme: dark) {
  :root {
    --colour-surface-base: #0d1117;
    --colour-text-primary: #f0f6fc;
    --colour-focus: #58a6ff;
  }
}

@media (forced-colors: active) {
  :focus-visible {
    outline: 2px solid Highlight;
  }
}

This example illustrates architecture only. Its values are not a universal HIF palette and do not establish component conformance.

12. Deterministic selection algorithm

For each required semantic role:

1. state the information, action or surface relation;
2. enumerate modes, states, media and required pairings;
3. set normative contrast and non-colour-cue constraints;
4. choose a working-space anchor consistent with brand and convention;
5. solve lightness first for critical pairs;
6. constrain chroma and hue for gamut, status and pairwise distinction;
7. derive baseline sRGB and optional enhanced values;
8. run automated syntax, gamut, contrast and token-graph checks;
9. render the complete state matrix over real content and backgrounds;
10. test zoom, forced colours, colour-vision variations and supported devices;
11. test interpretation with representative people for consequential uses;
12. record values, algorithm, exceptions, evidence and owner.

If no candidate satisfies all hard constraints, change the composition, backplate, typography or redundant cue. Do not waive accessibility by searching indefinitely for a “better colour”.

12.1 Hard gates and aesthetic ranking

The selection engine MUST separate rejection constraints from preference objectives. Invalid syntax, unresolved tokens, out-of-contract gamut, failed required contrast, missing non-colour cues and indistinguishable consequential states are hard failures. Aesthetic ranking MUST NOT compensate for them.

Candidates that pass every hard gate MAY then be ranked by declared product-specific objectives such as monotonic lightness, chroma restraint by displayed area, hue stability, perceptual spacing, proximity to approved brand anchors and the minimum number of competing colour families.

There is no universal HIF “pleasantness score”, maximum OkLCH chroma or 60–30–10 area ratio. The product MUST record its emphasis policy and validate it with representative compositions and people. Use the Colour System Profile Template as the canonical generator input and release record.

13. Acceptance tests

13.1 Automated

• Every colour parses in its declared space.
• Every required token resolves for each mode, platform and gamut.
• Alias graphs are complete and acyclic.
• Baseline values are in sRGB or have an approved mapping.
• Required foreground/background pairs meet declared WCAG 2.2 thresholds.
• State pairs meet product distinguishability thresholds.
• Generated scale lightness is monotonic where specified.
• External assets contain expected profiles and provenance.
• Screenshots cover all state/mode/theme combinations.

13.2 Manual and human

• Focus, selection, errors and disabled states remain distinct.
• Meaning survives greyscale and relevant colour-vision diagnostics.
• Forced-colour and user palettes preserve structure and operation.
• Dark mode has no unacceptable glare, halation or lost elevation.
• Text over media passes at every required position.
• Charts retain ordering, category distinction and missing-data meaning.
• Representative devices, ambient conditions and print proofs were checked.
• People can identify consequential status and action without colour names.

13.3 Release evidence

The release record MUST name test inputs, rendering engines, devices, display settings, profiles, algorithms, standard versions, failures, exceptions and residual risks. A palette image or automated report alone is insufficient.

14. Sources

All sources are English-language original research, standards or official specifications. Retrieval date: 30 July 2026.

• CIE 015:2018, Colorimetry, 4th Edition:
  https://www.cie.co.at/publications/colorimetry-4th-edition
• IEC 61966-2-1, sRGB colour space:
  https://webstore.iec.ch/en/publication/6169
• International Color Consortium, ICC specifications:
  https://www.color.org/specification/ICC.1-2022-05.pdf
• W3C, CSS Color Module Level 4:
  https://www.w3.org/TR/css-color-4/
• W3C, CSS Color Module Level 5:
  https://www.w3.org/TR/css-color-5/
• W3C, CSS Color Adjustment Module Level 1:
  https://www.w3.org/TR/css-color-adjust-1/
• W3C, Media Queries Level 5:
  https://www.w3.org/TR/mediaqueries-5/
• W3C, Web Content Accessibility Guidelines 2.2:
  https://www.w3.org/TR/WCAG22/
• W3C, Understanding Success Criterion 1.4.1 — Use of Color:
  https://www.w3.org/WAI/WCAG22/Understanding/use-of-color.html
• W3C, Understanding Success Criterion 1.4.3 — Contrast (Minimum):
  https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html
• W3C, Understanding Success Criterion 1.4.11 — Non-text Contrast:
  https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html
• W3C, WCAG 3.0 Working Draft:
  https://www.w3.org/TR/wcag-3.0/
• W3C, WCAG 3 introduction and maturity status:
  https://www.w3.org/WAI/standards-guidelines/wcag/wcag3-intro/
• Brettel, Viénot and Mollon (1997), computerised simulation of dichromatic colour appearance:
  https://doi.org/10.1364/JOSAA.14.002647
• Machado, Oliveira and Fernandes (2009), a physiologically based model for colour-vision-deficiency simulation:
  https://doi.org/10.1109/TVCG.2009.113
• Brewer, Hatchard and Harrower (2003), ColorBrewer in Print:
  https://doi.org/10.1559/152304003100010929
• Design Tokens Community Group, Format Module 2025.10:
  https://www.w3.org/community/reports/design-tokens/CG-FINAL-format-20251028/
• Design Tokens Community Group, Color Module 2025.10:
  https://www.w3.org/community/reports/design-tokens/CG-FINAL-color-20251028/
• Design Tokens Community Group, Resolver Module 2025.10:
  https://www.w3.org/community/reports/design-tokens/CG-FINAL-resolver-20251028/