Relative Luminance contrast values not changed everywhere

[mbgower]

in PR 1780 the RsRGB values were altered; however, not all occurrences seem to have been acted upon.

The changes seem to have been considered across version of 2.x. The following files are in the PR:
guidelines/terms/20/relative-luminance.html
understanding/20/contrast-enhanced.html
understanding/20/contrast-minimum.html

However, for WCAG 2.2, I'm seeing the new 0.0404 numbers adopted in the Understanding documents but not in the standard definition

Further, all the following have not been updated
https://www.w3.org/TR/WCAG20/#relativeluminancedef
https://www.w3.org/TR/WCAG21/#dfn-relative-luminance
https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html#dfn-relative-luminance

[bruce-usab]

Did we decide on the final treatment for this little bug? My recollection is that we decided to make the change in Understanding, but that then we would survey AGWG to either (1) replicated correction throughout 2.2 materials, (2) revert 2.2 Understanding, or (3) something else.

For Understanding, I had previously made an editorial suggestion for the second Note:

It has no practical effect on the calculations in the context of these guidelines.

IMHO we should strike practical so:

It has no effect on the calculations in the context of these guidelines.

That might also be provocative. So how about:

Calculations using the previous value result in no differences to two decimal points, and have no practical effect in the context of these guidelines.

Alternatively, leave this (new) note as is, but add some exposition only in Understanding?

[mraccess77]

It does impact the calculation - but not the resulting values used to in the ratio. So it has no effect on the outcome.

[bruce-usab]

Understood and agreed. That is the phrasing I would like to see in the note or in understanding.

Edit to note that I agree It has no practical effect on the calculations in the context of these guidelines == no effect on the outcome. Reviewing the minutes, my recollection was for a different edit, removing "should", and that has been incorporated.

[alastc]

Minutes: https://www.w3.org/2021/05/11-ag-minutes.html#item07
PR: https://github.com/w3c/wcag/pull/1780/files
CFC: https://lists.w3.org/Archives/Public/w3c-wai-gl/2021AprJun/0209.html

So it was intended to go into 2.1 (as an errata) & 2.2.

Some of the locations Michael referenced wouldn't update, such as the TR doc for WCAG 2.1 (due to... reasons that are beyond me). However, it should be listed as an errata: https://www.w3.org/WAI/WCAG21/errata/

@michael-n-cooper could you check the errata for the PR above? It was marked as errata, but doesn't I'm not sure how to cherry pick that change for the 2.1 branch or add the errata statement.

The place I would expect to see it is the understanding doc: https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html#dfn-relative-luminance

Michael, do the 2.1 docs need a publishing update? (I thought it had been done since June, but perhaps if it wasn't in the 2.1 branch it didn't take effect?)

[Myndex]

Hi @mbgower @bruce-usab @mraccess77 @alastc

Basically, if 8bit integers are used, there is no effect, as Jonathan pointed out in another thread that 0.3928 and 0.4045 are between code values 0x0a and 0x0b ...

Floating points

CSS 4 is bringing with it floating point (0.0 to 255.0), as it is needed for the new color spaces. Float values are potentially affected, so it is good to change this soon as CSS4 is not recommendation yet but will be in the not too distant future, and many features are already being adopted.

So out of an abundance of caution, I just ran the numbers, and the worst case error in terms of the WCAG ratio (at the threshold of pass/no pass for 7:1) is 0.00009971172471612280

In other words, not more than ±0.0001 and in the area near black (which is where WCAG 2 math is otherwise lacking accuracy for unrelated reasons)

So an example, with a CSS4 value of rgb(164,164,164.5) against rgb(10.017,10.017,10.017)

** 7.002657590700490** with 0.03928
** 7.002557878975780** with 0.04045

And both still round to 7.00 (for the record, Bridge PCA calls this 2.7:1 and rejects it for text)

So while this is not a thing for the end user, it is still the kind of thing that could cause head-scratching for developers trying to find bugs, etc. and should definitely be corrected in that light.

[michael-n-cooper]

I've cherry-picked the change into the 2.1 branch, noted the erratum in 2.1 and updated the 2.1 Understanding and 2.1 Techniques. Doing so for 2.0 is a whole 'nother kettle of fish, putting on my todo list to sort out sometime.

[bruce-usab]

@michael-n-cooper — One more item for your todo list is another patch to 2.0 errata.

I noticed today that the 2.0 errata page incorporates correcting 0.03928 to 0.04045. From the file date, that was 3/8. As you wrote above, the 2.1 errata page has the correction, but it lists the file modification date as 2017/05/24.

The abstract section of the errata page reads:

Each entry has the following information:

• The date it was added to the errata page.
  …
• A rationale for making the change (not required for editorial errata)

I would note that:

• None of the errata bullets include a date.
• No rationale is not provided for the change from 0.03928 to 0.04045.

My expectation was that the rational would essentially be the same as the note from 2.1 Understanding, including this sentence:

It has no practical effect on the calculations in the context of these guidelines.

Let me know if we be helpful for me to send a separate email, open a new issue, or pull request.