Accessible Palette: stop using HSL for color systems (2021)
wildbit.com
wildbit.com
I'd point out though that with ordinary display and print systems, saturated reds and blues really are darker than greens. The exact formula depends on your color space but
Grayscale = 0.299R + 0.587G + 0.114B [1]
You can certainly use those colors but they are always going to be dark. Simply applying contrast rules will make your color choices accessible but if you want to make something accessible and that look good the techniques in that article will make you a winner.
For that matter, saturated screen greens are nowhere near as saturated as is possible but are more saturated than most greens you see in real life: I make red-cyan stereograms
https://en.wikipedia.org/wiki/Anaglyph_3D
and one rule of thumb is that trees and grass look great in stereograms because even though they are green, they actually have a lot of red so the balance between the channels is good so you get good stereo and good color.
[1] https://www.dynamsoft.com/blog/insights/image-processing/ima...
Yet when I look at today's typical "top quality" live broadcast content such as the 4K Super Bowl as delivered by mass consumer distribution such as Comcast Xfinity (via their latest high-end decoder box), it's a visual mess compared to what the signal chain should be capable of delivering.
Even though I have top notch viewing gear properly configured and calibrated (with local video processing 'enhancements' disabled), it looks terrible. Unfortunately, due to the layers of compression, conversion and DRM slathered on the signal before I receive it, it's extremely difficult to analyze what's going wrong. All I can determine is that it is a video feed being decompressed into a 4K-resolution, 4:2:2, 60fps frame buffer. However, examining still frame sequences reveals extensive motion, color and resolution artifacts.
The net effect conveys a sense of "sharpness" in the frequency domain at first glance but on critical viewing over time it's a weird kind of digital abomination of macro-blocked chroma splotches, lagged temporal artifacts and bizarre over-saturation of primary hues. While some pre-compressed streamed film content looks quite good when delivered via a streaming service willing to devote sufficient encoding time and delivery bitrate, it's still hit and miss. Live broadcast content, especially high-motion sports, is almost always a mess. We've come so far in standards and specifications yet still have so far to go in the actual delivered result to most households.
My favorite cable box sports example was a PGA tournament was showing a golfer putting on the green. The shot was an extremely tight close up of the ball sitting there as the golfer addressed the ball. All of the dimples in the ball were clear, and every blade of grass was visible until the golfer swung and made contact with the ball. As the camera panned to follow, the ball went to this white roundish shape with no detail and the grass went to this blurry green smear again with no detail. As soon as the ball went into the cup and the camera stopped moving, at least one GOP later the grass snapped into full detail again.
Their predictive model is tuned for low motion static content because that's what 90%+ of their content is. Even something like ESPN is now primarily talking heads of people talking about sports rather than being sports. Any sports show in replay and not live so who cares? Looking back at crappy SD tape captures, it's obvious that anything was better than nothing. Much like YouTube. People just want something, doesn't have to be amazing. If it looks like Picasso instead of Monet, they don't care as long as their minds don't have to think
Also, the signal was meant to have even more bandwidth. When the broadcasters decided to bring out the fractional channels, it didn't exactly fit the idea that Congress had when allocating the frequencies. Yet another example of how Congress can be behind the times in pretty much everything.
> Even though I have top notch viewing gear properly configured and calibrated
Any chance you'd be willing to share a few details about this?
> While some pre-compressed streamed film content looks quite good when delivered via a streaming service willing to devote sufficient encoding time and delivery bitrate, it's still hit and miss.
Which streaming services are doing things right in your view?
I have several viewing devices in different rooms including an LG C2 OLED, a high-end Samsung QLED and in my dedicated, fully light-controlled home theater room a native 4K 10-bit HDR+ laser projector and 150-inch screen. Each of these displays has been professionally calibrated. To objectively evaluate an input source these days it's important to try multiple different display technologies because flat screens can vary between OLED, QLED, mini-LED, LCD and VA which all have different trade-offs in contrast, peak brightness, viewing angles, color spaces, gamma response curves, etc. And that's before getting into various front projector technologies.
Most consumer TVs these days come with a pile of post-processing algorithms which claim to deliver various "enhancements." In almost all cases you'll want to turn these options off in the setup menus. For critical viewing, objective calibration with a suitable colorimeter is ideal, especially when considering HDR sources which should be normalized to each display's native capabilities in Nits. If you don't want to dive down the rabbit hole of evaluating all this yourself (which can admittedly get complex), I suggest the TV reviews at https://www.rtings.com which are credible, thorough and yet still relatively accessible to non-experts. Unfortunately, RTings doesn't evaluate front projectors. For that the best bet is an expert forum like AV Science (https://www.avsforum.com).
> Which streaming services are doing things right in your view?
Currently, I don't think there's any service I would say is universally "doing it right." It still varies depending on the individual piece of content. Amazon, Netflix, AppleTV and even YouTube each have some extremely well-encoded, high bitrate content. But I've also seen examples on each service that aren't great.
The highest-quality home source will typically be a UHD Blu-Ray disc player. If you have such a player I highly recommend the Spears and Munsil UHD Benchmark Discs (https://spearsandmunsil.com/uhd-hdr-benchmark-2023/). Just because a disc is UHD format doesn't mean the media on it has been encoded correctly, from a high-fidelity source and in appropriate quality. The Spears and Munsil disc features a comprehensive suite of custom-designed test signals and specially sourced demonstration content identically encoded in HD, UHD, HDR, HDR10, HDR10+ and DolbyVision, including moving-window split screens allowing you to compare formats. It's extremely impressive and, as a video engineering geek, I found it fascinating to explore for hours on my various displays - while my wife had zero interest in it :-).
I don't even watch that much TV content but when I do, I want it to not look like crap. It's frustrating because I'm sure the four national broadcast networks and top cable channels (eg ESPN, CNN, etc) are providing pristine source feeds at their head-end distribution points which look amazing. Is there even any meaningfully better-quality alternative these days? Maybe some over-the-top streaming provider of broadcast and cable channels who actually delivers 4k sources with guaranteed high-quality encoding and decent bitrates? If so, I'd cut the Comcast cord even if it costs more. It's not like Comcast is cheap but I also hate the idea of paying top dollar for such a substandard product simply because there are no better alternatives.
BTW: I'd be delighted to learn of any viable US-based content alternatives (eg streaming, direct satellite, etc). Back in the analog SDTV days I had a C-Band sat dish and the direct network feeds looked amazing in pure 6 Mhz analog component compared to local cable and even local OTA broadcast.
It's definitely better than it used to be, though.
(sRGB combines the Rec. 709 primaries with a certain nonlinear transfer function, while Display P3 combines the DCI-P3 primaries with the sRGB nonlinear transfer function and with the PAL/SECAM white, which is also used by Rec. 709 and sRGB).
With the DCI-P3 primaries, it is very noticeable that the red is much better, allowing the displaying of reddish colors that are simultaneously more saturated and brighter than what can be achieved with the Rec. 709 red.
While DCI-P3 also has a better green than Rec. 709, there the improvement is much less obvious than in the red area.
What matters is which are the colors that will be reproduced on the display when you send the digital codes corresponding to pure red, green and blue, through the DisplayPort or HDMI interfaces of the monitor.
All the good monitors have a menu for the selection of the color space that will be used by DisplayPort and HDMI, and the menu will typically present a choice between sRGB and Display P3 or DCI-P3. Even when in the menu it is written DCI-P3, what is meant is Display P3, i.e. the menu changes only the primaries, without changing the white or the nonlinear transfer function.
All monitors will process the digital codes corresponding to standard color spaces to generate the appropriate values needed to command their specific pixels in order to reproduce a color as close as possible to what is specified by the standard color space.
The cheapest monitors are able to display only a color space close to Rec. 709 a.k.a. sRGB, those of medium price are normally able to display a color space close to DCI-P3 and a few very expensive monitors and many expensive TV-sets, which use either quantum dots or OLED, are able to display a larger fraction of the Rec. 2020 color space (laser projectors can display the complete Rec. 2020 color space).
Even when a monitor can display bright and saturated reds, as long as it remains in the default configuration of using sRGB over DisplayPort and HDMI, you cannot command the monitor to display those colors. For that, you have to switch the color space used by DisplayPort and HDMI to a color space with a wider color gamut.
Some monitors, typically those that are advertised to support HDR, allow the use of the Rec. 2020 color space over DisplayPort and HDMI, but most such monitors cannot display the full Rec. 2020 color space, so the very saturated colors will either be clipped to maximum saturation or mapped to less saturated colors.
This is overly optimistic. It has gotten better lately but most monitors aren't calibrated as well as they could but. And not that long ago the RGB signals were directly mapped to the monitors colors.
Thank you for your beautiful turn of phrase which has made my evening brighter.
Happy to see I’m not the only one. This has been bugging me for a long time, how an “accessibility guidance” formula actually had the opposite effect. Why was that standardized?
See a partial listing of reviews: https://git.apcacontrast.com/documentation/independent-revie...
It’s funny, in a sad way, when you dig into it. The ‘scientific’ version is about 5 lightness points different from WCAG, on a scale of 100. That isn’t a coincidence. put somewhat more directly, it sure is funny these people made up contrast ratio out of thin air without evidence, and the answer that will save us has basically the same #s
Warning: super-long read, you will spend a day.
You'll be surprised, but I use some thoughts from this article in ClickHouse to color logs nicely: https://github.com/ClickHouse/ClickHouse/blob/master/base/ba...
Could you share what are your RGB expectations for every message type you have set in your code?
One thing I'll give a big shout out to in this article is APCA, which will likely be a successor to WCAG 2's color contrast algorithm. We used it internally here at Figma for our own accessibility revamp for a final result that ended up much better than it would have otherwise. Eugene provides some great examples of when WCAG 2 fails, and we were continually running into those.
That really brings me to my main piece of advice here: color is really hard to get right - any tool you have can help you along the way, but that said at some point you also have to trust your eye. At the end of the day, all of these tools are just providing some mathematical approximation for how your eye sees color. Your eye is the final source of truth, not the algorithms. If you're encountering areas where a tool or an algorithm aren't providing you the right result, switch it around or fall back to basics.
Can you go into more detail here? Do you mean you use only APCA and ignore what the WCAG 2 color contrast algorithm flags as insufficient contrast?
This was relevant for our Figma's brand color, as prior to our accessibility pass it wasn't compliant when combined with white text for neither WCAG 2 nor APCA. We modified it slightly to be #0D99FF, which was close enough to the original brand color it didn't feel like a rebrand, while still allowing us a passing APCA color contrasts score. Notably though it doesn't pass WCAG 2, but you'll see from this example the contrast is significant: https://image.non.io/15ed7558-5337-40fc-9e5b-2392087cc35b.we...
That's not to say though that APCA is a perfect solution. Interestingly, should APCA be adopted as the WCAG standard, Figma and Hackernews both would fail contrast guidelines. Part of APCA is a guideline for what font size/weight combinations are allowed for any color contrast level. Even with #000 and #fff as your colors, fonts under 11.5px are not allowed (Figma uses 11px for much of the UI). For many expert tools, 11px fonts are fairly standard due to the amount of UI you have to have on screen - other examples here where this is common are tools such as Blender or CAD software. Hackernews uses black 12px font for the main body text against a #f6f6ef background, which according to APCA requires a minimum 15px font at normal font weight. This is a perfect example of my earlier point that you have to use a collection of tools at the end of the day to get to a correct solution, rather than using a single tool or algorithm as a dogmatic source of truth. You can create poorly accessible solutions with WCAG and bad user experiences with APCA.
> All of our body text is WCAG 2 compliant - we wanted to ensure the primary usability of the app is accessible towards the current standard. Where we diverge is when combining saturated colors with desaturated colors for foregrounds/backgrounds, which WCAG has some trouble with.
Why not use APCA only though? Isn't it hard to keep track of where you're following WCAG 2 for some colors and APAC for others?
> Even with #000 and #fff as your colors, fonts under 11.5px are not allowed (Figma uses 11px for much of the UI). For many expert tools, 11px fonts are fairly standard due to the amount of UI you have to have on screen - other examples here where this is common are tools such as Blender or CAD software.
I've encountered this pain too. It feels like the only solution is the user configures their browser/OS to say what they find acceptable so the UI can adapt to that, rather than the default UI for everyone having to conform to the most restrictive rules.
> Hackernews uses black 12px font for the main body text against a #f6f6ef background, which according to APCA requires a minimum 15px font at normal font weight.
Do you have any tricks for conforming to APCA when you need to keep track of font weight, font size, and background vs foreground color while designing/developing UIs? There's style guides for reference, auditing tools, and potential for automation (e.g. CSS variables that pick a contrasting color for you), but curious if you had some thoughts given it can be a lot to manage.
> This was relevant for our Figma's brand color, as prior to our accessibility pass it wasn't compliant when combined with white text for neither WCAG 2 nor APCA. We modified it slightly to be #0D99FF, which was close enough to the original brand color it didn't feel like a rebrand, while still allowing us a passing APCA color contrasts score.
I'm curious how WCAG managed to miss this one during standardisation given how common blue is for a brand color. I wonder how many brands this has impacted.
I don't, as for us we set our goal to have a contrast of >60 regardless of font size/weight. Since we already weren't compliant with our 11px font sizes, we chose to use the contrast guidelines without the font size guidelines. Agree it's a lot to manage - we didn't find a great way to solve for this, which is why we mixed and matched WCAG, APCA, and general UX principles rather than relying on a single set of rules.
First of all thank you for these comments, I do proactively seek out comments like these as there are too few at the official APCA discussion forum https://github.com/Myndex/SAPC-APCA/discussions That said:
A px is not a device pixel, it is referenced to the canvas abstraction layer as the canonical CSS reference px. It represents 1.278 arc minutes of visual angle as subtended onto the retina. Or 0.0213° 𝑽𝜽
This is the case with a 96ppi monitor at 28" away.
Visual Angle in arc minutes is what is used in research, and in fact what the Snellen eye chart is based around, 20/20 is based on a capital E that is 5 arc minutes high, where each line is 1 arcmin, and each space between the three horizontal lines is 1 arcmin, where we then find a spatial frequency of 30 cycles per degree.
But that is for minimum acuity .
Minimum acuity is NOT best readability, which needs to be ~2.5 or times larger than the acuity size (critical size). For a standard display a reference distance away, that means an x-height of 9.4px, which is 12 minutes of arc 𝑽𝜽.
Critical size and critical contrast are recited and empirically tested for decades by eminent readability researchers Whittacker, Lovi-Kitchin, Ian Bailey, Legge, et alia.
The font sizes for APCA are based on this, and assuming a reference font like Helvetica with a 0.52 x-height ratio.
ALSO, if you want a "catch all" contrast value,Lc 75 is more appropriate IMO.
NOT SET IN STONE YET
This kind of discussion is good at the forum, so that it can be tracked and considered in the conversations about guidelines.
ALSO
If you want an easy way to use APCA and be fully backwards compatible with the old WCAG 2.x, then try BridgePCA at https://bridgepca.com
That's my general strategy too e.g. I'd rather pick a single blue that always works for large and small text, rather than having to keep track of and workaround which shade to use for different sizes.
I do wonder if they'll make some compromises to APCA in this area to make it easier to apply before it's standardised, as there's much more to track now compared to WCAG.
The reason for the public beta is to find concerns like these.
One of the aspects of APCA that is unique are the many use-case levels that improve design flexibility by focusing contrast values where they are actually needed.
The draft use cases for text are: https://readtech.org/ARC/tests/visual-readability-contrast/?...
It makes design more intuitive, they only need to know that a 40 difference in 'T' ensures that WCAG standards for buttons are met, and a difference of 50 meets the standards for text.
On the same topic, any thoughts on https://www.myndex.com/APCA/ and approaches if this becomes a standard? The color contrast value between a pair of colors depends on which color is the foreground and which is the background, so just comparing the difference in "T" won't be enough now?
I love APCA, Myndex (Andrew Somers, APCA author) was an absolute inspiration to me for getting interested in color, I wouldn't have known 1% of what I do or have done 1% of it without his deep dives showing how to work in this space.
It has an interesting effect on the community in that the general language around it is read too strongly: it is an important and crucial advance, getting science-backed data on exactly the right contrast in multiple scenarios is _absurdly important_ in a world of Ambient Computing™.
The mistake that's made is reading into this too heavily as _the previous spec or WCAG aren't based on data at all_.
Yes, the calculation is based on absurd stuff -- 100 nit monitor, you can't track down a source for every bit of it.
But there's a _whole separate field_ that spatial frequency comes from and it is _very_ well known and understood.
Most importantly: the APCA predictions for contrast were only about 5-7 L* different last time I checked. This is important, thats a _lot_ --- but it also isn't a lot, that's on a scale of 100. What we have today isn't completely utterly alienly different and broken.
Comparing the difference in T will be enough as long as the luminance measure APCA relies on is monotonic to RGB (HSL's lightness is hilarious, its the max of RGB minus min of RGB)
Let's say that I knew that I needed 6 colors in an application: a red, a yellow, a blue, an orange, a green, and a purple — that is, the 3 primary colors and the 3 secondary colors. Finally, say I didn't care much about which colors I arrived at, but that I would like to try to equalize for brightness (maybe saturation, too?) while being somewhat identifiable as those 6 colors.
I'm sure there's no exact answer, since Yellow is very bright and blue is very dark, so I'd probably have to arrive something approximate.
How would I do that? Are there tools or tutorials for learning such a thing?
This isn't quite as helpful as it might sound, i.e. it can't settle all debates, then design needs to become playing within the system: ex. lets say you land at you want mostly pastels. You could settle on lightness 90 -- get nice yellows, teals, but...no red!?!? It turns out light red is pink. And then on top of it, the yellows and teals colorfulness can get crazy high: lets say 80. But red can only get to 16, this breathy pink.
This can be extremely aggravating, ex. yellow. It just doesn't contrast with white, there's absolutely no way to get any a11y number to tell you that a nice bright yellow can be a button in light mode. But the system is empowering in that you know you can't do any better on the implementation, and you can trust the #s.
Also, I'm getting the impression that I'd have to be working in the Android ecosystem, maybe?
Looking at the code, it seems the computations are much more involved than OkLab, especially in the HCT -> RGB direction?
#1 it takes the most modern widely accepted space in color science, CAM16 for hue and colorfulness. CAM16 is relatively incredibly complex, about 500 lines of code. #2 it maps it to L*.
#1 is because nobody gets fired for basing Google's color system on CAM16. #2 is for WCAG.
There was continually interesting conversations on what exactly the name of the space was and whether it represented a new color space that precluded more formalization of it, the code ended up being the spec as it were. I did get a blog post out: https://material.io/blog/science-of-color-design
https://test.csswg.org/harness/results/css-color-4_dev/group...
https://caniuse.com/css-color-function tracks support for the colorspaces, complementing the above link for Lch/Lab, and showing essentially the same current data: All desktop and the two top mobile browsers now support it.
I'm really glad to see this. Thank you for sharing. That makes me much more optimistic about what will come of this.
(Note that all browsers are currently failing LCH and OKLCH tests 9 and 10, and Firefox failing 15% of the CSS Color v4 parsing tests, at https://wpt.fyi/results/css/css-color?label=experimental&lab... — but this is still a page full of great success for CSS Color v4! So happy.)
- it's _not bad_ Its better than HSL in that its lightness is correlated to "true lightness", and it's __much__ simpler to implement than a more complex thing like HCT's CAM16 x L. That's about 500 LOC, versus 15 I'd guess. And substantially faster too, few mat muls in each direction.
- Oklab L is not L: The problem for engineers and designers: no relation to LAB L*/XYZ Y, so no correlation to WCAG.
The problem on the designers end: it's not a linear ramp in dark to light visually. This usually goes unnoticed in a cross-disciplinary scenario unless you're really going deep into color, designers are used to working under eng. constraints.
- Color space accuracy / blue and yellow gradient:
It's a warning sign, not a positive sign, if a color space _isn't_ gray in the middle of a blue to yellow gradient. They're opposites on the color wheel and should cancel out to nothing. Better to instead note the requirement that you don't want gray gradients, and to travel "around" the colorspace instead of "through" it, i.e. rotate hue to make the gradient, travelling along the surface of the colorspace, rather than going into the color space, reducing colorfulness.
That should not be considered a bug by itself. CAM16-UCS lightness J also does not depend only on XYZ Y.
> no correlation to WCAG
Y does not necessarily have to be the standard used by WCAG (see CAM argument). And a stick that's a little skewed is still very well correlated with an upright stick, statistically speaking.
> The problem on the designers end: it's not a linear ramp in dark to light visually.
Now that is the actual issue which has nothing to do with which variables L depends on. The L_r (lightness with reference) derived from L is designed to deal with that: https://bottosson.github.io/posts/colorpicker/
I avoided the word bug, I believe. Let's say someone else claims it is. I would advise it is not a bug, but the absence of a feature. And that I'd struggle to come up with a good reason to switch away from HSL without that feature. If you're just picking colors, HSL is fine. The process advantage and magic is built-in "oh I know this color passes a11y with this one without guessing" is ___huge___. At least at BigCo, you can't skip a11y.
> Y does not necessarily have to be the standard used by WCAG (see CAM argument).
Sure, but it is used by WCAG and that's important: see above. Also, there's a reason Y has survived since 1900, and it's not because it's an arbitrary decision.
> And a stick that's a little skewed is still very well correlated with an upright stick, statistically speaking.
I assume it's a reference to the shape of Oklab's L, but I'm not sure if you meant that, so apologies if this sounds aggressive because it's not what you meant / I'm repeating another comment: Oklab's L is not Lab's L, and it's not close, and when you plot Oklab's L versus any other color spaces its very oddly shaped. This isn't a problem for an engineer or color scientist, but it is a problem for a designer.
> Now that is the actual issue which has nothing to do with which variables L depends on.
I agree that if we say "well WCAG could use any lightness measure" and decide we'll switch away from HSL to an arbitrary color space because the science on spatial frequency might be rewritten or WCAG may divorce itself from it completely, that we can completely write off a11y as a non-goal.
1931. And Y is known to be problematic since Judd (1951) and Vos (1978), with the latest approach being the Stockman & Sharpe 2005 "fundamental" redefinition. This error has real bearing on how narrow-spectrum display works.[1]
[1]: https://sensing.konicaminolta.asia/wp-content/uploads/2018/0...
> I assume it's a reference to the shape of Oklab's L... not close
The "a little skewed" refers to the shape of the L (or CAM "J") axis projected into the 3D XYZ space, not how the values are scaled in 1D (which I have addressed separately as L_r). They will not perfectly match the Y axis and appear bent, even skewed, because they don't just mathematically depend on Y. But they will be quite close and score a good (> 0.90, I guess) correlation coefficient over a set of color samples because they are trying to model the same aspect of human vision. That is still good correlation, and given the limited nature of gamuts you'd still be able to derive some sort of "this much difference means at least this much ratio".
Good reading for the color theory behind perceptual contrast: https://www.smashingmagazine.com/2022/09/realities-myths-con...
And a distilled description of APCA: https://typefully.com/u/DanHollick/t/sle13GMW2Brp
https://twitter.com/MyndexResearch/status/169550147293769333...
I am sorry about the licensing issue, it is only temporary during the public beta. And I am providing some exceptions, if you need, send an email to legal@myndex.com
Just can't do an MIT type license right now—and really there's no generic one that really suit what we need right now, so we're working on such a license, one that is reasonably permissive yet prevents some of the issues we've run into. I.e. like with bad actors incorrectly modifying, or reverse engineering and doing so wrongly, or taking it to the cantina at Mos Eisley...
[1] https://wolthera.info/2014/07/hsi-and-hsy-for-kritas-advance...
https://www.smashingmagazine.com/2023/08/oklch-color-spaces-...
@media (color-gamut: p3){
.some-class {
color: oklch(70.9% 0.195 47.025);}}
We were at an art museum once and there was a painting that was just a bunch of rectangles of different colors. She thought it was the most beautiful thing ever. So I got her a small print of it and she was disappointed. I’m sure the print was a CMYK printing of an RGB picture, so it got down sampled back to three channels. It looked the same to me as the original.
God help us when we go pick out paint for a room in the house or try to color match a fabric. She has word visceral reactions to colors that just doesn’t make any sense to me.
Here's a real question for her on the subject, how does she see a blacklight? I expect a true tetrachromat to see it nearly white. But also I wonder if she's sensing a fluorescing that is of sufficiently short wavelength that standard vision can not perceive it.
The implants I have in each eye are different technologies. The right eye has no UV filter, the IOL in the left eye does have a UV filter. When I look at a blacklight with my right eye, it's bright, almost white in appearance.
But looking at the blacklight with my left eye, it looks like what most see, as a very dark purple with almost no visible light.
A friend of mine is an artist who has been experimenting with extreme metamerism, using pigments that radically change perceived color under different light sources, including of course, blacklight.
Since you mention hiking, I wonder if some of the plant life you and your wife encounter have any florescent properties, or perhaps interact with some fungus that does... A portable UV light at night might be interesting...
[1] https://www.quora.com/How-can-I-really-test-if-I-am-tetrachr...
My theory that I've pieced together: The Y chromosome codes for 1 piece of the information and the X codes for 2. I'm sure it's not linear, but the quantum mechanic in me says that the color receptors are a linear combination of the three basis functions encoded on the DNA. For women their system is over determined, and I bet the green is really a degenerate solution that _usually_ overlaps. But in some cases the green is extra wide or even two district peaks. It also can explain why men are more likely to be color blind, if one of the 1 drops out, they only have two channels remaining. Women tend to have a back up.
Mind you, I appreciate the suggestion to avoid Tool X (i.e., in this case HSL) but I can't help but believe they did themselves a disservice by choosing a six-color color system to begin with. In my eyes, mind and heart accessiblity and simplicity go hand in hand.
Fact: There's not a user in the world who wakes up and thinks "My day will be made if and only if I visit a site with an overly complicated color system."
At a minimum, most web UIs grow to need:
- Several greys (borders, headings, body text, boxes), a primary/accent color (to show what's clickable), green (to show success), red (for danger) and orange/yellow (for warning).
- If you then want to show success/danger/warning alerts/badges/icons/buttons, you'll usually want extra shades of each for the borders/background/headings/text.
- For buttons, you'll usually want shades of at least your primary color for the background of each normal/hover/clicked/disabled state too.
- At that stage, you may as well have shades/tones ready for the other colors in case you need them in the future so you don't have to keep coming back to it. You could get by for a while by generating new color variants from existing colors with shortcuts like using transparency or contrast filters, but the feel/branding of these probably won't be ideal compared to more designed palettes.
- From a light theme, you'll need to tweak the colors to get a dark theme, usually reducing saturation as the colors become too bright on a dark background.
You can get pretty far with a restricted palette though e.g. https://design-system.service.gov.uk/styles/colour/ and https://getbootstrap.com/docs/4.0/utilities/colors/. Or use an existing large palette like https://www.ibm.com/design/language/color/, https://www.radix-ui.com/colors or https://designsystem.digital.gov/design-tokens/color/system-... (these ones have nice rules about which colors contrast with others).
Put another way, how many users are going to understand ALL those shades and subtle signals in a don't-make-me-think (i.e., Steve Krug) sort of way?
And how accessible are all those (too often) lower contrast combos?
I appreciate the finer points of your answer but it still feels to me like designers are imposing their form-over-function will on the users, and shouldn't we be past that at this point?
That is, ultimately, was HSL The Problem? Or was is more guilt by being in the wrong place, used in the wrong way, at the wrong time?
So see Bootstrap's alerts for example (not known for being overly flashy):
https://getbootstrap.com/docs/5.0/components/alerts/
They've got primary, secondary, warning, danger and info and alerts. Each one has a unique background, border and text color, and the text contrast meets accessibility standards. So that's 15 colors just there.
Alerts like this are super common for any UI with forms. You could simplify each alert to use only one or two colors (which puts limits how you can make them look), but do you think this example is over designed as is?
> Put another way, how many users are going to understand ALL those shades and subtle signals in a don't-make-me-think (i.e., Steve Krug) sort of way?
You'd assume the user can tell the danger color from info, but the different shades of the danger color wouldn't have a different meaning except for emphasis and to help with the information hierarchy. Even if your UI was greyscale, you'd want different shades to help here too.
Can you point to a UI you like? How many colors and shades does it have?
Look. I'm not saying there's absolute right or wrong. But I do believe there's enough myths and false gods kicking around that someone needs to stand up and say, "Wait a minute..." I'm that guy today. I'm that person.
Yes, it's standard practice that you don't rely only on color for information. But for people that can see those color differences (about 90% of the population don't have color blindness) it's a very worthwhile improvement so isn't it overkill to ignore these people? And what's the problem with tweaking the shades so they match the brand a little better?
What are you advocating as an alternative? How many colors and shades?
https://developer.mozilla.org/en-US/docs/Web/CSS/color_value...
As a user of their "doing it right" - and feeling under-satisfied too often - maybe they should be listening more, and imposing their will on the rest of us less? Or do I roll over and play brain dead because I'm told to do so?
I happen to believe less is more. And I've seen that work well / better often enough. If mo' mo' mo' is so great, why am I not seeing it and feeling it?
I am looking at a picture of an anime character (Kizuna Ai) on my wall and it has two shades of five colors plus one shade of blue used in the background for a total of 11 shades.
This is exactly the point of accessibility colors. Making things easier to see. There's a whole discussion on measurement of it in the article. It's just not a solved problem yet.
https://en.wikipedia.org/wiki/Metamerism_(color)
particularly metameric failure. For instance there are those RGB lights like Phillips Hue and Lifx which would render colors in the environment better if the colors were wideband but would work better at rendering strong saturated colors (like a display) if the R, G and B were laser-like monochromats.
There was this system for stereo films
https://en.wikipedia.org/wiki/Dolby_3D
that exploited metamerism by using 6 monochromats and very glasses with narrowband filters that route 3 of them to each eye. These were very high performance but were crazy expensive (needed theft protection) and got trashed in the marketplace by Lifton's RealD system based on circular polarization even though RealD doesn't perform quite as well.
https://variety.com/2012/film/news/transformers-ride-pushes-...
https://professional.dolby.com/product/dolby-cinema-imaging-...
but there might still be some theme park rides still using it.
I have looked at the glasses for rides like Transformers in my link, and Avatar and Harry Potter Gringotts and none of the lenses were polarized to my quick tests.
High-resolution spectra (like needed for many scientific applications) can be recorded only for images with few pixels or for images with many pixels but with long delays between successive images (because they are obtained by mechanical scanning of the pixels), so you must accept a trade-off between spectral resolution and either spatial resolution or temporal resolution.
That's not what color in this context actually is though.