Update components to use functional colours where possible

[36degrees]

Brief

There are two types of colour in the Design System and GOV.UK Frontend:

• functional colours, which represent a specific use case like 'text colour', 'focus colour' or 'error colour'
• colour palette, like 'black tint 80%', 'accent teal' or 'orange shade 50%'

Our components currently use a mix of functional colours and the colour palette. For example, inactive tabs use the 'text colour' for text, but the background is 'black tint 95%'.

We want to get to a place where we use functional colours wherever possible, setting us up to better support a potential dark mode, or other customisations to colours. When we're done, components should only use the colour palette where they reference colours directly, like the tag modifier classes which are based on the colours.

To achieve this we'll need to map the existing references to the colour palette to functional colours, creating functional colours to represent new use cases where required. We may also need to rename or remove existing functional colours if required (following our usual deprecation strategies) to make the system coherent.

By the end of the cycle we want to have:

• releasable, non-breaking changes to GOV.UK Frontend that make progress towards components using functional colours where possible, with release notes that explain any user-facing changes
• an update to the functional colours on the Design System colours page, reflecting any changes
• made a decision on the best way to unblock the interruption panel component (see point 3)

It's likely that we won't be able to fix all instances of components using the colour palette in a single cycle. A suggested priority list of activities might be…

1. Understand the current state

Audit the codebase to identify where components reference the colour palette directly (using the govuk-colour function) rather than using functional colours.

It might also be useful to spend some time looking at what other design systems or component libraries do.

Finally, it might be useful to document which functional colours are combined as foreground and background colours, so we know which functional colours need to meet contrast with each other.

2. Fix occurrences of functional colours and palette colours in combination

Prioritise fixing instances where functional colours and palette colours are used in combination (i.e. foreground and background colours use a mixture of both).

Addressing these occurrences should also resolve text being invisible or low contrast in older browsers that do not support CSS Custom Properties. These older browsers all fall in 'Grade X', but we do currently say that 'our CSS are still compatible with Internet Explorer 11'.

A non-exhaustive list of known occurrences includes:

• Header (hardcoded white foreground against against a brand background)
• Inverse links (hardcoded white foreground against a brand background)
• Inverse buttons (brand foreground on a white background)
• Inverse service navigation (white foreground on a brand background)
• Selects (text foreground on a hardcoded white background)
• Inactive tabs (text foreground on a hardcoded light grey background)
• Accordion hover states (a mix of hardcoded black and text foreground on a light grey background)
• Task list hover state (a mix of text and link-hover foreground on a light grey background)
• Pagination hover state (link foreground on a light grey background)
• Summary cards (text foreground on a light grey background)
• File upload (text foreground on a light grey background)
• Text input prefixes and suffixes (text foreground on a light grey background)

3. Unblock shipping the interruption panel

As part of our work on the interruption panel contribution we've identified a need to be able to make arbitrary content white when it appears within the panel.

We have a few different components that do something similar, but we're not consistent in our approach.

We would like to ship the interruption panel at the end of this cycle. Decide whether redefining the --govuk-text-colour custom property within the panel is the right approach to take now. If not, work out what the best possible solution is to enable us to ship the component this cycle.

If we decide that redefining the --govuk-text-colour custom property is the right approach, identify where else we should use this approach and create issues to represent the work involved. You might then choose to tackle some of this work as part of the next section.

4. Identify and fix other references to the colour palette

Fix other instances of references to the colour palette that should be updated to use functional colours.

A non-exhaustive list of known occurrences includes:

• Confirmation panel
• Button
• Exit this page overlay

5. Any other colour or custom properties related work

For example:

• [SPIKE] Set media overrides in functional colours map; support @media (prefers-contrast: more) #6788
• Deprecate print-text functional colour #6791
• Fix tests linting for presence of custom properties #6897
• Explore generalising how we output custom properties from a map #6487
• Automatically check we're not using var() statements as part of a shorthand property #6485
• border colour ratio with body-background is too low #6776
• Explore if useful to add custom properties for each value of the colour palette and spacing scale #6490 (colour only)
• Explore generalising how we output custom properties from a map #6487

Further detail

Out of scope is any design work for alternative sets of functional colours (e.g. dark mode).

For testing purposes I've found it useful to install a browser extension to allow you to set custom CSS on a webpage.

You can then use custom CSS to override the custom properties and see what breaks:

:root {
    --govuk-brand-colour: #1d70b8;
    --govuk-text-colour: #ffffff;
    --govuk-template-background-colour: #0F385C;
    --govuk-body-background-colour: #061625;
    --govuk-hover-colour: #cecece;
    --govuk-link-colour: #8EB8DC;
    --govuk-link-visited-colour: #AA98CF;
    --govuk-link-hover-colour: #D2E2F1;
    --govuk-link-active-colour: #0b0c0c;
    --govuk-surface-background-colour: #0F385C;
    --govuk-surface-text-colour: #ffffff;
    --govuk-surface-border-colour: #0F385C;
    --govuk-secondary-text-colour: #8EB8DC;
    --govuk-input-border-colour: #ffffff;
    --govuk-error-colour: #D76868;
    color-scheme: dark;
}

[36degrees]

A few examples of things that break when changing custom colours in the review app:

(It's not obvious, but this first example is showing a select, not a text input)

[36degrees]

Found another couple of issues that I think we might end up closing as part of this work:

• Text colour for inverse button should use variable that indicates design intent #3918
• Spike how we can use sass to support custom properties on older browsers #4925 (which I suspect we just want to close as not planned?)