In lots of international locations, internet accessibility is a human proper and the regulation, and there may be heavy fines for non-compliance. Naturally, which means that textual content and icons and such should have optimum coloration distinction in accordance with the benchmarks set by the Net Content material Accessibility Pointers (WCAG). Now, there are fairly a couple of coloration distinction checkers on the market (Figma even has one built-in now), however the upcoming contrast-color() perform doesn’t verify coloration distinction, it outright resolves to both black or white (whichever one contrasts probably the most together with your chosen coloration).
Proper off the bat, you must know that we’ve sorta checked out this function earlier than. Again then, nevertheless, it was known as color-contrast() as an alternative of contrast-color() and had a way more convoluted manner of going about issues. It was solely launched in Safari Know-how Preview 122 again in 2021, and that’s nonetheless the case on the time I’m penning this (now at model 220).
You’d use it like this:
button {
--background-color: darkblue;
background-color: var(--background-color);
coloration: contrast-color(var(--background-color));
}Right here, contrast-color() has decided that white contrasts with darkblue higher than black does, which is why contrast-color() resolves to white. Fairly easy, actually, however there are a couple of shortcomings, which features a lack of browser help (once more, it’s solely in Safari Know-how Preview for the time being).
We are able to use contrast-color() conditionally, although:
@helps (coloration: contrast-color(crimson)) {
/* contrast-color() supported */
}
@helps not (coloration: contrast-color(crimson)) {
/* contrast-color() not supported */
}The shortcomings of contrast-color()
First, let me simply say that enhancements are already being thought-about, so right here I’ll clarify the shortcomings in addition to any enhancements that I’ve heard about.
Undoubtedly, the primary shortcoming is that contrast-color() solely resolves to both black or white. When you don’t need black or white, properly… that sucks. Nonetheless, the draft spec itself alludes to extra management over the resolved coloration sooner or later.
However there’s one different factor that’s surprisingly straightforward to miss. What occurs when neither black nor white is definitely accessible towards the chosen coloration? That’s proper, it’s potential for contrast-color() to only… not present a contrasting coloration. Ideally, I believe we’d need contrast-color() to resolve to the closest accessible variant of a most well-liked coloration. Till then, contrast-color() isn’t actually usable.
One other shortcoming of contrast-color() is that it solely accepts arguments of the contrast-color() for 2 coloration stops/one linear gradient):
button {
background: linear-gradient(to proper, crimson, blue);
span {
background: linear-gradient(to proper, contrast-color(crimson), contrast-color(blue));
coloration: clear;
background-clip: textual content;
}
}The explanation this seems so horrid is that, as talked about earlier than, contrast-color() solely resolves to black or white, so in the midst of the gradient we basically have 50% gray on purple. This downside would additionally get solved by contrast-color() resolving to a wider spectrum of colours.
However what in regards to the font dimension? As you would possibly know already, the factors for coloration distinction will depend on the font dimension, so how does that work? Effectively, for the time being it doesn’t, however I believe it’s protected to imagine that it’ll ultimately take the font-size into consideration when figuring out the resolved coloration. Which brings us to APCA.
APCA (Accessible Perceptual Distinction Algorithm) is a brand new algorithm for measuring coloration distinction reliably. Andrew Somers, creator of APCA, carried out research (alongside many different unbiased research) and discovered that 23% of WCAG 2 “Fails” are literally accessible. As well as, an insane 47% of “Passes” are inaccessible.
Not solely ought to APCA do a greater job, however the APCA Readability Criterion (ARC) is way extra nuanced, considering a a lot wider spectrum of font sizes and weights (hooray for me, as I’m very a fan of 600 as a typical font weight). Whereas the criterion is expectedly advanced and unnecessarily complicated, the APCA Distinction Calculator does a decent-enough job of explaining the way it all works visually, for now.
contrast-color() doesn’t use APCA, however the draft spec does allude to providing extra algorithms sooner or later. This wording is odd because it means that we’ll be capable of select between the APCA and WCAG algorithms. Then once more, we’ve to do not forget that the legal guidelines of some international locations would require WCAG 2 compliance whereas others require WCAG 3 compliance (when it turns into a typical).
That’s proper, we’re a good distance off of APCA changing into part of WCAG 3, not to mention contrast-color(). In actual fact, it won’t even be part of it initially (or in any respect), and there are numerous extra hurdles after that, however hopefully this sheds some gentle on the entire thing. For now, contrast-color() is utilizing WCAG 2 solely.
Utilizing contrast-color()
Right here’s a easy instance (the identical one from earlier) of a darkblue-colored button with accessibly-colored textual content chosen by contrast-color(). I’ve put this darkblue coloration right into a CSS variable in order that we will outline it as soon as however reference it as many instances as is important (which is simply twice for now).
button {
--background-color: darkblue;
background-color: var(--background-color);
/* Resolves to white */
coloration: contrast-color(var(--background-color));
}And the identical factor however with lightblue:
button {
--background-color: lightblue;
background-color: var(--background-color);
/* Resolves to black */
coloration: contrast-color(var(--background-color));
}Initially, we will completely swap this up and use contrast-color() on the background-color property as an alternative (or in-place of any
button {
--color: darkblue;
coloration: var(--color);
/* Resolves to white */
background-color: contrast-color(var(--color));
}Any legitimate
button {
/* HSL this time */
--background-color: hsl(0 0% 0%);
background-color: var(--background-color);
/* Resolves to white */
coloration: contrast-color(var(--background-color));
}Want to vary the bottom coloration on the fly (e.g., on hover)? Straightforward:
button {
--background-color: hsl(0 0% 0%);
background-color: var(--background-color);
/* Begins off white, turns into black on hover */
coloration: contrast-color(var(--background-color));
&:hover {
/* 50% lighter */
--background-color: hsl(0 0% 50%);
}
}Equally, we may use contrast-color() with the light-dark() perform to make sure accessible coloration distinction throughout gentle and darkish modes:
:root {
/* Darkish mode if checked */
&:has(enter[type="checkbox"]:checked) {
color-scheme: darkish;
}
/* Gentle mode if not checked */
&:not(:has(enter[type="checkbox"]:checked)) {
color-scheme: gentle;
}
physique {
/* Totally different background for every mode */
background: light-dark(hsl(0 0% 50%), hsl(0 0% 0%));
/* Totally different contrasted coloration for every mode */
coloration: light-dark(contrast-color(hsl(0 0% 50%)), contrast-color(hsl(0 0% 0%));
}
}The fascinating factor about APCA is that it accounts for the discrepancies between gentle mode and darkish mode distinction, whereas the present WCAG algorithm typically evaluates darkish mode distinction inaccurately. This one nuance of many is why we want not solely a brand new coloration distinction algorithm but in addition the contrast-color() CSS perform to deal with all of those nuances (font dimension, font weight, and so forth.) for us.
This doesn’t imply that contrast-color() has to make sure accessibility on the expense of our “designed” colours, although. As an alternative, we will use contrast-color() inside the prefers-contrast: extra media question solely:
button {
--background-color: hsl(270 100% 50%);
background-color: var(--background-color);
/* Nearly white (WCAG AA: Fail) */
coloration: hsl(270 100% 90%);
@media (prefers-contrast: extra) {
/* Resolves to white (WCAG AA: Move) */
coloration: contrast-color(var(--background-color));
}
}Personally, I’m not eager on prefers-contrast: extra as a progressive enhancement. Nice coloration distinction advantages everybody, and apart from, we will’t make certain that those that want extra distinction are literally arrange for it. Maybe they’re utilizing a model new laptop, or they simply don’t know learn how to customise accessibility settings.
Closing ideas
So, contrast-color() clearly isn’t helpful in its present kind because it solely resolves to black or white, which could not be accessible. Nonetheless, if it had been improved to resolve to a wider spectrum of colours, that’d be superior. Even higher, if it had been to improve colours to a sure commonplace (e.g., WCAG AA) in the event that they don’t already meet it, however allow them to be in the event that they do. Kind of like a failsafe method? Because of this internet browsers must take the font dimension, font weight, factor, and so forth into consideration.
To throw an alternative choice on the market, there’s additionally the method that Home windows takes for its Excessive Distinction Mode. This mode triggers internet browsers to overwrite colours utilizing the forced-colors: lively media question, which we will additionally use to make additional customizations. Nonetheless, this impact is sort of excessive (although we can choose out of it utilizing the forced-colors-adjust CSS property and use our personal colours as an alternative) and macOS’s model of the function doesn’t lengthen to the net.
I believe that compelled colours is an unbelievable thought so long as customers can set their distinction preferences once they arrange their laptop or browser (the browser could be extra enforceable), and there are a wider vary of distinction choices. After which if you happen to, as a designer or developer, don’t just like the enforced colours, then you will have the choice to satisfy accessibility requirements in order that they don’t get enforced. For my part, this method is probably the most user-friendly and probably the most developer-friendly (assuming that you simply care about accessibility). For full flexibility, there might be a CSS property for opting out, or one thing. Simply coloration distinction by default, however you may hold the colours you’ve chosen so long as they’re accessible.
What do you assume? Is contrast-color() the appropriate method, or ought to the person agent bear some or all the accountability? Or maybe you’re glad for coloration distinction to be thought-about manually?
