Colours

Colour with a clear role

JR Dream’s colour system combines warm-neutral reading surfaces, charcoal structure and a precise orange accent. Colour supports brand expression, information hierarchy, accessible interaction and functional feedback through distinct roles.

Keep decorative brand orange separate from darker action orange. Use functional green, amber, red and blue only where a status justifies them, with words or another non-colour cue. The source’s 70% light/neutral, 20% dark and 10% accent balance is a visual guide, not a pixel quota.

The supplied logo has its own unchanged colours and gradients. Approximate logo samples are not extra interface colours. These are internally accepted working specifications, pending implementation validation and final company approval.

Source: Colour System Exploration & Validation v1.0, pages 1–3 and 12.

Core colour palette

The complete source-defined scales contain 11 warm neutrals and 10 oranges. Values and variable names below come directly from the existing central token file. Swatches carry their labels on a separate white surface, so the palette is not mistaken for approved text pairings.

Copy a HEX value or variable name using its button. If copying is unavailable, select the visible value manually; every value also remains available in print.

Neutral 50/100 provide fills; 200 is decorative; 500 identifies controls; 600 supplies supporting text on light; 900/950 provide dark structure. Orange 50/100 provide subtle fills, 300 inverse focus, 500 decoration, 700 actions/light focus and 800/900 action hover/pressed states. Scale numbers alone do not establish an accessible pairing.

Source: Colour System Exploration & Validation v1.0, page 3, “Two useful tonal scales”.

Brand and interaction colours

The brighter decorative orange cannot replace action orange for small white labels. Changing the interface action colour does not authorise recolouring the logo. Orange 500 on charcoal narrowly passes normal text at 4.52:1 in the source; reserve it for highlights and prefer white for extended inverse reading.

Source: Colour System Exploration & Validation v1.0, pages 2–5.

Semantic colour roles

Use the existing CSS names below to express intent. Their aliases and resolved HEX values are read from styles/tokens.css at build time; this page does not define a second colour system.

Functional foreground and surface tokens are listed in the next section. The neutral-800 inverse divider is an existing implementation reference, not an additional Colour PDF semantic role or a meaningful control boundary.

Source: Colour System Exploration & Validation v1.0, page 11, “Practical semantic colour tokens”; inverse-divider mapping also recorded in the Stage 02.1 implementation report.

Functional status colours

These four foreground/background pairs are defined for light status treatments. Each example includes explicit wording; none depends on colour alone. They are documentation demonstrations, not claims about actual records or outcomes.

Do not invent status ramps or inverse status variants. Keep these foregrounds on their paired light tints rather than reusing them directly on dark cards. Status tints need no visible outer boundary when their words carry the meaning.

Source: Colour System Exploration & Validation v1.0, pages 4, 6, 10 and 11.

Accessibility and contrast

The source uses WCAG 2.2 AA thresholds of 4.5:1 for normal text and 3:1 for large text. Large text means at least 18pt regular or 14pt bold (approximately 24px or 18.7px). Meaningful boundaries and graphics need 3:1 against adjacent colours where necessary to identify them.

Source columns reproduce the PDF’s ratios. Calculated columns independently apply the source’s sRGB relative-luminance method to the current CSS HEX values: (lighter luminance + 0.05) / (darker luminance + 0.05). Results are rounded to two decimals for display; verdicts use unrounded calculations. These calculated validation results do not create new brand rules.

Restrictions to carry into implementation

• Do not use decorative orange for small white labels or orange body text on white. A large-text PASS is not permission to use it for small interface labels.
• Neutral 200 is a decorative separator, not an essential input outline. Use neutral 500 for meaningful control boundaries on the tested light surfaces.
• Use orange 700 focus on light, orange 300 on inverse, and a local surface-coloured gap. Visibility, area and obstruction still require testing.
• Disabled controls use neutral 100 fill and neutral 600 labels with a native or correctly exposed disabled state. Remove active affordance and avoid whole-control opacity. Inactive controls have contrast exemptions; the documented pair deliberately remains readable.
• Keep explicit status/error wording and chart labels. Never communicate status or chart meaning through colour alone.
• Do not promote approximate logo amber, green or red-orange samples into extra brand primaries. Logo lettering’s contrast exception does not apply to ordinary branded text or controls.

