Re: [csswg-drafts] [css-color-5][css-images-4] Are these features ready to ship? (#7310)

Hi Chris @svgeesus 

> _Thanks for the clarification regarding versioning and stability. In that case, please update your readme which gives a very different impression:_

Done. Thank you for pointing this out. And please let me know of any other concerns, misunderstandings, or rumors that have arisen here regarding APCA and related. 

### on ` color-contrast() `
> _However, regarding the substance of _this_ issue, it seems clear that:_
> 
> * _CSS Color 5 `color-contrast()` should continue to reference the WCAG 2.1 algorithm, flawed as it is, since that is the basis for current usage and is mandated in some legal contexts_

## _I can not agree._ 
If the WCAG 2 math is the only useable math at this time, then `color-contrast()` is not a useable function, and should not be advanced into use. It will have a damaging effect on accessibility.

### Not Fit For Purpose
The *only* reason that the WCAG 2 contrast math and SCs managed to stumble along for 15 years is that it is like "a broken clock is right twice a day" — pure conformation bias. A skilled designer is going to pick readable colors in the first place. If the "broken clock" says they pass, no one raises an eyebrow. And so it have been for 15 years.

But the FACT is that WCAG 2 contrast ONLY WORKS when the background is very light or white. Now with DARK MODE, gaining in popularity, the failings of WCAG 2 contrast are ever more clear. 

<img width="420" alt="DarkModeComparev2_2022 demonstrating that WCAG 2 contrast can not calulate for dark mode" src="https://user-images.githubusercontent.com/42009457/172025818-d755c059-889c-42e8-a4cf-5c57edbe0c15.png">



And if you take the eyes of the designer out of the equation by adding this function, then significant unintended consequences will result. A `color-contrast()`function using WCAG 2 math will happily create unreadable colors. And this is not good.

Here is an example: Each column WCAG 2 is the exact same contrast ratio from top to bottom.  Notice how as a color pair gets darker, that WCAG 2 contrast reports a passing grade for unreadable color pairs.

<img width="420" alt="ColumnCompareAll400 demonstrates how WCAG 2 contrast is not fit for purpose" src="https://user-images.githubusercontent.com/42009457/172025044-f372b662-4a19-40a6-9a0e-fc7cf7a6609d.png">

### Legal Questions
The claim that WCAG 2 contrast is "legally mandated" is not s persuasive reason to include a less-that-functional extension of a not-fit-for-purpose hand-wavy pseudoscience guideline.

I've examined the laws, and such a statement is misleading. In the US, WCAG 2 is NOT mandated by the ADA, nor is there any federal case law that makes such a holding (and note that Winn-Dixie was VACATED by the 11th district court).

In the US, the 508 applies to Federal-related entities only. And even here, the 508 has two important exemptions:

1) If something is not "commercially available" then it does not have to meet 508.
2) For any WCAG 2 SC, an "alternate" means may be used, so long as it provides equal or better accessibility.

This is not a _mandate_ to use WCAG 2, **it is a mandate to be accessible.**

This point is echoed in the laws I've examined in other parts of the world as well—even if they specifically mention WCAG 2 they have similar exception clauses. Beyond that I have gathered ample evidence proving that APCA provides better and more accessible contrast guidance, and APCA has been reviewed by third parties [see the review section here](https://git.myndex.com/#apca-peer-review--third-party-discussion).

AFAIC: It is **_legally negligent_** to continue to use methods that have been shown to be faulty when improved alternates are available.

If there remains an actual concern about being "backwards compatible" to WCAG 2, then there is [BRIDGE-PCA](https://www.myndex.com/BPCA/) which is entirely backwards compatible as a literal drop-in replacement for the WCAG 2 math. ` npm i bridge-pca `




## _Formal Objection_

### As a result, I object to the inclusion of `color-contrast()` until such time as an appropriate perceptually uniform math is used. Until then, it is negligent to allow it to be adopted as a usable function using WCAG 2 math.


## Regarding Integration
> * _another function could be added, for WCAG 3, rather than extending `color-contrast()`, because_
>   * _foreground and background need to be explicitly identified, rather than treated as interchangeable_
>   * _the font size and font-weight dependencies also need to be integrated_

Neither of these is true, and there exists versions that are a drop-in backwards compatible replacement for WCAG 2 math.

### _Explicit ID_
* Explicit identification already exists in CSS: it is `color:` and `border-color:` vs `background-color:` no further identification is needed.
    * On that note, the currently stated implementation has additional concerns in that (as I understand it) it requires listing both the colors? It seems to me:
        * A useful implementation would determine the adjacent color to be compared to intrinsically. e.g.:
        * ` color: color-contrast( 90 #ddd #222 auto );  `
            * In this case, the colors `#ddd` and `#222` would be checked against the color that is _**currently defined**_ as the backgrund color.
            * The result is using the first one in the list to meet Lc90,
            * And if none, then ` auto ` would provide either black or white, which ever is "best"
            * And ideally, if neither black or white achieves the needed contrast (a real consideration) then the relevant background color would be adjusted until the closest ( white or black ) did succeed.
        * ` background-color: color-contrast( 90 #ddd #222 auto );  `
            * In this case would look for the next element with ` color: `, or if none the next ` border-color: `
    * Otherwise, the current implementation does not solve any problem and only creates new ones.

### _Size and Weight_
* No, font size and weight does _NOT_ need to be integrated to _use_ APCA, as they are _**not**_ dependencies for the algorithm that generates the Lc value.
    * APCA only requires the stimulus color and the background color to generate the Lc value.
    * The Lc value perception curves are based on the maximum spatial frequency for the given contrast, as assessed by the contrast-matching experiments, meaning that stimulus consideration is integral.
    * The font size and weight are _conformance_ specifications, and they've always been separated to keep the function of the APCA Lc value calculation as simple, flexible, and integratabtle as possible.

### _Drop-In and Polarity_
Also, Bridge-PCA in "WCAG mode" ignores polarity if that is _really_ an issue (??) but as outlined it should not be. And further it should not be because if you are developing something NEW, then considering it is well known that there is a polarity difference in perception, then any new method should be considering that.

### TL;DR

**As proposed, `color-contrast()` is taking a rusty petrol engine from a Model T-Ford and crossing-fingers hoping it'll work in a Tesla.**

Also, I am at your disposal for answering any questions and addressing any concerns you may have regarding APCA or future guidelines in this area. 

Thank you for reading,

Andy

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


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

Received on Saturday, 4 June 2022 22:12:48 UTC