Approximating contrast-color() With Different CSS Options

You may have a component with a configurable background colour, and also you’d prefer to calculate whether or not the foreground textual content needs to be gentle or darkish. Appears simple sufficient, particularly realizing how conscious we should be with accessibility.

There have been a number of drafts of a specification operate for this performance, most lately, contrast-color() (previously color-contrast()) within the CSS Colour Module Stage 5 draft. However with Safari and Firefox being the one browsers which have applied it up to now, the ultimate model of this performance is probably going nonetheless a methods off. There was loads of performance added to CSS within the meantime; sufficient that I wished to see whether or not we might implement it in a cross-browser pleasant manner at the moment. Right here’s what I’ve:

colour: oklch(from  spherical(1.21 - L) 0 0);

Let me clarify how I acquired right here.

WCAG 2.2

WCAG supplies the formulation it makes use of for calculating the distinction between two RGB colours and Stacie Arellano has described in nice element. It’s based mostly on older strategies, calculating the luminance of colours (how perceptually brilliant they seem) and even tries to clamp for the restrictions of screens and display flare:

L1 + 0.05 / L2 + 0.05

…the place the lighter colour (L1) is on the highest. Luminance ranges from 0 to 1, and this fraction is accountable for distinction ratios going from 1 (1.05/1.05) to 21 (1.05/.05).

The formulation for calculating the luminance of RGB colours are even messier, however I’m solely making an attempt to find out whether or not white or black may have greater distinction with a given colour, and may get away with simplifying somewhat bit. We find yourself with one thing like this:

L = 0.1910(R/255+0.055)^2.4 + 0.6426(G/255+0.055)^2.4 + 0.0649(B/255+0.055)^2.4

Which we can convert into CSS like this:

calc(.1910*pow(r/255 + .055,2.4)+.6426*pow(g/255 + .055,2.4)+.0649*pow(b/255 + .055,2.4))

We will make this entire factor spherical to 1 or 0 utilizing spherical(), 1 for white and 0 for black:

spherical(.67913 - .1910*pow(r/255 + .055, 2.4) - .6426*pow(g/255 + .055, 2.4) - .0649*pow(b/255 + .055, 2.4))

Let’s multiply that by 255 and use it for all three channels with the relative colour syntax. We find yourself with this:

colour: rgb(from   
  spherical(173.178 - 48.705*pow(r/255 + .055, 2.4) - 163.863*pow(g/255 + .055, 2.4) - 16.5495*pow(b/255 + .055, 2.4), 255)  
  spherical(173.178 - 48.705*pow(r/255 + .055, 2.4) - 163.863*pow(g/255 + .055, 2.4) - 16.5495*pow(b/255 + .055, 2.4), 255)  
  spherical(173.178 - 48.705*pow(r/255 + .055, 2.4) - 163.863*pow(g/255 + .055, 2.4) - 16.5495*pow(b/255 + .055, 2.4), 255)  
);

A method that, given a colour, returns white or black based mostly on WCAG 2. It’s not simple to learn, nevertheless it works… besides APCA is poised to switch it as a more recent, higher method in future WCAG pointers. We will do the mathematics once more, although APCA is an much more difficult method. We might leverage CSS capabilities to scrub it up somewhat, however finally this implementation goes to be inaccessible, arduous to learn, and tough to take care of.

New Method

I took a step again and considered what else we have now obtainable. We do have one other new function we are able to check out: colour areas. The “L*” worth within the CIELAB colour area represents perceptual lightness. It’s meant to replicate what our eyes can see. It’s not the identical as luminance, nevertheless it’s shut. Perhaps we might guess whether or not to make use of black or white for higher distinction based mostly on perceptual lightness; let’s see if we are able to discover a quantity the place any colour with decrease lightness we use black, and better lightness we use white.

You may instinctively assume it needs to be 50% or .5, nevertheless it isn’t. Quite a lot of colours, even after they’re brilliant, nonetheless distinction higher with white than black. Right here’s some examples utilizing lch(), slowly rising the lightness whereas preserving the hue the identical:

