Update color palette for better accessibility

[elichad]

This is achieved by overriding the Sass colors set in Bootstrap 4. I followed the guidance in the Bootstrap 4 docs. custom_bootstrap.css and custom_bootstrap.css.map are both generated by Sass based on custom_bootstrap.scss.

Most of the palette is copied from the Bootstrap 5 palette, but some customisation was needed to meet WCAG 2.1 AA contrast throughout, especially for links in striped tables. There is no change to the meaning of any color.

This PR will resolve the majority of contrast-related a11y issues across the whole UI, reducing pa11y failures from ~4400 to ~1300.

Example screenshots which use most of the palette:
Old palette:

New palette:

[pbanaszkiewicz]

Looks good. Kudos for such a big improvement in accessibility in one go!

I just want you to confirm if there is any impact on deployment with this new (S)CSS file introduced. I guess once we regenerate it, we should run collectstatic again?

Do you think it's worth updating README to capture these instructions in case someone wants to extend or modify our SCSS?

[pbanaszkiewicz]

Could you perhaps use some calculate function to get this value, for example:

$gray-650: hsl(208, 7%, 46% - 8%);  // hsl values for $gray-600

This is an example, as the value you entered for $gray-650 is hsl(206, 8%, 38%) - very similar to what I put above, but not quite the same.

...
After some thinking I decided to add here that using hsl or any other color function only makes sense if you modified another color by e.g. increasing or decreasing individual component (like lightness or saturation, or hue). If there's too many components changed then it doesn't really make any sense.

[elichad]

I switched to hsl, as it's mainly a lightness change (difference of 2 in the other components between gray-600 and gray-700).

[pbanaszkiewicz]

Should this filename contain .min?

[pbanaszkiewicz]

I'd prefer to put sass as dev dependency in package.json. This way everyone following readme will have it installed locally if they need to regenerate this file.

[elichad]

I think we will need to run collectstatic during deployment whenever this file is updated (this is part of the Ansible playbook already, is it also handled in the CDK deployment?)
On a local instance with DEBUG=True, Django picks up the files from static/ anyway, so you don't need to run/re-run collectstatic during development.