The issue has been closed
The contrast function does not take opacity into account, but I think it should regardless of discussion around the same topic in #136.
While the arguments for that issue keep hold, the result is as such:
rgba(0,0,0,000001) on rgba(255,255,255,1) has a contrast ratio of 21.
In actuality the contrast of those two rounds down to 1 because of the low alpha.
In other functions taking alpha into account might not make sense, but when you know the background the alpha blends with, that clearly affects the contrast ratio.
This has to do entirely with what the color is mixed against behind it. All an alpha channel is for is to define mixing ratios when compositing an image. So no, the contrast functionality shouldn't take alpha into account because one cannot assume the color underneath (there's no way to represent this I'm the API right now)
As I mentioned in my other comment, you should .mix first based on alpha.
Specifically for the wcag .contrast function you do know the background color since it's provided as an argument to that function: https://github.com/Qix-/color#luminosity There's no assuming the color, it's given.
One level down, of course if the background also has alpha, you cannot assume the color under that.
Still it seems reasonable to have the contrast function do a .mix on the foreground color when it contains an alpha component.
Contrast is not foreground/background, it's a comparison between two colors (regardless of how they're being used). You might be interested in the contrast between a background and foreground, but this library has to cater to all use-cases.
This isn't really something that can be changed - you have a specific use for the library so ultimately you'll have to write more code.
Good question though :)
IssueHunt