The transition level the place it’s simpler to learn the black textual content than white normally occurs between 60-65. So, I put collectively a fast Node app utilizing Colorjs.io to calculate the place the minimize off needs to be, utilizing APCA for calculating distinction.

For oklch(), I discovered the brink to be between .65 and .72, with a median of .69.

In different phrases:

• When the OKLCH lightness is .72 or above, black will all the time distinction higher than white.
• Beneath .65, white will all the time distinction higher than black.
• Between .65 and .72, usually each black and white have contrasts between 45-60.

So, simply utilizing spherical() and the higher certain of .72, we are able to make a brand new, shorter implementation:

colour: oklch(from  spherical(1.21 - L) 0 0);

For those who’re questioning the place 1.21 got here from, it’s in order that .72 rounds down and .71 rounds up: 1.21 - .72 = .49 rounds down, and 1.21 - .71 = .5 rounds up.

This method works fairly effectively, having put a pair iterations of this method into manufacturing. It’s simpler to learn and preserve. That mentioned, this method extra intently matches APCA than WCAG, so typically it disagrees with WCAG. For instance, WCAG says black has a better distinction (4.70 than white at 4.3) when positioned on #407ac2, whereas APCA says the other: black has a distinction of 33.9, and white has a distinction of 75.7. The brand new CSS method matches APCA and reveals white:

Arguably, this method could do a greater job than WCAG 2.0 as a result of it extra intently matches APCA. That mentioned, you’ll nonetheless must examine accessibility, and in the event you’re held legally to WCAG as an alternative of APCA, then perhaps this newer less complicated method is much less useful to you.

LCH vs. OKLCH

I did run the numbers for each, and except for OKLCH being designed to be a greater alternative for LCH, I additionally discovered that the numbers help that OKLCH is a better option.

With LCH, the hole between too darkish for black and too gentle for white is usually greater, and the hole strikes round extra. For instance, #e862e5 by means of #fd76f9 are too darkish for black and too gentle for white. With LCH, that runs between lightness 63 by means of 70; for OKLCH, it’s .7 by means of .77. The scaling of OKLCH lightness simply higher matches APCA.

One Step Additional

Whereas “most-contrast” will definitely be higher, we are able to implement yet one more trick. Our present logic merely provides us white or black (which is what the color-contrast() operate is at the moment restricted to), however we are able to change this to offer us white or one other given colour. So, for instance, white or the bottom textual content colour. Beginning with this:

colour: oklch(from  spherical(1.21 - L) 0 0);  

/* turns into: */

--white-or-black: oklch(from  spherical(1.21 - L) 0 0);  
colour: rgb(  
  from color-mix(in srgb, var(--white-or-black), )  
  calc(2*r) calc(2*g) calc(2*b)  
);

It’s some intelligent math, nevertheless it isn’t nice to learn:

• If --white-or-black is white, color-mix() ends in rgb(127.5, 127.5, 127.5) or brighter; doubled we’re at rgb(255, 255, 255) or greater, which is simply white.
• If --white-or-black is black, color-mix() cuts the worth of every RGB channel by 50%; doubled we’re again to the unique worth of the .

Sadly, this method doesn’t work in Safari 18 and under, so you want to goal Chrome, Safari 18+ and Firefox. Nonetheless, it does give us a manner with pure CSS to modify between white and a base textual content colour, as an alternative of white and black alone, and we are able to fallback to white and black in Safari <18.

It’s also possible to rewrite these each utilizing CSS Customized Capabilities, however these aren’t supported in all places but both:

@operate --white-black(--color) {  
  outcome: oklch(from var(--color) spherical(1.21 - l) 0 0);  
}

@operate --white-or-base(--color, --base) {  
  outcome: rgb(from color-mix(in srgb, --white-black(var(--color)), var(--base)) calc(2*r) calc(2*g) calc(2*b));  
}

Conclusion

I hope this method works effectively for you, and I’d prefer to reiterate that the purpose of this method — on the lookout for a threshold and a easy method — is to make the implementation versatile and simple to adapt to your wants. You’ll be able to simply modify the brink to no matter works finest for you.