[css-color-6] Parameter for font size in `contrast-color()`?

[LeaVerou]

The current grammar for the target contrast ratio is:

to [<number> | AA | AA-large | AAA | AAA-large]

This requires authors to know when to apply *-large and when not to. Given that these are expressed in pt, that requires a fair bit of mental gymnastics.

I was wondering if something like this would be better:

to [ <number> | [AA | AAA] [for <length>]? ]

Where <length> defaults to 1em.

(Let's please not have a discussion about the potential future contrast algorithms in WCAG 3. We can cross that bridge when we get to it, and both syntaxes allow for future expansion)

[svgeesus]

Automating this is a good idea in theory,and leveraging the ability of CSS to convert between length units is attractive.

However there is some hand-waving in WCAG 2.1 which makes this less algorithmic and thus more difficult to implement. For example

or font size that would yield equivalent size for Chinese, Japanese and Korean (CJK) fonts

and

For many mainstream body text fonts, 14 and 18 point is roughly equivalent to 1.2 and 1.5 em or to 120% or 150% of the default size for body text (assuming that the body font is 100%), but authors would need to check this for the particular fonts in use.

The precise nature of the font-specific check, or the definition of equivalent font size for CJK, could use some clarity.

[michael-n-cooper]

APA just wants to make sure you are aware of the new approach to color contrast proposed for WCAG 3:

https://www.w3.org/WAI/GL/WCAG3/2020/how-tos/visual-contrast-of-text/

This is a draft new algorithm which could change or be removed, but might be good to consider related to this issue, and provide feedback on the algorithm if needed.

[svgeesus]

Thanks @michael-n-cooper I'm aware of the new proposal in WCAG 3.0 and should probably raise issues (the conversion to luminance is non-standard, which makes it had to use with other color spaces, for example).

[Myndex]

Thanks @michael-n-cooper I'm aware of the new proposal in WCAG 3.0 and should probably raise issues (the conversion to luminance is non-standard, which makes it had to use with other color spaces, for example).

Hi Chris @svgeesus

The TLDR is "For non-HDR displays, the colorspace is simply selected by the three coefficients, and the pre-processing exponent."

Input Stage Notes

Technically, it does not convert to a traditional calculated luminance, and is not intended to. The first stage is a conversion to model of typical monitors in typical environmental settings. Included is consideration of surveys of case studies of monitors in real-world environments. This pre-processing stage also includes a soft clamp at black for initial monitor modeling. (Interestingly earlier today I was looking at the DICOM spec, which happens to model displays similarly.) The need for the soft clamp makes using the piecewise redundant, as that section near black is reshaped by the soft clamp to account for ambient flare.

The contrast calculation stage then applies a different exponent to the BG, which drives local adaptation, and the stimuli (text) that is substantially affected by that adaptation.

The piecewise sRGB TRC is not an emulation of actual monitor behavior, having been created to prevent infinite slope at 0 to facilitate digital processing. The APCA is not about processing images and round trips, where using the piecewise curve is of benefit. It is useful to note that many ICC profiles (including those that ship with Adobe products) do not use the piecewise, and instead use the simple 2.2 gamma, which the piecewise was intended to emulate, and the IEC standard indicates the physical display being the simple gamma.

The only thing in the APCA input stage that is really different is the exponent set to 2.4. This slightly higher exponent is added as part of pre-processing to relax the exponents in the contrast determination stage, and the aforementioned modeling of real-world monitors and devices. The "extra" could be added separately before the contrast stage, but is combined for simplicity in the current implementation.

That said, APCA is intended only to predict a display, and the perceived supra-threshold contrast for best readability, and to be perceptually uniform when doing so. Any alternate colorspaces therefore must be the destination display colorspace.

For AdobeRGB, Apple Display P3, and sRGB, changing destination colorspace is a matter of swapping out the coefficients.

For Rec2020, there may need to be an additional pre-processing adjustment to the exponent. I have yet to evaluate Rec2020 as I do not have a Rec2020 monitor at my disposal. Rec2020 does have some additional accessibility issues which will entail some separate discussion, largely that the red primary is out of range of someone with protanopia (invisible).

For Rec2100 and other HDR types, a different set of constants and exponents is expected, and probably other modifications.

But for non-HDR displays, the colorspace is simply selected by the three coefficients, and the pre-processing exponent.

Outside of the question on colorspace, if you have other thoughts, I am certainly interested in hearing them.

Thank you

Andy

[svgeesus]

There is a lot to pick apart in that response, which in general is very handwavy and poorly defined, but this is not the place for it.

However, this issue is about making it easier to select the correct WCAG 2.1 contrast.

If WCAG 3.0 starts to nail down the new contrast algorithm such that it is adequately documented, widely reviewed, and multiply implementable then we could revisit to select the right level (which apparently would need the font size, and some indication of how serify the font is, and a bunch of other as-yet poorly defined criteria).

[Myndex]

There is a lot to pick apart in that response, which in general is very handwavy and poorly defined, but this is not the place for it.

Hi Chris @svgeesus

I'm concerned you find my reply "handwavy" though to be sure, I'm not quite ready to "defend my thesis" — mainly I wanted to address the statement regarding colorspaces, as that flexibility has always been a consideration, and there is substantial due diligence behind this project.

However, this issue is about making it easier to select the correct WCAG 2.1 contrast.

Understood, I simply saw some of your concerns in your reply to Michael, and I wanted to address them and mention the background/basis for some of the work.

If WCAG 3.0 starts to nail down the new contrast algorithm such that it is adequately documented, widely reviewed, and multiply implementable then we could revisit to select the right level (which apparently would need the font size, and some indication of how serify the font is, and a bunch of other as-yet poorly defined criteria).

There is documentation, white papers, and other discussion up on my site, GitHub, W3, and elsewhere, as well as some informal reviews, though this is certainly a work in progress. Font definition related methods are part of the plan for next year.

Nevertheless, APCA does not require anything regarding the font, as far as returning the L^c value. The font recommendation is separated, in part to facilitate use with other languages, which use different glyphs / logograms etc.

There is a lot of new activity in the newly re-born Low Vision Task Force, but I was planning on reaching out later and more formerly once the key paper is close to ready... Covid slowed some of the empirical study sadly, but getting moving again.....

Thank you,

Andy