The new CSS Color 4 specification added new ways to declare colours in CSS, including for various kind of wide gamut colour spaces/monitors. Don’t worry if you have an old monitor; browsers try to find the nearest displayable colour.
I’ve been reading some evangelising of one of the specs that’s called OKLCH (L = Light, C = Chroma, H = Hue. I think the OK means it’s ‘Okay compared to plain old LCH.’) The reason I mention it on intfiction is that it should make it easier to create more accessible-to-read text, or to support tools that do the same.
It produces predictable results with consistent perceived lightness levels. It can do things like modify the hue of a colour without altering the perceived lightness. RGB was never intuitive for colour modification (how much red do I add to get so-and-so?) and HSL was never accurate for it because its lightness is not evenly mapped.
A real world example is – you’ve looked up some colour combination that will produce sufficiently contrasty text. You could now move a slider (or adjust a single value) to try it out in different hues without losing the contrast and accessibility tick. Currently, you tend to have to muck around a ton moving other sliders and making subjective judgments, or just go back to looking up lists of pre-tested colour value combinations.
You can read a highly technical breakdown of the format and features (and other CSS 4 colour spaces) in this article at Evil Martian design.
Speaking about contrast and changing web standards…
The WCAG 2.X standard’s algorithm for determining adequate contrast is flawed, and it’s not hard to find false positives and false negatives, i.e., combinations that their contrast ratio algorithm say are great that are obviously far from great and combinations that the algorithm says are unacceptable that are clearly adequate or even pretty good. And it has little to say about font-weight and size, merely defining one ratio as adequate for “large-scale” text – either at least a 24px font-size (at any font weight), or both a bold font-weight and at least an 18.66px font-size – and a higher contrast ratio for anything that isn’t “large-scale”, stating no minimum for font size. And it was created before anyone was thinking about dark mode, and some ratios it defines as accessible are truly awful in dark mode.
The WCAG 3.0 draft defines a new system called APCA that is much, much, better, and takes font weight and size into account. Here’s an ACPA Contrast Calculator. I recommend using it!
WCAG 2.0 Level AA is a de facto legal standard for accessibility (at least in the US) so you’re best off picking a combination that also still satisfies it. (There’s federal law that calls for things to be accessible, but no legislation that defines what that means for the web. The Office of Civil Rights is very specific about how they’re an enforcement agency and not a policy agency so they’re not saying that WCAG 2.0 Level AA constitutes accessibility… it just happens to be the case that when there’s legal action regarding accessibility they keep deciding to say that you should become compliant with WCAG 2.0 Level AA to remedy it…)