PR'ing that widen function I mentioned a while ago. :)

[erlandsona]

No description provided.

[tesk9]

Heya, thanks for the PR!

The changes to checkContrast will make this a major version change, and generally I avoid those. I also generally avoid type aliases in function type annotations in packages because I think the compiler error messages are nicer without the alias.

I would love to see some tests against widen before merging as well.

[erlandsona]

Fair point... that said, I ended up going even deeper down the rabbit hole which fundamentally shifted my approach to this whole "widen"ing thing.
But it makes the widen function more predictable.
That is, I realized that working in sRGB / HSL makes reasoning about accessible contrast a bit of a nightmare and that LCH just "fixes" it.
So I pulled the JS from https://css.land/lch/ and translated most of the JS to elm given most of it was pure functions anyways.

Basing my theme-ing primitives on LCH means I can adjust the Lightness of any hue according to this 10-step system.

Which means widen is just +/- 40 Lightness (for AA) and 50 (for AAA) for any hue of any color.

Ultimately I thought I could use elm-color-extra's Accessible module to do the lch conversion but it didn't have functions for converting True LCH back into the sRGB space which is why I had to adapt the css.land/lch functions.

ALL THAT said, not sure whether to make a new elm package just for LCH or add it to elm-color-extra or adapt the functions to work with this repo...

I'd love more eyes on the work and maybe some guidance / rubber 🦆'ing, I'm pretty much always available on Slack at @erlandsona if you're interested or want to talk more?

Feel free to do whatever with this.