Re: [csswg-drafts] [css-color-5] Wide review (#7297)

Hi Chris @svgeesus 

In response:

> _removing color-contrast() from CSS Color 5_

This is really my main concern/suggestion at this time, that is, hold off until other documents catch up with useful guidance, in part due to issues with the expected time frames moving other things forward, in addition to the known deficits in the current recommendations.

> _deprecating the color-contrast portion of WCAG 2.1 and republishing the Recommendation_

There are issues with the charter preventing this, which is why APCA was moved to Silver/WCAG 3. There has been some informal talk regarding a WCAG 2.3, but that is not much more than conjecture at this point, and not any closer to a recommendation than WCAG 3.

Something worth mentioning, due to both an apparent demand, and the expected time frame of WCAG 3, APCA is also developing independently, towards a wider-scope set of guidelines. The W3/AGWG/WCAG3 version is ` apca-w3 `, the WCAG2 backwards compatible version is ` bridge-pca ` but there are other important applications for this, and therefore the broader scope considerations and development. 


> _helping drive APCA towards consensus_

I hope to have some positive news in this regard, relating in part to funding for a larger set of studies.


> _getting a normative reference to APCA added to WCAG 3.0 (currently it is just mentioned in passing, as a possible tool to use, and the mathematics of the calculation are not referenced at all)_

The current WCAG3 draft does specify "using an APCA compliant tool."  I was told at the time that the editors wanted the complicated technical information as a separate white paper.


> _creating a pair of functions (APCA does not treat text and background as identical, unlike WCAG 2.x):_
> _color-contrast-text()_
> _color-contrast-background()_

**_On this note:_** 
- it's possible for a non-polarity-sensitive iteration, giving up accuracy by splitting the difference.
    - A non-polarity version would probably be accurate to about ~±12%
    - The current simple pair-wise version is ~±5% accuracy
        - _(increasing accuracy further requires an input for total RMS page luminance)_
    - In comparison, WCAG2 contrast math error is roughly +150%/-50% over the range.
- Similarly it's possible to _improve_ accuracy by adding in a third, and possibly fourth, and fifth, color inputs (for the larger background, RMS page luminance, and ambient, respectively).
    - For simplicity, only a pair of colors are considered right now.
    - Adding in a third input is not too difficult (larger background if present),
    - though the fourth and fifth are non-trivial and not expected to ever be a part of guidelines. 
    - The point here is, it's a trade-off for functional usability vs accuracy.
- Regardless, I don't think having two functions is needed—all that is needed is that the functions are aware of what property is calling them.
    - If it is being called from ` color: ` or ` border-color: ` then it needs to evaluate against the current background.
    - if it is being called from ` background-color: ` then it then it needs to evaluate against the current ` color: `
        - In thinking over this, perhaps one other use-case is ` background-color: ` vs the larger ` background-color: ` -
            - the minimum contrast for low spatial frequency (large) items is very low, 
            - this might also pre-suppose the aforementioned three-way-inputs. 




-- 
GitHub Notification of comment by Myndex
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7297#issuecomment-1146856780 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Sunday, 5 June 2022 17:56:14 UTC