Open atanassov opened 4 years ago
lch(from var(--mycolor))
, which can also be computed easily via even the old CSSOM.color()
as a predefined color space. Relative luminance is just the Y component of XYZ, and contrast ratio is just a ratio of relative luminances + 0.05.That said, it would be good to have a color-space agnostic Color
object that supports all the manipulations CSS Color does, though not sure Typed OM is a good place for it. In fact, @svgeesus and I are prototyping such a Color object and plan to release it as a library soonish. It has given us a lot of insight into API decisions for something like this, and I suspect releasing it into the wild will give us a lot more.
Excited to hear you're prototyping something! Eventually having a standardized Color
constructor living on CSS.Color
seems like a natural fit here, IMHO.
I know Lea and Chris are already well aware of this, but for those reading along, this came up earlier in this whatwg/html issue. There might be some useful suggestions in the comments.
@LeaVerou @atanassov Hi Lea and Rossen,
Just FYI the contrast methodology is changing in a future version WCAG (3.0 aka Silver) the current code for the new version is very beta, and will have additional capabilities for modeling and predicting contrast perception.
There is a test/example page of the algorithim here: https://www.myndex.com/SAPC/
A description of the methodology is here: https://www.myndex.com/WEB/WCAG_CE17polarity
A description of how FONT WEIGHT & SIZE directly affects contrast separate from the foreground and background colors. This is important to the understanding of perceived contrast and readability: https://www.myndex.com/WEB/WCAG_CE14weight
And my repository of some work in progress is here: https://github.com/Myndex/SAPC
NOTE: This is all beta, including explanatory texts, and subject to change. The research code name is SAPC-7, but as released will be called APCA (Advanced Perceptual Contrast Algorithm).
Please let me know if you have any questions.
Andy
Hi Andy,
Thank you for the update. It's great to hear that there are plans to improve the contrast algorithm, as it is indeed rather problematic. I tried following the thread I linked to above but it was way too long and seemed to be mostly notes of original research. Is there a working group resolution or draft spec? I'm afraid until there is, we cannot build on top of it in other specs, but we will certainly keep this in mind in anything we design.
I tried following the thread I linked to above but it was way too long and seemed to be mostly notes of original research. Is there a working group resolution or draft spec? I'm afraid until there is, we cannot build on top of it in other specs, but we will certainly keep this in mind in anything we design.
@LeaVerou Hi Lea,
Yes, thread 695 get quite dense. The first three links in my post above provide a working example, and some documentation on the methodology.
The official working draft is not released for Silver, but there is a work in progress you can view here:
EDIT: to replace an obsolete link with this catalog of APCA resources.
But yes, this is more of a "heads up/what's coming." and to be clear the aim is to predict readability as opposed to perceived contrast. Complete models like Hunt or ICAM are very complex; here the goal is to keep the prediction as simple as possible to maintain readability as opposed to a complete prediction of image assessment.
Something much farther off is the SAPC standard observer and SLAB or SLUV, a lab type space but specific to sRGB. (More focused on accessibility adjustments)
Let me know if you have any questions or thoughts.
Note that Color 4 does include sample code for color conversions and, while this is non-normative and illustrative, it does work. I used it to make a lot of the diagrams and examples for CSS Color 4 and 5.
It isn't necessarily a good API design, it was primarily intended to be super simple to read and understand.
To avoid cluttering the sample code, I put additional stuff that I needed in practice into a separate utilities file which includes, for instance, the WCAG 2.x relative contrast ratio. Not just for sRGB, but for any color space (display-p3, Lab, and so on).
Lea and I have been working on a more modern, object oriented library for color conversions. We would be happy to demonstrate this at the next virtual F2F. The two produce equivalent results.
The CSS Working Group just discussed Color Conversion and Contrast Ratio
.
Excited to hear you're prototyping something! Eventually having a standardized Color constructor living on CSS.Color seems like a natural fit here, IMHO.
As the maintainer of color
I agree. I simply strongly caution against letting it become a kitchen sink. I would love to see color
be obsoleted by standard browser functionality at some point, to be completely honest.
@atanassov wrote:
Further, it would be great to have a function that enables contrast ratio calc given any two colors. The expectations for color contrast described by WCAG are rather detailed and lack developer ergonomics
The WCAG contrast ratio is detailed enough, for sRGB only, but lacks explanation. However it is easy to work out what is being done - the relative, D65-adapted XYZ is calculated for the two colors and the luminance (Y) is used to calculate the contrast.
Given that, it is trivial to extend to other RGB spaces (whether they use D65 or not) and to XYZ, Lab and LCH. Color.js does this, so you can ask for a contrast ratio between any pair of colors regardless of what colorspace each was originally specified in.
@atanassov wrote:
Further, it would be great to have a function that enables contrast ratio calc given any two colors. The expectations for color contrast described by WCAG are rather detailed and lack developer ergonomics
@svgeesus The WCAG contrast ratio is detailed enough, for sRGB only, but lacks explanation. However it is easy to work out what is being done - the relative, D65-adapted XYZ is calculated for the two colors and the luminance (Y) is used to calculate the contrast.
Given that, it is trivial to extend to other RGB spaces (whether they use D65 or not) and to XYZ, Lab and LCH. Color.js does this, so you can ask for a contrast ratio between any pair of colors regardless of what colorspace each was originally specified in.
However, the ratio as expressed by the WCAG 2.x math is of questionable utility, as it is not relative to perception as we've discussed elsewhere. As WCAG 2.x contrast ratios do not follow visual perception, the ratio expressed is meaningless, and therefore scaling it to other spaces will carry that same meaningless presentation that does not predict the perception of contrast of a self-illuminated display. WCAG 2.x "4.5:1" is not even remotely consistent in appearance across the range of lightness on the small colorspace of an sRGB monitor, and I should think that scaling to much larger spaces will only exacerbate this problem.
A similar problem exists with Weber, Mod-Weber, and Michelson, as they are all set to predict contrast at threshold for the JND, but become increasingly inaccurate at suprathreshold levels. Suprathreshold contrast prediction is what is needed to give designers useful guidance for readability/discernibility.
At the moment, the implementation of contrast prediction for Silver/WCAG 3.0 is the APCA (derived from SAPC) which is a suprathreshold perceptual contrast appearance model. Presently it is aligned with the sRGB transfer curve, using a standardized observer with ambient luminance at 20% of display max white.
It is sensitive to ambient levels, spatial frequency, and other factors — and for HDR there is the question of where "page white" and "peak white" are mapped (not to mention the different HDR TRC types). Fitting to different transfer curves or gamma, and different expected environments, and as well considering certain adaptive technologies, adds significant complexity as far as selecting the various constants & exponents.
From an accessibility perspective, the coordinates for the primaries of a given colorspace will have an effect on useful choices of constants for improving accessibility with certain impairments.
This leads us to question if we need considerations of things like the H-K effect on perceived contrast — though for readable content, we are mostly interested in font contrast against a background that helps get stimuli to the Visual Word Form Area (VFWA), a pre-lexical processing of whole words and letter pairs, needed for best readability and reading speed.
Current research indicates that this processing path relies on the luminance component, and not chroma. Nevertheless, hue & chroma have implications for various impairments and other visual issues such as chromatic aberration, glare, scatter, and CVD. As such even a perceptual contrast based only on perceived lightness (derived from calculated luminance) presents challenges for accessibility with tristimulus color models.
All of this is a long way to say that these (SAPC/APCA/RLAB/CAMxx/etc) methods for contrast appearance prediction are certainly scalable to different spaces, but not necessarily trivial if the goal is a perceptual uniformity across the various colorspaces.
If we assert that perceptual uniformity is desired for the contrast metric to be useful, then the extra effort for such scaling/mapping is warranted. There are some enhancements I have not made public yet that may become helpful for some of these more complex issues, but still under evaluation.
Andy
With the the current color space additions to [css-color-4], namely lch() and lab(), we solved the declarative side of the problem. What we lack is the ability to request or at least easily convert computed color values into these color spaces. Can we allow that in Typed OM?
Further, it would be great to have a function that enables contrast ratio calc given any two colors. The expectations for color contrast described by WCAG are rather detailed and lack developer ergonomics. Typed OM seems really well positioned to help.