Re: [csswg-drafts] [css-color-6] `contrast-color()` syntax proposal (#7954)

Hi Adam @argyleink 

> *This proposal intends to empower the prefers-contrast media query*

I just came across this thread, I am here to answer any questions that might come up or to provide assistance.


As I think you are aware, user personalization is the most important thing that can be done for accessibility. If _**real**_ effective user personalization can be had, then many other concerns about accessibility become very secondary or even moot.


As such I've been considering some of the needs that could potentially be addressed by appropriate media queries, such as prefers contrast or theme, etc.

## Conflicts of Needs

One issue is that what one user needs, another user may find harmful or interferes with their needs. Visual presentation is probably one of the more complicated and common situations where this issue is present.


There are easily 10 basic themes or contrast modes, I put the supporting minutia in the spoiler.
<details>
  <summary>Visual Needs/Themes examples</summary>

In an ideal world, the user's environment or at least the entire screen luminance would be taken into consideration.

As well, the use-cases relating to tasks, i.e. reading long form material, or interacting with forms, have two different needs in terms of contrast and presentation.

Some arguably useful luminance and contrast themes:

Dark Mode for dark environments
Dark mode for light environments 
Enhanced contrast for dark mode

Light mode for bright environments
Light mode for dark environments
Light mode for the paper reading experience
Enhanced spatial contrasts (i.e. weight increase)

Luminance contrasts relate to readability for all sighted users, color (hue/colorfulness) relate to distinguishability and discernibility.

Reduced color (hue/chroma) contrast (without reducing luminance contrast)
Daltonized palette (deutan)
Daltonized palette (protan)


### _Reading_
Luminance contrast is critical for visual readability for all sighted users.

Excess brightness as in too much luminance relative to the eye's adaptation state in their environment leads to rapid eye fatigue. This is an emerging problem with people that are using HDR displays.

"Too much contrast" is a complaint given for what is actually excess brightness.

Reducing contrast with a bright background by making the text a lighter gray is exactly the _opposite_ correction needed. More: ["Please Stop sing Grey Text"](https://tangledweb.xyz/please-stop-using-grey-text-3d3e71acfca8)

</details>
10 different modes is far too much to ask an author to provide, what is needed is  automated theme variations, such as creating a Daltonized palette.

Automated color palette development requires perceptual uniformity in whatever model is being used.

----
Hi @bramus + @argyleink 
>> _which could then be expressed as wcag3(75, font-size, weight)_
> _engineering made it sound like they could derive that as they needed and wouldnt require authors to pass it explicitly to fulfill the algo._

You definitely **do not need** to send APCA the font size and weight. 

If you have one color, you then only need a target Lc value (lightness contrast) to determine the needed second color.

If you don't have an $L^C$ value in mind, you can use font size & weight of the reference font to determine the needed $L^C$ value.

<details>
  <summary>Lc, Weight, and Size</summary>

In other words, if you have one color, with font size and weight, then you can determine the second color. Or if you have one color and an $L^C$ value you can determine the second color.

However, for font size & weight to really work, we need to have a reliable way to set x-height directly, and a reliable way to determine a font's actual weight since there's no standardization here. 

This is something that we're working on, but it's not something that's gonna be happening anytime soon.
</details>

----
Hi @tabatkins 

> ..._almost certainly far too dangerous to allow an auto algorithm, except maybe if it was restricted to only giving black/white._

I agree that automatically selecting some algorithm is fraught with a lot of unexpected behavior. A black and white font flipper could work, but you don't need much of an algorithm for that.

You can pretty much convert to luminance and flip between black and white at  $37\ Y$  I discuss this at the [FancyFontFlipping repo](https://github.com/Myndex/fancyfontflipping)

----
Hi @argyleink 

> _the more that folks will use cielab to estimate L* differences for contrast._

**Unfortunately** $∆L*$ **is no improvement over WCAG 2.x.** Both $L*$ and WCAG_2 put center contrast at `#777777`, and that is **_not_** the center of contrast. 

I was working with $∆L*$ early in 2019, and found it provided no benefit on its own, however much of that work lead directly to developing SAPC which then developed into APCA.

The tangent is DPS contrast a.k.a. Delta Phi Star, which uses $L*$ as the starting point.


### Summary

I hope this post was useful please ping me if you have questions.


Thank you for reading



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


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

Received on Wednesday, 25 January 2023 09:09:57 UTC