For data visualisation, the source suggests action orange, information foreground and success foreground as a small categorical set on white, with direct labels, gaps and patterns as needed. Real charts also need values and a data table; no chart or colour-vision testing is claimed here.

These pair calculations do not establish comprehensive WCAG conformance. Recheck changed backgrounds, transparency, overlays and all implemented interaction states.

Source: Colour System Exploration & Validation v1.0, pages 4–6, 10 and 12; method and W3C source references on page 12.

Practical UI applications

These scoped documentation demonstrations show token usage. They are not production-ready components or a standalone component library.

The status demonstrations above also provide information notices, success feedback, warnings and explicit error guidance. Their light foreground/surface pairs remain intact.

Source: Colour System Exploration & Validation v1.0, pages 3–6 and 11; sidebar exception: Stage 02.1 accepted documentation-sidebar refinement.

Developer implementation

Use the existing semantic variables in the eventual corporate website, with the central token stylesheet included by that application. Use primitives to define roles centrally, rather than choosing a scale step afresh in each component. This documentation does not create a package, token engine or corporate website.

Semantic action and focus usage

.primary-action {
  background: var(--action-primary-background);
  color: var(--action-primary-text);
}
.primary-action:hover {
  background: var(--action-primary-hover);
}
.primary-action:active {
  background: var(--action-primary-pressed);
}
.secondary-action {
  background: var(--surface-primary);
  color: var(--action-secondary-text);
  border: var(--border-thin) solid var(--border-control);
}
.primary-action:focus-visible,
.secondary-action:focus-visible {
  outline: var(--focus-width) solid var(--focus-light);
  outline-offset: var(--focus-offset);
  box-shadow: 0 0 0 var(--focus-offset) var(--surface-primary);
}
.primary-action:disabled {
  background: var(--state-disabled-background);
  color: var(--state-disabled-text);
  cursor: default;
  /* Use the native disabled attribute; no whole-control opacity. */
}

Status and inverse-surface usage

.information-notice {
  color: var(--status-information);
  background: var(--status-information-surface);
  /* Include explicit guidance text, not colour alone. */
}
.inverse-panel {
  color: var(--text-inverse);
  background: var(--surface-inverse);
  --focus-ring: var(--focus-inverse);
  --focus-gap: var(--surface-inverse);
}
.inverse-panel :focus-visible {
  outline: var(--focus-width) solid var(--focus-ring);
  outline-offset: var(--focus-offset);
  box-shadow: 0 0 0 var(--focus-offset) var(--focus-gap);
}

Restricted usage: do not copy into production

/* RESTRICTED: do not ship these combinations. */
.small-white-label-on-bright-orange {
  color: var(--text-inverse);
  background: var(--brand-accent-primary); /* Fails normal text. */
}
.orange-body-on-white {
  color: var(--brand-accent-primary); /* Fails normal text. */
  background: var(--surface-primary);
}
.essential-boundary {
  border-color: var(--border-default); /* Decorative only. */
}
/* Use action-primary-background for small white action labels,
   text-primary for body copy and border-control for essential outlines. */

The snippets illustrate colour roles, not complete controls. Apply existing typography, spacing, geometry and keyboard behaviour separately, then validate each real foreground/background pair. Disabled rules must win over hover and pressed rules.

Preserve both original SVG assets. Primary Transparent belongs on suitable plain light surfaces and Reversed Transparent on charcoal/deep neutral. Do not place the logo on accent orange, imagery or patterned surfaces; see the Logo foundation guidance.

HEX/sRGB expresses digital intent. Print needs printer-managed profiles and physical proofs; no CMYK recipe or spot-colour match is approved.

Source: Colour System Exploration & Validation v1.0, pages 7, 9, 11 and 12; code is documentation implementation guidance.

Validation and approval status

Successful builds, browser checks and contrast calculations do not certify production readiness or comprehensive WCAG conformance. No final company approval is claimed.

Source: Colour System Exploration & Validation v1.0, page 12, “Recommended system and approval gates”; Stage 02.1 implementation limitations retained.