Implement more systematic use of colour #147

james-nash · 2018-06-20T15:28:03Z

Our modest 4 page website designs already include many different styles of links and also a button. The use of colour for those interactive elements is very ad hoc as we never defined any clear guidance or rules.

This story is to establish and implement a more systematic use of colour with the goal of encouraging (enforcing?) more consistent usage in the future.

james-nash · 2018-08-23T15:51:15Z

@buildit/gravity-maintainers

After much thought and experimentation, I'm now leaning towards a solution along these lines:

Concept

Define a smallish set of CSS custom properties representing colour purposes
- There should also be some rules on which pairs of colours are allowed to be combined into foreground / background pairs.
Define one or more colour themes, which are assignments of colour values (taken from our brand palette) to those custom properties.
- The colour assignments should ensure that each permitted pairing has a contrast ratio that meets at least WCGA 2.0 AA criteria
- There is at least one, "default", colour theme which is essentially set on via the body (or perhaps :root) selector in CSS.
- Every other theme would have a class selector, which simply overrides the values of the custom properties. They'd also set: background-color: var(--grav-co-bg); and color: var(--grav-co-fg);, so that whatever container they are is coloured correctly.
Downstream, in the styles for UI components, colours must always reference those CSS properties (or, alternatively, use inherit or currentColor)

Using this approach, every UI component would become themable. Likewise, it would become very easy to add more themes (or to temporarily alter our UI colours - e.g. for seasonal events).

Prototype

I have put together a prototype of this in CodePen here: https://codepen.io/cirrus/pen/wxVqxG

At the time of writing, this prototype has 10 colour purposes:

  --grav-co-fg
  --grav-co-bg

  --grav-co-fg-secondary
  --grav-co-bg-secondary
  
  --grav-co-fg-primary
  --grav-co-bg-primary
  
  --grav-co-fg-tertiary
  --grav-co-bg-tertiary
  
  --grav-co-fg-neutral
  --grav-co-bg-neutral

--grav-co-fg is the default foreground colour. It is allowed to be paired up with any of the 5 --grav-co-bg* colours.

Similarly, --grav-co-bg is the default background colour and may be paired with any of the 5 --grav-co-fg* colours.

Then, each theme should assign colours to each of those 10 custom properties such that all permitted pairings meet AA standards.

The "primary", "secondary", "tertiary" and "neutral" colours are intended to be applied in the UI as follows:

Primary should be used sparingly for key UI elements that need to grab the user's attention. E.g. CTA links, form submit buttons, etc.
Secondary should be used for all other interactive elements (buttons, checkboxes, links, etc.) or content that needs to visually stand out from its surroundings but not be as attention-grabbing as "primary" stuff.
Tertiary should be used visited links and other non-default states of interactive UI elements
Neutral should be used for disabled elements or for visually separating items on the page (e.g. divider lines, borders, etc.)

The prototype displays all the pairings and calculates their respective contrast ratios. As you can see, the current assignments for "Default theme" and "Dark theme" (which are approximations of the Buildit website's current body and footer styles) don't quite meet those contrast constraints.

The "crazy" theme is proof of concept (and fugly) theme, simply to demonstrate that you can in principle, choose colours that meet the necessary a11y requirements. 😛

The "new default" and "new dark" themes are experiments to see, if a slightly different assignment of existing Buildit brand colours (and also introduction of additional colours) could create more accessible themes.

Questions

Are 10 colours enough to adequately colour every UI element we have today and might need in the foreseeable future? (Do we need more or less?)
Are categories like "primary", "secondary", etc. appropriate and intuitive?
- Should they have other names (more abstract? more specific?)
Does the bg / fg naming approach succeed in making permitted colour pairing easy to identify?

Please chime in with thoughts, questions, ideas, etc. below. Thanks!

james-nash · 2019-02-22T11:46:16Z

Thanks to a lengthy brainstorming session with @dw-buildit, we now have a more refined concept and prototype.

Rather than the fg/bg naming scheme proposed before, we instead divide the set of colour purposes (which each colour scheme then assigns actual colour values to) into 2 layers. Any colour from the 1st layer may be paired with any colour from the 2nd layer and that combo will be guaranteed to have an accessible contrast ratio. There is however no requirement for colour pairs within the same layer to have any particular contrast ratio.

So, when styling UI components, if something needs to be perceivable - e.g. text on a background, or the boundary of a UI control against its surrounding background - then you simply need to pick a colour from a different group than the surroundings.

Colour schemes can be applied to any container (and the page itself is a container which will have a default colour scheme set on it). This not only updates the values of all the colour purposes (which are exposed as CSS custom properties), but also sets the color and background-color for that container.

Setting a colour scheme on a UI component that is not a container (or wrapped in one) is not supported. For the most part, we expect this to be the "atomic" components (e.g. buttons, icons, form inputs, etc.). For now we're calling them "final" components (because it's akin to a final method or property in OOP which cannot be overridden) and the intention would be to make this explicit in their documentation somehow.

Some nice benefits this will give us are:

The layer concept (whose name we may still change - perhaps "group" is a better name?) should lower the learning curve. Based on the layer (which we'd probably make explicit in the custom prop names) you can quickly determine which colour may be adjacent to which other when you need perceivable contrast.
Since there's no guarantee for colour purposes within a layer to have high contrasts between them, you're free to assign the same colour to several of them in a particular colour scheme. An extreme use of this is to make all 1st layer colours white and all 2nd layer colours black. If our UI components are using the system correctly, they should still be perceivable with that colour scheme applied to them. While this might not be useful for production, it does give us a handy a11y testing tool since this effectively simulates colour blindness! (we've built this into the prototype!)

We came to the conclusion that the next step is to try and stress-test this idea with lots of different UI components. I have started a prototype here: https://codepen.io/cirrus/project/editor/AyaaEd which aims to do just that.

To get us up and running quickly, we used the colours from Solarized to make light and dark colour schemes. Obviously these aren't the Buildit Gravity colours (and I doubt they have the AA contrast ratios we want) but for the purpose of visualising the idea its sufficient.
The page's default is the light scheme, but as you can see, the dark scheme has been applied to various sections. Note how all components within automatically adapt their colours to match.
You can nest colour schemes as much as you like. So, we have light within dark within light in some places to demo this.
We added syntax highlighted code blocks (produced by Prism.js) since they're probably one of the most colourful UI components we're likely to use, so that should be a good stress test.
The "Toggle a11y test" button at the top switches on a special pure B&W theme that overrides everything on the page and can be used to check that the UI components are still perceivable with the absence of colour (as described above).

Here's a screenshot of it in action in our prototype:

Instead of SASS vars that get compiled to explicit values, Gravity now uses CSS custom properties. This allows color values to be overridden via the CSS cascade, so different parts of a page can have different color schemes applied to them. BREAKING CHANGE: All `grav-co-*` SASS vars have been removed. The new CSS custom properties should be used instead. fix #147