Hey,

First of all I really enjoy your tool! Especially as a color blind person, it has helped me to pick colors that other people can see as well.

However sometimes majority disagrees with the results. For example:
White on #28A3CE gives a ratio of 2.9.

rgba(0,0,0,87) on #28A3CE gives a ratio of 6.38.

Everyone that I've asked has agreed that white is more visible than the black, and it's weird that it says white is over twice better. I know WCAG is a common guideline. Do the guideline define the algorithm, or is it something that can be tweaked and/or improved? Are our monitors just configured weirdly?

I'd love to hear your thoughts on this, and thanks again for the great tool!

PS. I tested on a few other monitors and the contrast is definitely different. The blue appears lighter on mobile screen making the black slightly less contrasted and the white more contrasted.

Hello,
I browse the web without JS first, and then, add JS if needed.

Today I wanted to use contrast-ratio.
I knew I had to enable the JS in this page. And I did.

But before I did, I stumble upon that page :

Can we make a default behavior when JS is not (yet) enabled ?

The incrementable script src currently redirects to a non secure address, which causes the script to be blocked when mixed content is not allowed in the browser.

Display contrast values seems to have incorrect rounding.

To recreate:
Precise contrast between white and hsl(294, 85%, 39%): 6.169999638792364
Display value: 6.16

Seems strange to me, is there any particular reason you use floor instead of round?

The website isn't very friendly to use on mobile.

If I can find time later for it, I'll see if this is something I can handle and revamp the site for mobile without impacting the desktop usage.

Hey! Congratulation for that neat and very useful tool. Love it! ❤️

Unfortunately, the current link in this project's About section (https://leaverou.github.com/contrast-ratio) ends up with a 404 Not Found.

I think it should be updated to https://contrast-ratio.com/?

Holding on UP-ARROW/DOWN-ARROW doesn't update the hexadecimal properly, but appends (negative/invalid) numbers.

Hey @LeaVerou I would really apprechiate this color ratio as a gulp Plugin, so it can be integrated into a typical workflow.

I guess many others would as well, since it addresses an important issue.

Any chance of you turning it into a gulp plugin?

Cheers,
Lukas

I think that the code would be improved if you were able to change the value of the opacity for colors in increments of 0.01 instead of changing it by values of 1, like for the other values. This is because opacity only has a range of 0 to 1, and would mean that decreasing opacity with the down button would only work if opacity was set to 1, and vice versa.

Thanks to Github recent changes, supporting HTTPS on contrast-ratio.com should be as easy as flipping a checkbox in the github settings to enable the Let'sEncrypt certificate for the custom domain.

I love this site, both because it's so attractive and easy to use, and because it allows me to test colors with alpha values. Thank you!

One thing I noticed while playing around with it, though, was that there's no indicator when a user enters an invalid color code. If the input is invalid, the last valid entry silently remains. If a user enters an invalid color, the new pairs seems to be just as the last valid pair.

For example, the page begins with:

white / hsla(200,0%,0%,.7)

If a user modifies the foreground number and misses a percent sign or pastes a malformed color code, output and #results remain unchanged, and the user may believe that their malformed color code is both valid and accessible, based on the unchanged success message.

For example, each of the following invalid foreground colors will appear to be successful:

white / hsla(200,0,0%,.7) (missing percent sign on saturation)
white / hsla(0%,0%,100%,0) (erroneous percent sign on hue)
white / bloop! (invalid color name)

Swapping the colors then fails because the invalid color code can't update the background color, so that both colors are now identical, i.e., reversing "white / bloop!" says "bloop! / white" but the actual colors being compared are "white / white."

I wasn't quite able to see how colors were being parsed, but it'd be great to work out validation for color codes so that users, especially those less familiar with how the different types are formed, can see where they've made mistakes in using the tool (e.g., it's easy for beginners to a percent sign, or confuse RGB and HSL).

Thanks.

(P.S.: I'd like to help out if I can, but I'm feeling a bit dense in trying to see how the inputs are parsed.)

Hi!

I love your algorithm :P Could you tell me what's the formula? I want to use this in my application, but on server side (php). I tried a lot of algorithms, but any doesn't work so well as yours.

I want to know what font color I have to use (black or white) if I know the background color.

I hope not to bother you with my question.

BTW: I tried to read your code, But I get lost in so many lines of code hehe

Regards!!

I had an issue using this tool where the colour combination was compliant here (4.5:1) but was actually 4.47:1 according to Snook's tool, so non-compliant.

Would it be worth changing the mathematical logic to either ignore rounding or round down so that combination would have been 4.4:1?

Alternatively going for a more accurate ratio?

I'm working to create a library of color scales with consistent contrast ratios. With 20+ values each and 16 colors that's a LOT of copy/paste. I would love a way to bulk import them and get back a new column showing the contrast ratios. In my ideal world it would be a Google Sheets script.

Hello and thank you for sharing his project.

I have a little question.

In your script color.js

rgb = rgb < .03928 ? rgb / 12.92 : Math.pow((rgb + .055) / 1.055, 2.4);

Meaning:
if RsRGB < 0.03928 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4

On the w3c page:

if RsRGB <= 0.03928 then R = RsRGB/12.92 else R = ((RsRGB+0.055)/1.055) ^ 2.4

It should be:

rgb = rgb <= .03928 ? rgb / 12.92 : Math.pow((rgb + .055) / 1.055, 2.4);

Or do you change it for any good reason ?

https://www.w3.org/TR/WCAG/#contrast-minimum

I noticed that when the background color is set to white, then the white text describing the site is not able to be seen without highlighting it with the mouse. It would be good if you were able to change that to a color that had sufficient contrast when the background color of the area the text is in changes.

This is a very visually appealing color contrast checker. Often though I end up going to http://webaim.org/resources/contrastchecker/

I do this because it has a simple lighter/darker link on the side which makes it pretty trivial to pick a variation that is just slightly darker than the original. I'm not sure how Webaim does this, but in talking to @mparker17 he suggested that this is something that could be done in a fairly straight forward way using the HSL color space.

It would be great to know given a random foreground color, what is the lightest background color necessary to meet WCAG 2.0 AA & also for AAA.

Hey Lea, this is superuseful. Can the code be adapted into projects? I can't find any license info. I want to plug it in a color scheme/ color picker tool.

Hi,

I'd like to use your code. I was wondering if you have a license you'd be willing to add? Would the MIT license work?

Thanks

AFAICT, this tool is hosted on Github Pages. Since a few months, HTTPS is available for free for custom domains, and it is only a matter of enabling the feature in the settings of the repo.

Thanks for this great tool!

A suggestion: Would you rewrite the text on the button “Set as background color”? What this button does is more “Flip colors” or “Swap background/text colors”.

It would be cooler if you put color picker directly in the project, so that people do not have to go and pick color from else where

For example
hsla(0, 100%, 100%, 1); breaks lightness interpretation,

...but removing the semi-colons fixes it.

If you enter linear-gradient(lime, green) as the value for the background, it’ll render it, but its calculations are off, because it’s interpreting it as a semi-transparent background.

It should instead calculate the range of contrast ratios, probably by sampling a bunch of colours on the gradient and considering them individually.

(Pathological example: grey on linear-gradient(white, black) has contrast ratios in the range 1–5.31, but if you only sampled the two ends of the gradient you’d get the answer 3.94–5.31.)

Hi,

it would be very very handy, when writing hex colors, if the max length allowed was 7.

XXXXXX = 7 = max allowed string ;)