Huetone | Hacker News Reader

Huetone

huetone.ardov.me

69 pointsjohn-doe13 comments

I have very little understanding of what all this means

Same at first, there's a link here which goes into it https://stripe.com/blog/accessible-color-systems.

Nice. This looks similar to the internal tool mentioned in the classic Stripe blog post on designing a color palette (search for "how limited the space is"):

https://stripe.com/blog/accessible-color-systems

edit: I just realized this site links to that Stripe article in the credits section.

>Accessible Perceptual Contrast Algorithm (APCA) by Andrew Somers is a WCAG 3 working draft and may change later.

It's too soon to use APCA. Use the current WCAG color contrast algorithm and standards.

I strongly disagree. APCA isn’t finalised, but it’s vastly better than the existing WCAG contrast stuff. I’d much, much rather have it included than not. Pointing out in the clearly-visible credits that it’s a work in progress is entirely sufficient.

The WCAG contrast formula is really not great, and gives very misleading results in plenty of situations.

I've wondered where they came up with their formula, because it's not obvious and the results are so clearly wrong in many simple cases. The best I can figure is that they just re-worked some some formula from back in the green-screen CRT days and it's just laughably inappropriate now.

It's tough to find any solid info on the actual history of the development of the WCAG contrast criterion, but it looks like they chose to base their concepts on the work done in the mid to late 1990s on the sRGB color space, which itself seems to have been motivated by the desire to maintain the simplicity of defining colors by R, G, and B. The WCAG's "relative luminance" is calculated from the raw RGB values using very simple arithmetic, which tends to not be the case for perceptual color spaces.

There's definitely an element of sRGB in there, but it feels grafted on to something older. Like someone was tasked with throwing something together from whatever references they could find. P.S. sRGB was motivated by a desire to quantify the behavior of an "average" CRT monitor, and while it probably didn't accomplish that at least it gave everybody a target so that hardware could converge on something sensible.

The WCAG contrast algorithm is laughably bad. It's not bad enough to justify saying screw it, I won't care about the accessibility of my color choices at all, but it is bad enough to say even though I'm not an expert in accessibility or color theory, I can still do better than the WCAG contrast algorithm.

I really like this approach, but there are things I don't understand: * Dragging a color dot outside the color space area continues to update it, making me think the color space isn't properly defined. Shouldn't the color clamp once you go into the grey zone? * I don't understand how the grid on the left works. What do the numbers across the top mean? How can I adjust a column? Overall seems very promising!

It looks like the shaded area marks colors that are representable in the color space of that chart (CIELCh or OKLch) but not representable in sRGB (which is the color space used by the rgb and hsl functions in CSS). I think it makes sense to allow experimenting with dragging colors into the shaded area, because you still get to see how that effects the shaded area in the charts for the other axes. I would also love this tool to support color spaces from the CSS Color Module Level 4, like display-p3, but I don't think the underlying chroma.js library supports those yet.

This is fantastic! One question I have is how I compare two specific colors. I can compare teal-900 to green for example, but I would like to compare specifically green-400: is that possible?

Reply on news.ycombinator.com