Non-sRGB color spaces, outdated sRGB threshold, and other issues in the "relative luminance" definition

[peteroupc]

Also found at this issue. Posting here in case I get a reply sooner.

The value 0.03928 (as used in what was formerly a note to the "relative luminance" definition but what is now a "normative" part of that definition) comes from the sRGB proposal. This is outdated and either 0.04045 or 12.92 * 0.0031308 = 0.040449936 (I don't know which is used in the IEC standard) should appear in its place.

I understand, however, that all three thresholds don't make a difference in the results if only 8-bit linear sRGB values are involved. On the other hand, if no change to the 0.03928 threshold is planned soon, a note on the origin of that threshold should be added to the document (in particular, why that threshold was chosen rather than the one given or implied in the IEC standard).

EDIT (Mar. 27): Clarification.
EDIT (Apr. 9): Struck out part of the text. Since so few source code files on GitHub use 0.040449936 compared to 0.04045, I reasonably believe that the IEC standard uses 0.04045 as the relevant threshold, assuming it even mentions an inverse transfer function.

[awkawk]

Thank you for commenting. For more information about how the AG WG will process this issue, see the following:

• Issue Processing - How the WG will discuss the issue
• Issue Resolution - Identifying and responding to the official WG response
• Issue Notification - How to limit notifications from GitHub

[awkawk]

Thanks for the comment - we can look at an update to the understanding document after WCAG 2.1 is published, but we are not making changes to the normative text or definitions from WCAG 2.0 in this update. I am closing the other issue you link to as we will track it here.

[peteroupc]

Thanks for the update. A related issue concerning the "relative luminance" definition that the Understanding WCAG document should clarify is whether "relative luminance" should be considered equivalent to the Y component of CIE XYZ (especially for non-sRGB color spaces such as DCI-P3) (more specifically, equivalent to the "luminance factor" as defined by the CIE) and whether the notes in that definition specifically apply only to companded ("non-linear") "sRGB" colors encoded as 8-bit-per-component colors and not to sRGB or sRGB-like colors encoded or represented in some other way (whether by using different red, green, blue, or white points, a different color component transfer function, a different encoding form, or otherwise).

EDIT (Apr. 8): Clarification.

[alastc]

I'm going to take this to people who know more about color spaces than I do, but regarding urgency it would help to know in what scenario CIE XYZ or DCI-P3 would be applicable for web content?

I.e. if "relative luminance" were considered equivalent to the Y component of CIE XYZ as you described, what difference would that make? What would someone creating web content do with this information?

[peteroupc]

My reference to CIE XYZ in my post is largely for the sake of clarity. What I mean to refer to is relative luminance being equivalent to the ratio of a color's luminance (Y component of CIE XYZ) to the white point's luminance; that is, the luminance factor — this is a much more precise statement than the definition of "relative luminance" in the current WCAG. Specifically, given a colorimetric color space such as sRGB or DCI-P3 (and other examples), the luminance of a color is objectively defined, whereas the current definition uses the word "brightness", which is a subjective attribute.

Some higher-end monitors support a wide gamut of colors, wider than sRGB; examples include DCI-P3 and Adobe RGB (1998). For such monitors, as well as images that use non-sRGB color spaces (via ICC profiles and similar mechanisms), and in other cases in which a non-sRGB color space is known to be involved, it can be useful to find the relative luminance of RGB colors in terms of such a non-sRGB color space. However, if I am not mistaken, color specifications in CSS (and presumably in HTML as well) are in terms of sRGB regardless of the monitor's color gamut or the computer's working color space; even so, this doesn't rule out images with profiles specifying a non-sRGB color space.

Most importantly, though, although the WCAG is primarily designed for Web content, those guidelines also appear in design recommendations for mobile apps (for example, in Google's material design specification), and the WCAG guidelines for the use of color can also find good use when designing computer programs with graphical user interfaces in general.

Finally, in any case, the threshold 0.03928 instead of 0.04045 indicates that the color space in note 1 of the current WCAG is "like sRGB", but not exactly sRGB. If an application wants to use the threshold of 0.04045 (which is the threshold that I presume is given in the IEC standard), then note 1 arguably doesn't apply anymore and the manner of calculating relative luminance for the "real" sRGB is undefined except as given in the definition for "relative luminance" in the current WCAG.

[alastc]

whereas the current definition uses the word "brightness"

Assuming you mean the normative definition of relative luminance, we can't change that in the 2.x versions.

Also, the description part of the definition can't repeat the word luminance from the term it is trying to describe, it has to use a more widely understood term (in general English).

this doesn't rule out images with profiles specifying a non-sRGB color space.

If I then use a color-picker tool that checks for colour contrast on such an image, would it give a different result between testing methods?

the color space in note 1 of the current WCAG is "like sRGB", but not exactly sRGB.

It looks like the main references are "A Standard Default Color Space for the Internet - sRGB", IEC-4WD and ISO 9241-3, although I assume older versions than you might be using. Again, not something we can change in WCAG 2.x.

If an application wants to use the threshold of 0.04045 ... then note 1 arguably doesn't apply anymore and the manner of calculating relative luminance for the "real" sRGB is undefined except as given in the definition for "relative luminance" in the current WCAG.

I don't follow, you seem to be saying note 1 doesn't apply except as the definition to apply?

If a company "wants to use" 0.04045 (which I assume is a slightly higher threshold?), then they will get different results. I think you trying to get at something here, but I'm not understanding it.

I'm not seeing anything to add that will clarify more than it confuses, for me the key question is whether a tool using the current formula would give different results (from other tools) due to a different color space of an image.

[peteroupc]

All the changes I am implying or referring to is to the Understanding WCAG series of documents (especially the document relating to color contrast), not to the WCAG specification itself. I was already told, and I accept, that "we are not making changes to the normative text or definitions from WCAG 2.0 in this update".

Luminance can be described relatively simply as the "light that is seen when a color is viewed".

Relative luminance, or luminance factors, can be described equally simply as the "light that is seen when a color is viewed, compared to 'white' light".

It looks like the main references are "A Standard Default Color Space for the Internet - sRGB", IEC-4WD and ISO 9241-3, although I assume older versions than you might be using.

The color space "like sRGB" refers to the color space given in the sRGB proposal. The "real sRGB" is the color space specified in IEC 61966-2-1, which is changed, among other things, in the respect that I refer to.

I don't follow, you seem to be saying note 1 doesn't apply except as the definition to apply?

I meant to say that "If an application wants to use the threshold of 0.04045 ... then note 1 arguably doesn't apply anymore to that application's calculation of relative luminance; as a result, the manner of calculating relative luminance for the 'real' sRGB is undefined except as given in the definition for 'relative luminance' in the current WCAG, which is relatively vague for the reasons given in the first paragraph."

[peteroupc]

If I then use a color-picker tool that checks for colour contrast on such an image, would it give a different result between testing methods?

It might depending on whether the tool honors the color profile given in that image, or whether it treats all images as sRGB regardless of the existence of a profile. This is because different RGB color spaces have different points for "pure red", "pure green", "pure blue", and "pure white", so that the same RGB point, say, (255, 0, 0), can have different relative luminances depending on the RGB color space.

[alastc]

All the changes I am implying or referring to is to the Understanding WCAG series of documents (especially the document relating to color contrast), not to the WCAG specification itself.

I can't find the references you are talking about except in the main spec. E.g. there is no mention of "brightness" in the understanding 1.4.3.

Relative luminance is in the glossary of the main spec, and the contrast ratio definition in the understanding doc is actually drawn from the main spec, it can't be changed either.

The only area we could change is the 'Notes on the formula', and even then only in ways that don't contradict the definitions.

The only note I can think of that would be suitable to add would be something like this, assuming it is true and this way around:
"If organisations wish to use the more recent value from sRGB of 0.04045 they can do so, it is a slightly higher contrast ratio."

[peteroupc]

The section "Notes on this formula" can explain how relative luminance is calculated in general for any (additive) RGB color space (not just sRGB), namely—

• converting each RGB component to linear RGB (which for many RGB color spaces is a simple gamma function), then
• calculating a weighted sum of the three RGB components, where each weight is the relative luminance of the color space's red, green, or blue point (e.g., 0.2126, 0.7152, and 0.0722, respectively, in note 1).

The section "Notes on this formula" can further explain—

• that the 0.03928 threshold comes from the sRGB proposal and not from the actual sRGB standard IEC 61966-2-1,
• probably, that an application is not precluded from implementing the sRGB formula in note 1 using the actual threshold from IEC 61966-2-1, which is 0.04045, with the understanding that different results are possible in rare cases,
• that if a different RGB color space than sRGB (or a different sRGB encoding than 8 bits per component) is known to be involved, an application ought to calculate relative luminance in terms of that color space (or encoding),
• that relative luminance is generally the light that is seen when a color is viewed, compared to 'white' light, and
• probably, that relative luminance (technically speaking) is equivalent to a color's Y luminance in the CIE XYZ system, divided by the Y luminance for "white".

Although Note 3 in the "relative luminance" definition says "If using other color spaces, see Understanding Success Criterion 1.4.3", actually Understanding WCAG is silent on color spaces other than sRGB.

[patrickhlauke]

Unless I'm misunderstanding some of the detail here, I think it's also important to mention that the calculation relates to whatever color space the actual user agent itself is using when displaying the content. Though this then starts to get a bit...difficult, as some browsers (bringing it back to more specific web content) nowadays also use a different color space (e.g. on Windows, if using a tool like CCA https://developer.paciellogroup.com/resources/contrastanalyser/, you end up getting very subtly different results when measuring particular hex color values as output between Firefox and Chrome, as Chrome now seems to apply color profiling/different color space). In short, we're likely getting into a tricky situation where accurate test results will depend entirely on the browser used (and this is thankfully not taking into account any color profile at OS/monitor level, which I believe is excluded from the language anyway)

[alastc]

I wonder if @GreggVan could comment on the source of the sRGB threshold, from the comment above?

@patrickhlauke do you have any examples we can test, or clues about which colours might demonstrate that effect?

[patrickhlauke]

the very broad reason for this: for the last few versions, Chrome has now started to color-manage its entire output. previously, it only did this with images. Firefox still doesn't color-manage this aspect.
(note: the difference here will depend on your specific monitor/color-management profile on your specific machine, making this even more volatile)

as with the text size measurement though, the answer to this is mostly: make sure that you use the values as defined in the CSS (if you can) for your contrast calculation. (and for CCA, we're currently exploring if it can be adapted to also apply the same color management as the browser, but this would then likely result in skewed results when trying to pick the color from non-color-managed browsers like Firefox)

[alastc]

Hmm, that does make it more relevent for non-text contrast. UI controls will (generally) be defined in CSS, but graphics made with bitmaps like PNG/JPG could provide different results.

Would it be fair to 'note' something like, this, after some context about colour spaces:
"In cases where the contrast is borderline, it is recommended to increase the contrast. Where there is dispute about the results due to colour space, the test should use the colour space of the source image."

[patrickhlauke]

wonder if it also needs to say something about the gamma, and more generally the colour profile, of the source image. and perhaps for CSS-defined colours maybe it needs to reinforce that auditors should refer back to the colour as reported in the browser's dev tools/defined in the CSS, rather than the potentially color-managed output.

[alastc]

Interesting, using CCA will fail #5892ef in Chome, but not FF / Edge when using a colour picker approach as it comes out at #6095EC from the picker.

If I create a flat color image of #5892ef and display it in FF & Chrome, CCA reports the original colour, Chrome appears to have changed it.

It seems like the testing should be done in a UA that doesn't adjust the colour space?

[patrickhlauke]

If I create a flat color image of #5892ef

also depends how you create it, as many graphics apps will embed a color profile.

[alastc]

In this case it was from Photoshop using the default "Convert to sRGB" option. So if that was sRGB it shouldn't produce different results unless the browser is doing something?

[GreggVan]

I think the solution to this - is in one of the comments above. Specifically:

Note 3 in the "relative luminance" definition says "If using other color spaces, see Understanding Success Criterion 1.4.3"

It also notes "Understanding WCAG is silent on color spaces other than sRGB"

So the solution is to add text to Understanding WCAG 2.0 (which can be done) to talk about other color spaces. The contrast levels and definition of luminosity remains the same. It would only be the formulas for "lightness" that change to match the colorspace you are in.

[peteroupc]

It would only be the formulas for "lightness" that change to match the colorspace you are in.

Careful; the CIE definition for lightness (L*) is not the same as "luminance" or "luminance factor", but note 1 in the "relative luminance" definition clearly calculates the luminance factor, not lightness (like CIELAB lightness), for an sRGB-like color space.

By the way, a future version of WCAG (say, WCAG 3.0) could consider redefining "relative luminance" for contrast ratio purposes (or contrast ratio itself) in terms of a self-luminous neutral scale (which is appropriate for colors viewed on self-luminous displays, including colors used in Web content; the link points to the abstract of a recently published CIE technical report which, however, isn't free of charge). I stress, though, that this suggestion can't reasonably be implemented for WCAG 2.1.

[GreggVan]

Hi Peter, I think there is a little confusion here between luminance and luminosity — and what a web author has control of. WCAG does not and cannot be based on luminance or relative luminance. Luminance can only be measures with things that give off light. Hence WCAG uses Luminosity — which is different. Also note that luminosity is not lightness — but relative lightness or more accurately the ratio of two lightnesses (or darknesses). (See the formula in WCAG) You cite the CIE definition — but please note that the standard you are citing is for DEVICES — not for content. To go with luminosity contrast you would need to know the visual characteristics of the display, its contrast ratio, the saturation, the reflectiveness of the glass (is it frosted) the technology used for the display LCD, OLED etc all are factors. A lot of research went into WCAG 2.0 — and luminosity is the only thing that a web author has control of. Hence WCAG is based on that rather than luminance or relative luminance which the author cannot know. Best Gregg

…

On Apr 29, 2018, at 10:00 PM, Peter Occil ***@***.***> wrote: It would only be the formulas for "lightness" that change to match the colorspace you are in. Careful; the CIE definition for lightness <http://eilv.cie.co.at/term/680> (L*) is not the same as "luminance" or "luminance factor <http://eilv.cie.co.at/term/717>", but note 1 in the "relative luminance" definition clearly calculates the luminance factor, not lightness (like CIELAB lightness), for an sRGB-like color space. By the way, a future version of WCAG (say, WCAG 3.0) could consider redefining "relative luminance" for contrast ratio purposes (or contrast ratio itself) in terms of a self-luminous neutral scale <http://www.cie.co.at/publications/grey-scale-calculation-self-luminous-devices> (which is appropriate for colors viewed on self-luminous displays, including colors used in Web content; the link points to a recently published CIE technical report which, however, isn't free of charge). I stress, though, that this suggestion can't reasonably be implemented for WCAG 2.1. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#815 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3gaVojIz5fd_rERA2kDs42-S_ax2ks5ttnBRgaJpZM4S5qES>.

[peteroupc]

Also note that luminosity is not lightness — but relative lightness or more accurately the ratio of two lightnesses (or darknesses). (See the formula in WCAG)

@GreggVan : Which formula? The formula in the definition of "contrast ratio" or the formula given in Note 1 of the "relative luminance" definition? Also, neither WCAG 2.0 nor the CIE define "luminosity". If you mean contrast ratio, you should say that rather than "luminosity".

You cite the CIE definition — but please note that the standard you are citing is for DEVICES — not for content.

@GreggVan : Which CIE definition? I cite the definitions for "lightness" and "luminance factor".

Also, I mention the document for a self-luminous neutral scale only in passing — and with the understanding that many issues would need to be resolved before that suggestion could be adopted in WCAG 3.0 or later.

[GreggVan]

On Apr 29, 2018, at 10:45 PM, Peter Occil ***@***.***> wrote: Also note that luminosity is not lightness — but relative lightness or more accurately the ratio of two lightnesses (or darknesses). (See the formula in WCAG)

Sorry — I forgot we changed our terminology. Luminosity is relative brightness. We decided to go with relative luminance even though it was not quite accurate — since the pages do not give off luminance. So light and dark levels on the page are not measures of luminance but rather lightness and darkness of color.

@GreggVan <https://github.com/GreggVan> : Which formula? The formula in the definition of "contrast ratio" or the formula given in Note 1 of the "relative luminance" definition? Also, neither WCAG 2.0 nor the CIE define "luminosity". If you mean contrast ratio, you should say that rather than "luminosity" You cite the CIE definition — but please note that the standard you are citing is for DEVICES — not for content. @GreggVan <https://github.com/GreggVan> : Which CIE definition?

I was referring to the link you provided to GREY-SCALE CALCULATION FOR SELF-LUMINOUS DEVICES CIE 228:2018

I cite the definitions for "lightness" and "luminance factor"

Right: Lightness is what we are using in WCAG - but I don’t see the formula for Lightness in your link. Is their formula for the same color space different than the one used in WCAG? You are correct that “luminance factor” is different and would be incorrect since it relates to reflective surfaces.

Also, I mention the document for a self-luminous neutral scale only in passing — and with the understanding that many issues would need to be resolved before that suggestion could be adopted in WCAG 3.0 or later.

Agree with this. But - on a broader topic — I don’t think there should be a WCAG 3.0. We need to stop separating content from apps from tools etc. They are all merging. I think we need to leap ahead and look at accessibility to the radically new Internet Interfaces (More than just Web) that we are going to see soon. but that is for another time

…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#815 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3l-qodFGoaDuylOI1sdIhGH6KhlLks5ttnrLgaJpZM4S5qES>.

[peteroupc]

Right: Lightness is what we are using in WCAG - but I don’t see the formula for Lightness in your link. Is their formula for the same color space different than the one used in WCAG? You are correct that “luminance factor” is different and would be incorrect since it relates to reflective surfaces.

Unfortunately, yes, it is different. CIE lightness (L*, as used in the CIELAB formula, for example), is different from luminance (Y, as used in the CIE XYZ system) or luminance factor (Y/Yn, where Yn is the white point luminance). And the formula used in Note 1 of the "relative luminance" definition calculates a luminance factor (Y/Yn, where Yn is the D65/2° luminance), rather than CIE lightness (L*).

[alastc]

So I think there are three issues here:

1. The number for the threshold.

From asking around (and getting some links back like this comparison) there doesn't seem to be a huge difference between the sRGB proposal and sRGB standard. I.e. the results wouldn't be very different, and I'm assuming the .039 proposal value leads to slightly less contrast needed?

Given that the Understanding docs are aimed at web authors who will need to use a tool to test anyway, I don't see value in adding information about this.

If we need to provide better information for testing tool creators that is a good point, but that isn't necessarily something to be done in the Understanding docs.

2. Relation to other colour spaces.

The point to mentioning other colours spaces would only be to acknowledge they exist, but as it stands any calculation would need to be converted to sRGB.

If I'm missing something, please tell me what a web-author would do with information about other colour spaces.

3. Testing with browsers that use other colour spaces

As it is possible to get different results with the same value (which impacts web authors) I think we should add a note (to 1.4.11, possibly 1.4.3) about using the source values from CSS or a browser which uses the source-content colour space rather than the monitor's.

[peteroupc]

@alastc:

This issue is primarily for the benefit of tool implementers, not necessarily Web authors; such implementers benefit from an unambiguous implementation of the contrast ratio calculation. While this is by and large clear for sRGB, this is not necessarily so for color spaces other than sRGB — and as time goes on, such color spaces (including DCI-P3 and Adobe RGB (1998)) will become more and more commonplace.

As I already mentioned in the opening post, in the case of 8-bit linear sRGB (which is the most common
case seen in Web content), the threshold of 0.04045 vs. 0.03928 doesn't make a difference. However, if we raise the precision to 16 bits (a possible case if the WCAG is applied to graphical user interfaces in general), this difference may matter in very rare cases. (The sRGB transfer function consists of a "curved" part and a "linear" part; the threshold of 0.04045 vs. 0.03928 indicates when the linear part ends and the curved part begins; it doesn't change the formulas for either part.)

I mentioned before some of the things that can be added to the "Understanding WCAG" document — which includes proposed text that assures tool implementers that they can implement the "real sRGB" rather than the "proposal sRGB" given in note 1 of the "relative luminance" definition.

I repeat what you said earlier:

I wonder if @GreggVan could comment on the source of the sRGB threshold, from the comment above?

[alastc]

as time goes on, such color spaces (including DCI-P3 and Adobe RGB (1998)) will become more and more commonplace.

As an author using #787878 on #FFF what impact would that have?

I'm still not clear on how a web designer / developer would use this information?

If it is for toolmakers then I'd rather get some of them involved and write it up somewhere else.

[peteroupc]

As I mentioned before, "color specifications in CSS (and presumably in HTML as well)", such as #787878 or #FFF, "are in terms of sRGB regardless of the monitor's color gamut or the computer's working color space", so in the case of such color specifications, there is little to no impact because those specifications are in terms of sRGB rather than DCI-P3 or another color space.

However, "this doesn't rule out images with profiles specifying a non-sRGB color space", which can occur even in Web content; for example, a nature photo using an Adobe RGB (1998) color space as an image on a Web page. Here, naively applying sRGB calculations to such an image (such as finding the contrast ratio in terms of sRGB) could lead to incorrect results, since the ranges of colors in both color spaces are almost surely not identical. In any situation where Web content (such as images) in a non-sRGB color space is involved, authors might have to convert such content to sRGB for compatibility reasons (and even here, the techniques for doing so — collectively called "gamut mapping" — differ considerably), as some Web browsers might not have enough color management to deal with non-sRGB color spaces intelligently.

And as I mentioned before, the WCAG has found use outside the Web; for example in Google's material design specifications for mobile apps; thus the possibility that mobile apps (or other graphical user interfaces) use a non-sRGB color space is not ruled out either. Non-Web applications of the WCAG might or might not be faced with the same issues to the same extent.

[GreggVan]

I believe it was from an ISO standard - but I would have to dig back into my archives from before I moved from University of Wisconsin-Madison to University of Maryland to find the exact standard. I no longer have that standard handy. (it was a printed copy) and my co-worker on this has retired. best Gregg

…

On Apr 30, 2018, at 9:42 AM, Peter Occil ***@***.***> wrote: I repeat what you said earlier: I wonder if @GreggVan <https://github.com/GreggVan> could comment on the source of the sRGB threshold, from the comment above <#815 (comment)>? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#815 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3iqZUVLZiP1xl0S3GbQ2xZpDm-wDks5ttxTbgaJpZM4S5qES>.

[peteroupc]

Is adding an informative (not normative) note like the following to the "relative luminance" definition within the scope of the WCAG 2.1 revision?

NOTE xx: This is also equivalent to a color's luminance factor, which is roughly the light that is seen when a color is viewed, compared to "white" light.

I wrote the following in a previous comment. Is adding information described below, if not in an Understanding WCAG document, then in some other document, within the scope of the WCAG 2.1 revision?

[Some document] can explain how relative luminance is calculated in general for any (additive) RGB color space (not just sRGB), namely—

• converting each RGB component to linear RGB (which for many RGB color spaces is a simple gamma function), then
• calculating a weighted sum of the three RGB components, where each weight is the relative luminance of the color space's red, green, or blue point (e.g., 0.2126, 0.7152, and 0.0722, respectively, in note 1).

Is changing the first paragraph of "Notes to formula" in the document "Understanding Success Criterion 1.4.3" to say the following (and supplying the appropriate reference) within the scope of the WCAG 2.1 revision?

Conversion from nonlinear to linear RGB values is based on IEC/4WD 61966-2-1 [IEC-4WD] and on "A Standard Default Color Space for the Internet - sRGB" [sRGB]. Note that the threshold used in the conversion given there, 0.03928, is different from the threshold used in the final version of IEC 61966-2-1, which is 0.04045 [IEC-61966-2-1].

(Does "4WD" stand for "fourth working draft"?)

The following is suggested text to add to "Understanding Success Criterion 1.4.11" or "Understanding Success Criterion 1.4.3" with respect to non-sRGB color spaces, particularly in images. (The text in square brackets below is suggested for 1.4.3 only.)

A note on color spaces

There are many red-green-blue (RGB) color spaces, including sRGB, Adobe RGB (1998), and DCI-P3. [Color specifications in CSS and HTML, such as #787878 or #FFF, are in terms of sRGB regardless of the monitor's color gamut or the computer's working color space.] Images in some image formats, including PNG, can include a color profile specifying a custom color space. An example is a nature photo using an Adobe RGB (1998) color space as an image on a Web page. If an image includes a color profile, naively applying sRGB calculations to that image (such as finding the contrast ratio in terms of sRGB) could lead to incorrect results, since the ranges of colors in both color spaces are almost surely not identical.

In any situation where images in a non-sRGB color space are involved, authors might have to convert such images to sRGB for compatibility reasons (the approaches for doing so — collectively called "gamut mapping" — are beyond the scope of this document), as some Web browsers might not have enough color management to deal with non-sRGB color spaces intelligently.

(Note that a reference to the PNG specification might be added here if it speaks of color profiles.)

[awkawk]

Thanks for all of the commentary. We wanted to verify what possible impact there is with the sRGB formula if the value is .03928 vs. 0.04045 and we see (and now I see that this is consistent with what you have been saying) no impact. We will be proposing an additional note in Understanding for the group and appreciate your suggestions.

[GreggVan]

hi Peter Both Understanding WCAG 2.0 and Understanding WCAG 2.1 are INFORMATIVE documents — so both of they can be changed to add information like this. If this is a note on a WCAG 2.0 SC - I think the text should be in both documents - since it would apply to understanding WCAG 2.0 and WCAG 2.1 equally. Gregg

…

On May 7, 2018, at 11:04 AM, Peter Occil ***@***.***> wrote: Is adding an informative (not normative) note like the following to the "relative luminance" definition within the scope of the WCAG 2.1 revision? NOTE xx: This is also equivalent to a color's luminance factor, which is roughly the light that is seen when a color is viewed, compared to "white" light. I wrote the following in a previous comment. Is adding information described below, if not in an Understanding WCAG document, then in some other document, within the scope of the WCAG 2.1 revision? [Some document] can explain how relative luminance is calculated in general for any (additive) RGB color space (not just sRGB), namely— converting each RGB component to linear RGB (which for many RGB color spaces is a simple gamma function), then calculating a weighted sum of the three RGB components, where each weight is the relative luminance of the color space's red, green, or blue point (e.g., 0.2126, 0.7152, and 0.0722, respectively, in note 1). Is changing the first paragraph of "Notes to formula" in the document "Understanding Success Criterion 1.4.3" to say the following (and supplying the appropriate reference) within the scope of the WCAG 2.1 revision? Conversion from nonlinear to linear RGB values is based on IEC/4WD 61966-2-1 [IEC-4WD] and on "A Standard Default Color Space for the Internet - sRGB" [sRGB]. Note that the threshold used in the sRGB inverse transfer function given there, 0.03928, is different from the threshold used in the final version of IEC 61966-2-1, which is 0.04045 [IEC-61966-2-1]. (Does "4WD" stand for "fourth working draft"?) The following is suggested text to add to "Understanding Success Criterion 1.4.3" with respect to non-sRGB color spaces, particularly in images. A note on color spaces There are many red-green-blue (RGB) color spaces, including sRGB, Adobe RGB (1998), and DCI-P3. Although color specifications in CSS and HTML, such as #787878 or #FFF, are in terms of sRGB regardless of the monitor's color gamut or the computer's working color space, certain other Web content, notably images, can include a color profile specifying a custom color space. An example is a nature photo using an Adobe RGB (1998) color space as an image on a Web page. (Most images won't have a color profile and so will be treated as sRGB images by default.) Here, naively applying sRGB calculations to such an image (such as finding the contrast ratio in terms of sRGB) could lead to incorrect results, since the ranges of colors in both color spaces are almost surely not identical. In any situation where Web content (such as images) in a non-sRGB color space is involved, authors might have to convert such images to sRGB for compatibility reasons (the approaches for doing so — collectively called "gamut mapping" — are beyond the scope of this document), as some Web browsers might not have enough color management to deal with non-sRGB color spaces intelligently. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#815 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3r_4C0n0TWYMTdh8oITQCZj7gM8Yks5twGJlgaJpZM4S5qES>.

[WayneEDick]

Hi All I have studied the published formula and find it unnecessarily confusing. Also, I think transparency is missing. Her is my outline to fix things. Step I: Use a more understandable set of parameters for the base calculation of contrast. Why don't we recalculate this on a scale like HSL, or a suitable modern variant? There are many conversion programs from the RGB family to the HSL family. This would enable calculation to to be expressed directly in terms of luminosity. That would make the process much more understandable. The big problem with the RGB formula is twofold. 1) luminosity is not related to RGB by a linear function. Thus. the mappings between these two bases of color have exponents or logs in the formulas. That is ugly. 2) Black has an RGB value of (0,0,0) so it's luminosity is zero. Since luminosity is a ratio. Anything over Black luminosity is not defined. That results in a lot of logic to cope with, "What do we do when the luminosity in the denominator is zero". Again, necessary but ugly. The combination of these two difficulties with RGB makes for a nasty formula for an understanding document. (Note: the zero denominator will always be a problem, but it will be more understandable if it isn't preceded by a formula involving transcendental functions.) Also, we should be clear as to what contrast formula we are using. Sometimes people use L(f)+L(b)/L(b) and others use L(f) / L(b) where L(f)=luminosity of foreground and L(b)= luminosity of the background. Step 2: Update the formula to accommodate for the transparency / opaque spectrum. The differences in monitors really doesn't make that big of a difference, but partially transparency is a big deal. I hope current color checkers do this because a partially transparent light on dark field that sits on top of a darker background is not visible. I am not sure if the W3C published formula has been updated for this. Wayne

…

On Mon, May 7, 2018 at 10:03 AM GreggVan ***@***.***> wrote: hi Peter Both Understanding WCAG 2.0 and Understanding WCAG 2.1 are INFORMATIVE documents — so both of they can be changed to add information like this. If this is a note on a WCAG 2.0 SC - I think the text should be in both documents - since it would apply to understanding WCAG 2.0 and WCAG 2.1 equally. Gregg > On May 7, 2018, at 11:04 AM, Peter Occil ***@***.***> wrote: > > Is adding an informative (not normative) note like the following to the "relative luminance" definition within the scope of the WCAG 2.1 revision? > > NOTE xx: This is also equivalent to a color's luminance factor, which is roughly the light that is seen when a color is viewed, compared to "white" light. > > I wrote the following in a previous comment. Is adding information described below, if not in an Understanding WCAG document, then in some other document, within the scope of the WCAG 2.1 revision? > > [Some document] can explain how relative luminance is calculated in general for any (additive) RGB color space (not just sRGB), namely— > > converting each RGB component to linear RGB (which for many RGB color spaces is a simple gamma function), then > calculating a weighted sum of the three RGB components, where each weight is the relative luminance of the color space's red, green, or blue point (e.g., 0.2126, 0.7152, and 0.0722, respectively, in note 1). > Is changing the first paragraph of "Notes to formula" in the document "Understanding Success Criterion 1.4.3" to say the following (and supplying the appropriate reference) within the scope of the WCAG 2.1 revision? > > Conversion from nonlinear to linear RGB values is based on IEC/4WD 61966-2-1 [IEC-4WD] and on "A Standard Default Color Space for the Internet - sRGB" [sRGB]. Note that the threshold used in the sRGB inverse transfer function given there, 0.03928, is different from the threshold used in the final version of IEC 61966-2-1, which is 0.04045 [IEC-61966-2-1]. > > (Does "4WD" stand for "fourth working draft"?) > > The following is suggested text to add to "Understanding Success Criterion 1.4.3" with respect to non-sRGB color spaces, particularly in images. > > A note on color spaces > > There are many red-green-blue (RGB) color spaces, including sRGB, Adobe RGB (1998), and DCI-P3. Although color specifications in CSS and HTML, such as #787878 or #FFF, are in terms of sRGB regardless of the monitor's color gamut or the computer's working color space, certain other Web content, notably images, can include a color profile specifying a custom color space. An example is a nature photo using an Adobe RGB (1998) color space as an image on a Web page. (Most images won't have a color profile and so will be treated as sRGB images by default.) Here, naively applying sRGB calculations to such an image (such as finding the contrast ratio in terms of sRGB) could lead to incorrect results, since the ranges of colors in both color spaces are almost surely not identical. > > In any situation where Web content (such as images) in a non-sRGB color space is involved, authors might have to convert such images to sRGB for compatibility reasons (the approaches for doing so — collectively called "gamut mapping" — are beyond the scope of this document), as some Web browsers might not have enough color management to deal with non-sRGB color spaces intelligently. > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub < #815 (comment)>, or mute the thread < https://github.com/notifications/unsubscribe-auth/AJph3r_4C0n0TWYMTdh8oITQCZj7gM8Yks5twGJlgaJpZM4S5qES >. > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#815 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AH0OF_Ulfc7STlLaKJtVNvBpIoMpwvBcks5twH5lgaJpZM4S5qES> .

[GreggVan]

Hi Wayne interesting And good catch on the transparency issue However see below on your other points

On May 7, 2018, at 1:50 PM, WayneEDick ***@***.***> wrote: Hi All I have studied the published formula and find it unnecessarily confusing. Also, I think transparency is missing. Her is my outline to fix things. Step I: Use a more understandable set of parameters for the base calculation of contrast. Why don't we recalculate this on a scale like HSL, or a suitable modern variant? There are many conversion programs from the RGB family to the HSL family. This would enable calculation to to be expressed directly in terms of luminosity. That would make the process much more understandable.

No problem recalculating but the standard is in RGB - and no way to change that. Also not clear what that gives you.

The big problem with the RGB formula is twofold. 1) luminosity is not related to RGB by a linear function. Thus. the mappings between these two bases of color have exponents or logs in the formulas. That is ugly.

Well math is not ugly. It may be complicated for some - but it only needs to be comprehended by people creating tools. No one actually does any math. They simply use a tool. Our cars are full of calculus — but that doesn't make them hard to drive. (it actually makes them easier). Tool makers can do the math.

2) Black has an RGB value of (0,0,0) so it's luminosity is zero. Since luminosity is a ratio. Anything over Black luminosity is not defined.

Yes but that is true on any color space. So transforming it doesn’t make this go away. PS the formula in our standard is (L1 + 0.05) / (L2 + 0.05), so there is no division by zero anyway.

That results in a lot of logic to cope with, "What do we do when the luminosity in the denominator is zero". Again, necessary but ugly. The combination of these two difficulties with RGB makes for a nasty formula for an understanding document. (Note: the zero denominator will always be a problem, but it will be more understandable if it isn't preceded by a formula involving transcendental functions.)

Again. Transcendental functions are in every piece of technology we use. But only those engineering the tool needs to do the math.

Also, we should be clear as to what contrast formula we are using. Sometimes people use L(f)+L(b)/L(b) and others use L(f) / L(b) where L(f)=luminosity of foreground and L(b)= luminosity of the background.

We are clear. it is right there in the standard. We are using (L1 + 0.05) / (L2 + 0.05), where L1 is the relative luminance <https://www.w3.org/TR/WCAG20/#relativeluminancedef> of the lighter of the colors, and L2 is the relative luminance <https://www.w3.org/TR/WCAG20/#relativeluminancedef> of the darker of the colors.

Step 2: Update the formula to accommodate for the transparency / opaque spectrum. The differences in monitors really doesn't make that big of a difference, but partially transparency is a big deal. I hope current color checkers do this because a partially transparent light on dark field that sits on top of a darker background is not visible.

GOOD CATCH The standard is for the image as it appears to the user. whether it is a solid color the the mix of two colors via transparency. However, a note on the transparency mixing issue should be in the Understanding WCAG 2.0 document - to be sure that the Tools adequately account for this phenomenon and consider the transparency and underlying color when dealing with a transparent upper color.

…

I am not sure if the W3C published formula has been updated for this. Wayne On Mon, May 7, 2018 at 10:03 AM GreggVan ***@***.***> wrote: > hi Peter > > Both Understanding WCAG 2.0 and Understanding WCAG 2.1 are INFORMATIVE > documents — so both of they can be changed to add information like this. > > If this is a note on a WCAG 2.0 SC - I think the text should be in both > documents - since it would apply to understanding WCAG 2.0 and WCAG 2.1 > equally. > > Gregg > > > > > On May 7, 2018, at 11:04 AM, Peter Occil ***@***.***> > wrote: > > > > Is adding an informative (not normative) note like the following to the > "relative luminance" definition within the scope of the WCAG 2.1 revision? > > > > NOTE xx: This is also equivalent to a color's luminance factor, which is > roughly the light that is seen when a color is viewed, compared to "white" > light. > > > > I wrote the following in a previous comment. Is adding information > described below, if not in an Understanding WCAG document, then in some > other document, within the scope of the WCAG 2.1 revision? > > > > [Some document] can explain how relative luminance is calculated in > general for any (additive) RGB color space (not just sRGB), namely— > > > > converting each RGB component to linear RGB (which for many RGB color > spaces is a simple gamma function), then > > calculating a weighted sum of the three RGB components, where each > weight is the relative luminance of the color space's red, green, or blue > point (e.g., 0.2126, 0.7152, and 0.0722, respectively, in note 1). > > Is changing the first paragraph of "Notes to formula" in the document > "Understanding Success Criterion 1.4.3" to say the following (and supplying > the appropriate reference) within the scope of the WCAG 2.1 revision? > > > > Conversion from nonlinear to linear RGB values is based on IEC/4WD > 61966-2-1 [IEC-4WD] and on "A Standard Default Color Space for the Internet > - sRGB" [sRGB]. Note that the threshold used in the sRGB inverse transfer > function given there, 0.03928, is different from the threshold used in the > final version of IEC 61966-2-1, which is 0.04045 [IEC-61966-2-1]. > > > > (Does "4WD" stand for "fourth working draft"?) > > > > The following is suggested text to add to "Understanding Success > Criterion 1.4.3" with respect to non-sRGB color spaces, particularly in > images. > > > > A note on color spaces > > > > There are many red-green-blue (RGB) color spaces, including sRGB, Adobe > RGB (1998), and DCI-P3. Although color specifications in CSS and HTML, such > as #787878 or #FFF, are in terms of sRGB regardless of the monitor's color > gamut or the computer's working color space, certain other Web content, > notably images, can include a color profile specifying a custom color > space. An example is a nature photo using an Adobe RGB (1998) color space > as an image on a Web page. (Most images won't have a color profile and so > will be treated as sRGB images by default.) Here, naively applying sRGB > calculations to such an image (such as finding the contrast ratio in terms > of sRGB) could lead to incorrect results, since the ranges of colors in > both color spaces are almost surely not identical. > > > > In any situation where Web content (such as images) in a non-sRGB color > space is involved, authors might have to convert such images to sRGB for > compatibility reasons (the approaches for doing so — collectively called > "gamut mapping" — are beyond the scope of this document), as some Web > browsers might not have enough color management to deal with non-sRGB color > spaces intelligently. > > > > — > > You are receiving this because you were mentioned. > > Reply to this email directly, view it on GitHub < > #815 (comment)>, or mute > the thread < > https://github.com/notifications/unsubscribe-auth/AJph3r_4C0n0TWYMTdh8oITQCZj7gM8Yks5twGJlgaJpZM4S5qES > >. > > > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#815 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AH0OF_Ulfc7STlLaKJtVNvBpIoMpwvBcks5twH5lgaJpZM4S5qES> > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#815 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3utS8c4sd_-TC3FN9XLIePson7NBks5twIlmgaJpZM4S5qES>.

[patrickhlauke]

just as an aside on transparency, just to spell it out: of course we can't take into account transparency of the background, as then that would depend on what's behind THAT colour.

and on just working in HSL: i seem to recall that the current RGB formula takes into account that different hues, even if at the same saturation and lightness, have a different perceived luminance - so it's not just a straight comparison of the lightness in HSL.

[michael-n-cooper]

Migrated to w3c/wcag#360