Okaidia: Update comment text color to meet WCAG contrast recommendations to AA level

[Ayesh]

Hi everyone,
Text color for comments used in the Okaidia theme is slightly falling behind the minimum text contrast level required by WCAG guidelines.

This PR changes the text color slightly to meet the 4.5 requirement.

Please see the comparison below:

Color	WCAG score	hex	rgb	hsl	lch
Current	3.67	708090	112, 128, 144	210, 13%, 50%	52.697% 11.234 253.001
New	4.54	81909e	129, 144, 158	209, 13%, 56%	58.928% 9.916 250.732
Latest	4.66	8292a2	130, 146, 162	210, 15%, 57%	59.697% 11.234 253.001

Fingers crossed this can be merged and release, but I'd be happy to make any further changes if necessary.

Thank you, and stay safe 🙏🏽.

Edit: The first version of this PR suggested to use color #81909e, but it turns out to be a not good measurement to make lightness improvements. That commit was force-pushed to use the new color #8292a2, which only makes lightness increments until it meets to the WCAG recommendation, and then converted to the nearest hex color.

[RunDevelopment]

We usually don't accept stylistic changes to Prism's default themes.

That being said, I think that enforcing good color contrasts is a good thing but I think that if we do it, we should do it for all themes (Just from looking, I guess that other themes could benefit from higher contrasts as well).
However, just changing some colors of a theme can significantly change the "feel" of that theme. (Okaidia's comments are a good example. With AA contrast, comments are a lot less visually distinct from the rest of the code.)

@mAAdhaTTah @Golmote @LeaVerou

[Ayesh]

Thanks for your quick response Michael. I understand your point of view with unexpected surprises for existing users.

To provide more context, the contrast between .token.variable and current slategray is 3.80. With the new color #81909e, it brings the contrast down to 3.07, which is not good, as it certainly makes it look less distinct to the bright white color Okaidia theme has for regular code. The new #81909e is the closest color I could calculate to pass the WCAG 4.5 score though.

So I think it comes down to how much breaking changes are we willing to make, and if the reduction of code:comment contrast by 0.73 is an acceptable compromise to make theme as a whole colors WCAG compliant. As the author of the PR, I'd obviously like to see it merged, but even if it is not, I totally understand your point of view. It is not that big work to patch my copy of Prism CSS during the build process, and even if this PR is closed without merging, I still appreciate your thoughts and time on this.

[mAAdhaTTah]

I'll say I'm mildly in favor of this change, as I do think we should adhere to WCAG for our themes, but the question of "breaking change" is interesting, so I'd be interested to hear from @LeaVerou or @Golmote on this.

[LeaVerou]

In general, I'd be in favor of passing WCAG for contrast, especially since the change doesn't seem huge.
I would love a screenshot that shows this change in a larger code snippet. If the change in context is bigger than it appears, we may need to explore alternative strategies (e.g. increasing contrast on hover/focus). But we'll cross that bridge when we get to it, I suspect it would be ok.

However, the proposed color has a different hue. Please use https://css.land/lch or any other Lab or LCH picker to produce a suitable rgb() color with the same hue and chroma, just higher lightness. Please note that HSL is not a suitable model for this adjustment.

[Ayesh]

Thank you so much for your feedback @LeaVerou . I did not know about LCH colors, and it indeed makes sense. I learned this today and will be super helpful to personal projects too.

The current color is slategray, which comes to an LCH value lch(52.697% 11.234 253.001). I have force-pushed a commit that uses color lch(59.697% 11.234 253.001), which roughly translates to #8292a2.

I updated the issue summary with new color and attached a screenshot too. Same screenshot below:

[RunDevelopment]

Should I make a test that checks the contrast of (almost) all token colors? (Maybe even with automated contrast correction based on LCH?)

I mean, there are a few colors in other themes that have even lower contrasts than comments in Okaidia (e.g. regex in Default has a contrast of only 2.28). We should probably "fix" that as well (but not as part of this PR).

[Ayesh]

Aw yes, tests throughout the appearance would be lovely! I think Google Chrome lighthouse CI can run tests on an example rendered page that we try to all possible tokens can help? I don't have expertise with it but I'm available to collaborate if necessary. Thank you.

[RunDevelopment]

I was thinking of parsing the theme file, extraction all colors, and computing the contrast against a fixed background color. It's a simple approach and it allows us to exclude some tokens (e.g. it's fine if the contrast of punctuation was a little lower).
Lighthouse CI seems like overkill to me.

[mAAdhaTTah]

I'm still mildly in favor of this but would also be ok with slotting this into a potential 2.0 along with #2313.

[RunDevelopment]

I think it's ok to merge this. The change is relatively small and, IMO, can be seen as a fix.