Feature Request: Don't clamp low contrast values to 0

[NateBaldwinDesign]

Don't clamp low contrast values to 0

Is this about a tool (you're an end user) or about a code library (you're a developer)?
This is about a tool that I maintain for other people's code libraries.

Does this relate to a problem with using a tool or implementing code? Or is this something that would help expand use and application?.
This feature request pertains tho the flexibility my tool provides its end users, which provides a paradigm shift in the color generation process to be focused on targeting contrast values.

How do you think it would be best implemented?
Recommend to remove clamping that reduces any low-contrast value to 0 (ie, values less than 7.5 appear to just drop to 0).

Have you considered other alternatives?
Alternatives don't really make sense when the objective would be to extend APCA contrast values into the lower-end values. I would like to rely on a single formula for calculating contrast across-the-board.

Additional context
Why would we not want to clamp those values to 0? While I can understand the basis for APCA is primarily for text legibility, what it offers is much broader than that alone. Text at an APCA contrast of 4 may be completely impercievable, but that degree of contrast may be very desirable for something like a subtle background (such as the various shades of gray you see on this github page).

In terms of my specific use case, the tool I maintain provides a mechanism for web appilcations to offer end-users personalization of color including the ability to increase or decrease contrast of the entire user interface. This objective aligns with future ideals for inclusivity in design; where we can acknowledge that no sighted user will see an interface in exactly the same way. However it is not only text that needs contrast adjustments; all elements of the interface may need uniform adjustment based on individual user needs, environmental settings, etc.

How would this feature effect the future standard? I don't believe this has any impact. Clamping low-contrast-values to 0 reduces the amount of measurable colors a designer can use. Having guidelines that specify exact contrast value minimums already takes care of any issue of "what can/can't be seen" regarding text. This feature would not take anything away from the purpose and obectives of APCA / WCAG contrast calculations and guidelines, but it would offer better functionality support and flexibility for designers and developers using it.

[Myndex]

There are a few reasons for the clamp, and one is simplicity, as anything below Lc 10 is not needed for WCAG 3 guidelines, and as contrast values descend below Lc 15, there is a perception shift that requires an extension to the formula. The apca-w3 version uses the clamp, again for simplicity.

There are some different versions, and differing license statuses, that include extensions or adjustments to the base method. There is one that I'd call "okay for 8 bit use" that is the code at the SAPC research tool. Let's discuss further—there are also some opportunities for beta/private beta that includes some unreleased goodies, NDA required for now...

[ichik]

I want to voice my support for the removal of the clamp. I'm currently working on a generative color theming solution, that generates content, border, and surface colors from a starting seed color. From a practical point of view, there is a difference between true 0 and e.g. 4.3 when trying to determine the visibility of a button surface against the application surface.

[Myndex]

I want to voice my support for the removal of the clamp.

Just to be clear, the clamp can't simply be removed, it needs to be replaced with an "easing" into lower contrasts (the clamp allowed simplifying the perceptually uniform math for the important range between Lc 15 and Lc 90, done as several individuals are still claiming that it's all too complicated).

There are a couple different versions of this, the low-end extension that's publicly available right now under a non-commercial license is at the SAPC site.

[Myndex]

Also to point out something that I've mentioned in the past, the public-facing versions of APCA are designed first for text contrast and therefore have a modest contrast boost with darker color pairs. We have alternate curves with true uniformity across the entire range (which also varies based on context), to avoid confusion, and promote simplicity, they are not being publicly presented right now.

If there's interest, I'm thinking we might exercise those and present them under SAPC or another acronym perhaps?

[NateBaldwinDesign]

I would very much be interested in this, especially learning the differences between them. Your statement about APCA being primarily text-centric makes me wonder about its use relative to WCAG criteria for non-text elements— ie, is it appropriate to use for component contrast, such as borders of a text field or a solid colored button against the background. Would this mom-text formula be better suited there as well?

I would almost expect them to have the same acronym with a modifier, like APCAtext and APCAnontext (but I'm well aware these are poor suggestions, just directional).

[Myndex]

Hi @NateBaldwinDesign

Assuming standard screen distance:

When the smallest part of an element is about 4px thick or greater, we're close to peak luminance contrast sensitivity, and get into contrast constancy-land.

As an element gets thicker than 16px, then color, as an hue and chroma, contrasts begin to equals or exceeds the strength of luminance contrast.

The implication here is that a more complete definition of non-text contrast is often going to properly include hue and chroma or saturation, while text elements intended for readability will remain tied to luminance contrast.

The current non-text SC 1.4.11 is pretty far off-base as to what the needs of non-text contrast actually are—but I'm gonna stop there before I go into a rant, lol...

[angyb]

Throwing in my 2 cents: If you're able to tell me the contrast of my very light color with a black foreground, I want to know the same against a white background.

You can see from these pictures that #FFF5F5 is approx. Lc 4.6 (106 (for black/white) - 101.4 for (black/#FFF5F5) = 4.6).

I, too, am using a generative color theming solution (Leonardo.io), that generates my entire ramp of colors from a starting seed color. The lowest Lc it will produce is 7.5, but I need 5.0. I have to go to a lot of work to find the Lc5 for all the colors in my design system. And then it's not programmatic anymore; these are manually adjusted colors that are very time-consuming to produce.

Leonardo.io example of my ramps

Note how my color ramps increase in steps of Lc5. I want my lightest color to be Lc5 and I can't get there from here. I have to reverse engineer the color by comparing it to black and subtracting rom 106, to get an approx. APCA Lc of 5.

Just wanted you to better understand the use case for why designers are requesting you de-clamp the light colors. We need those very light colors for non-semantic backgrounds.

[Manueljlin]

I'd also love to see additional guidance under SAPC (or APCA with a general ramp) for UI components like buttons, containers etc. as a complement to perceptual color spaces like JzCzhz or OKLCh, since the viewing conditions as you've mentioned are quite different from the ones used in the color space research 😄