[Experimental] Contrast Calculation

[Mischback]

WCAG2.0 calculates the contrast ratio between two colors depending on their relative luminance.

The relative luminance is calculated like this:

  luminance: function(red, green, blue) {
    var a = [red, green, blue].map(function(v) {
      v /= 255;
      return v <= 0.04045
        ? v / 12.92
        : Math.pow((v+0.055) / 1.055, 2,4);
    });
    return a[0] * 0.2126 + a[1] * 0.7152 + a[2] * 0.0722;
  },

However, this article states, that the Y of XYZ corresponds to the relative luminance already.

Experiment

Define two colors (a, b) in sRGB colorspace. Calculate their contrast ratio in sRGB using the functions of WCAG2.0 and then use their corresponding XYZ representations to calculate the contrast ratio depending on Y alone.

Result

As of https://github.com/Mischback/colorizer/commit/28b7d7b70542a6245b87a74626d3c9c0e29b2302

• When RGB-based inputs are used to set the color (RGB, HSL, HWB), the values of both methods correspond within an acceptable error margin (talking 1/1000 here).
• When the okLCH-based input is used, the methods vary significantly. Probably this is not an issue of the actual calculating, but the clipping when converting the XYZ color (as it is stored internally) to RGB (ColorizerColor.toRgb()). This is already tracked as an issue (https://github.com/Mischback/colorizer/issues/25), which might need higher prio.

So What?

• Actually not yet sure. It feels better and more modern to use the XYZ Y component directly. This will work out ok, as soon as https://github.com/Mischback/colorizer/issues/25 is fixed, but will still not be perfect in line with WCAG2.0
• Possibly this is another subject for https://github.com/Mischback/colorizer/issues/23, letting the app's user make the decision, depending on his use case (if he's using RGB notation in his use case, he might want the more correct RGB-based calculation, but when he is already using XYZ or another (bigger) colorspace, he might want the XYZ Y solution).