Existing examples are not useful to evaluate contrast formulas

[xi]

Split from #2 by @Myndex:

Your examples as chosen are all fairly high contrast using a bold font. This does NOTHING to demonstrate the differences. Your examples are mostly in the realm of "contrast constancy", and not near the edge.

Your examples are poor, using a bold font, and using high contrast, the result is that your examples are above contrast constancy, and therefore do not demonstrate the important differences.

[xi]

I must admit that I am not familiar with "contrast constancy" yet, so I will have to look into that.

In the meantime I can already explain how I chose these specific examples: I had a script that generated a bunch of color pairs and then filter for those where WCAG and APCA disagreed significantly. As you can see, with all of these examples WCAG and APCA disagree by one or (in many cases) even two thresholds. Of course the script generated a lot of very similar color pairs, so I picked the final set of examples manually from those results.

[Myndex]

Please read the following peer review, written by a PhD at Cambridge UK:

https://www.cedc.tools/article.html

And then, please view this conference paper in its entirely, given by a PhD Optometrist and Accessibility Advocate:

https://youtu.be/Da1Jmi7wgCY?t=3976

The link starts @ 1:06:20 @ 1:21:30 are comparisons, & APCA review @ 1:26:40

I must admit that I am not familiar with "contrast constancy" yet, so I will have to look into that.

Contrast constancy refers to the flattening of the CS curve at supra-threshold contrast at lower spatial frequencies, and the fact that above the curve there is an area where contrast appears the same except in comparison to an adjacent contrast.

On this subject, your statement regarding low spatial frequencies is incomplete. The 5-7 cpd you are citing is for sine-wave gratings. Text is NOT that, and has sharp edges, and therefore large text is a combination of both low and higher spatial frequencies (see signal theory and square waves).

For the record, for readability, the character size (x-height) of best readability is 0.2° to 2.0° of visual angle as subtended onto the retina. This is peer-reviewed scientific consensus, and actually, rather academic.

[xi]

I read the paper "Contrast constancy: deblurring in human vision by spatial frequency channels" (1975). Now I much better understand your last comment.

As far as I understand, the term "contrast constancy" describes the phenomenon that the impact of spatial frequency on contrast perception decreases as color contrast increases. The relation between color contrast and spatial frequency is commonly expressed by the "contrast sensitivity function" (or CS curve). But that function only describes the threshold under which a pattern is not perceivable at all. The authors describe that for higher ("supra-threshold") color contrast, spatial frequency has basically no impact.

So if I understand correctly you are saying that I should have picked examples near that contrast sensitivity threshold.

I don't agree with that criticism. With WCAG we are aiming well above "is this even perceivable". The sensitivity threshold is not relevant in that context, especially because we need some leeway to account for different viewing conditions and vision deficiencies. The relevant thresholds are the ones defined by the two approaches: 3/4.5/7 and 45/60/75. That's exactly what I did: I selected the examples with the biggest differences according to those thresholds.

So I don't think there is an issue here and will therefore close this. Feel free to comment if you have convincing arguments to reopen this issue.

[Myndex]

NO, more recent studies show that is not the case for very high spatial frequencies, you are citing a very old paper.

[xi]

Sure, very high spatial frequencies, say a 5px font size, will never be legible no matter how much color contrast you add. But as I said, we are aiming well above "is this even perceivable".

[Myndex]

No, please read the full documentation and also the relevant cites. I've cataloged everything at https://git.myndex.com

[Myndex]

Sure, very high spatial frequencies, say a 5px font size, will never be legible no matter how much color contrast you add. But as I said, we are aiming well above "is this even perceivable".

No. 5px can be readable by standard and better vision if properly rendered to a retina display.

The critical size for best fluent readability (standard vision) is a font about 16px to 18px, and this equates to font characteristics of ~14 cycles per degree in spatial frequency on a CS graph.

[Myndex]

This is issues is closed while not being addressed, and #18 was a a good faith attempt to get you to look at this again.

You are NOT comparing APCA.

You are NOT showing examples of APCA.

Your comparisons and examples are INVALID. While you claim to be doing an analysis, it is incomplete, misleading, or simply wrong.

The fact that you are ignoring this and continue to close issues and PRs without taking corrective action is a violation of the APCA license.

I have exhausted good faith attempts to get you to correct these errors.

Please Rectify

[xi]

The examples are using the APCA color contrast formula. Since https://github.com/xi/apca-introduction/commit/f43b4ccf7aafcd5d4cc3aefddb42fe3afebc0f51 they are also using labels like "> 45" instead of admittedly misleading conformance levels.

These examples are only about color contrast, not about spacial frequency. The APCA documentation clearly states that the look up table for font size and weight is optional (emphasis yours):

The APCA also has an optional lookup table to associate font size and weight to the readability contrast (Lc value). The lookup tables allow for even greater accuracy and therefore greater flexibility in design. -- https://git.apcacontrast.com/documentation/APCA_in_a_Nutshell

So I really don't see the issue.

[Myndex]

So I really don't see the issue.

You are being obtuse and disengenuous.

The APCA conformance levels indicate font size and weight, and you are ignoring those.

Perhaps you have not read the documentation? Or at least, are you just ignoring it??

CONTRAST is primarily a function of spatial frequency. NOT COLOR, and your spurious comparison is comparing only color and not spatial frequency AT ALL.

Here is a published article on the subject, you might find it informative: https://www.smashingmagazine.com/2022/09/realities-myths-contrast-color/

Again, your "comparison" here is either fallacious or ignorant — why is this the case? Who or what is motivating this? I have attempted multiple times in good faith to show you why and how you are presenting false and misleading information. You are doing a disservice, so what is your motivation? Who are you really? Are you also the user known as JAWStest?

[Myndex]

The proper visual examples can be seen at the corrected fork of this repo

[Myndex]

In betrügerisch absicht

Clarifying again:

These examples are only about color contrast, not about spacial frequency. The APCA documentation clearly states that the look up table for font size and weight is optional (emphasis yours):

The APCA also has an optional lookup table to associate font size and weight to the readability contrast (Lc value). The lookup tables allow for even greater accuracy and therefore greater flexibility in design.

The base conformance levels specify specific minimum font sizes. You are fully ignoring those. The "optional" lookup table is only an extension of the base levels. The lookup table is designed to allow for interpolation, mainly in automated design tools.

This DOES NOT mean the minimum font sizes and weights listed in the use cases and base levels are optional, and you are not permitted to ignore them because it suits your false narrative.

You are ignoring them, and therefore you are in breech of the APCA license.

Your visual examples are fraudulent. In betrügerisch absicht.

[xi]

I still don't understand the issue. I understand that there are minimum font sizes associated with the thresholds. But the examples are not about thresholds. They only say "this color combination has a contrast of X according to WCAG/APCA". Whether that contrast is sufficient of course depends on spatial frequency, but that is not what these examples are about.

I am really trying to understand the disconnect here. I looked at the examples in your fork again and realized that you used the same (small) font size and weight for all examples, so they are not following the different requirements for each use case either. Can you explain why you picked that font-size specifically?

[Myndex]

Can you explain why you picked that font-size specifically?

In the corrected examples, the font size is at or near THRESHOLD size and weight using the reference font for use case, the chosen font size is the “legal” size for WCAG2 or APCA or both, depending on the specific example. Size lookup table was not used because you did not provide for that in your code, so instead minimum levels were used similar to “bronze”.

Contrast is a function of the font weight more than color.

Contrast is driven by spatial frequency more than arbitrary color pairs.

When you use colors and weights that are deep into contrast constancy, then sure, you're not going to see that much difference. To understand the differences, you need to look near thresholds.

[xi]

I have two questions about your answer:

• The CS curve defines the relation between color contrast and spatial frequency at threshold, right? So as far as I understand, there should be different font sizes for different contrasts at threshold. Why is the font size the same in all of your examples then?
• Why is it a bad thing to have examples that are "deep into contrast constancy"? Is the issue that there are no other examples or is it wrong to apply APCA to those cases in the first place?

[Myndex]

Hi @xi I was just about to post a followup, then saw your question. Here's the followup I had written first, then I'll answer more directly after.

TO ADD:

I just reviewed the corrected examples I created. My intent was to be minimally invasive to the example script as you laid out, only changing certain key values to demonstrate the issues clearly. Because you did not vary font size, I only used a single size. I had no intention of rewriting your code.

The font used is a reference font at 14px and 400 weight (normal). For APCA, 14px is the minimum size for fluent text at Lc 90, as seen on the use-case matrix at the SAPC development tool site.

14px normal at 4.5:1 is part of WCAG 2 AA level, and 14px is a common size widely used today on the web (for better or worse). I’ve even seen some “accessibility advocates” using 11px normal for call to action buttons, and claiming they pass at 4.5:1 under WCAG 2, which as a sad fact, does pass WCAG 2 SCs.

Because you originally set up your demo/examples to use either black or white against some arbitrary color, I set it to use a font size at a reasonable threshold which is in common use, as this is instructive.

What is NOT instructive is choosing a font size and weight that is of a lower spatial frequency such that contrast constancy comes into play, earlier than it would in a real world example using a normally thin font.

The font size and weight you are using for your examples has a stroke of nearly 3px on a standard res display, and if you look as the CS curve (example in my Smashing article) you’ll see this is an order of magnitude higher in terms of contrast sensitivity.

---

Your specific questions:

It's not the size so much as the weight.

The CS curve defines the relation between color contrast and spatial frequency at threshold, right? So as far as I understand, there should be different font sizes for different contrasts at threshold. Why is the font size the same in all of your examples then?

There are different font sizes in MY actual examples. But if you mean your example that I corrected, my corrections where intended to maintain your apparent intent, and to be minimally invasive. And as you did not have the code developed for varying the size or weight, I simply set it to a "key size" as I mentioned above.

For reference, here is one of my actual comparison graphics, the font sizes here are close to thresholds. (Click for full size, nominal image width is 820 pixels).

Also, the CS curve we normally are looking at is at the JND threshold, but for readability, we are far supra-threshold, and the CS curve at supra-threshold changes, in that it flattens as a function of contrast constancy. As a result, very bold items fall into contrast constancy much sooner than very thin items. And if we are comparing color contrasts at levels needed for readability, then we are mainly interested in fonts about normal weight. Using bold therefore is not a useful nor instructive comparison.

Today, the readability problem that WCAG 2 appears to have caused, is the most pressing problem, and it manifests largely with the use of too small or too thin fonts. So your use of larger bolder fonts is specifically ignoring the major problem that the APCA and WCAG 3 guidelines are being developed to fix.

Why your examples are misleading

Why is it a bad thing to have examples that are "deep into contrast constancy"? Is the issue that there are no other examples or is it wrong to apply APCA to those cases in the first place?

Because once you are in contrast constancy, changes in the luminance distance are not functionally relevant. Similarly, once above the critical contrast level, additional contrast has no functional effect.

As a result, if all your comparisons are far above thresholds, so that they are in the constancy range, comparisons are not instructive, and instead are misleading or confusing.

But for guidelines, we need to know where the thresholds and critical levels are, because designers need a range of contrasts to create a useful visual hierarchy. And we need to model this with perceptually uniform methods so that automated color/design systems can do useful work without the supervision or intervention of a human.

My questions to you

Considering your motivations again

So again I ask, what are your motivations here? Are you intending to mislead and confuse the issue? Because from my perspective that is exactly what you are doing. This concern extends to the assertions you have made over the last two months that are patently false, and while they may be your opinion, you state them as if they are facts.

I've been working this problem for three and a half years at this point. You just recently popped up, and aside from a brief interaction in 2019, you have not been involved here at all, any other accounts you might be using notwithstanding.

At the main SAPC-APCA repo, you posted that you "could not find the formula" despite the fact that it is literally the first file in the documentation folder, and also embedded in the main documentation readme at the main repo, and the apca-w3 repos, and also in the white-paper drafts, among other places. Not to mention the code itself is plain vanilla javascript, and quite easy to read, and with verbose comments throughout.

So, your actions/statements appear as a red flag to me. It means to me that you did not really read the documentation. To be sure, documentation is a work in progress, but the information and bibliographies are all there, with multiple indexes or catalogs of the links to ensure the materials can be easily found.

There has been significant effort to write plain language introductions, such as "Why APCA" and "APCA In A Nutshell". These documents are intended to be simplified, and therefore intentionally do not discuss the actual formula, as the general audience is not at all interested in the actual math.

You are literally only the third person in the last three years that has ever indicated any interest at all in the actual math. The other two are a PhD at Cambridge UK while he was doing a peer review, and the W3's technical director while he was also doing a peer review.

I had originally posted the LaTeX of the math prominently, along with some of the theory, all front and center. But authorities at the W3 encouraged me to create plain language documentation which focused more on how to use, not the underlying functional theories. For this reason the math and theory were moved&kept in other documents, including the standalone LaTeX, made possible when GitHub adopted MathJax here.

The math is neither hidden, nor is it placed inappropriately in basic usage documentation where it would serve no purpose. It is right where it should be, in the documentation that covers the theory. The target users of APCA are designers and developers, not mathematicians and engineers, and the basic documentation is intended to reflect that. Nevertheless there is ample documentation targeted at mathematicians and engineers and vision scientists as well.

As such your criticisms that the math was "not where you wanted it to be" falls somewhat flat, as does the derisive tone you adopted in your "missing introduction" which serves to mislead rather than enlighten, as I have already discussed and presented as a pull request #11 -- your statement that you will not merge it due to formatting is weird, and not such a supportable conjecture.

Let's look at your rejection critically:

• You are/were not aware of the GitHub flavored Markdown syntax, which is what is used here at GitHub, including with the hotkeys.
  • _italics_ **bold** is the standard for GitHub flavored MD
  • italics bold
  • Underscore is not for underlining, it is for italics (emphasis).
  • Nevertheless, _ or * for italics becomes the HTML tag <em>
  • ** or __ for bold becomes the HTML tag <strong>
  • Command I adds _ and command B adds ** around the selected text, per GitHub standards.
  • Notice also that whitespace is collapsed, including in code.
• Whitespace is also collapsed when you hard wrap at 80 characters.
  • That hard wrapping is fully ignored, unless 4 spaces added at the eol.
  • Regardless, hard wrapping text should never be done, ever, as (among other things) in cases where the hard wrap is observed, it prevents correct text reflow.
  • This is an accessibility issue as well as a general typography issue.
  • It is correct to set col width at < 80 char, 50-60 is an ideal target for columns... but this should be done using the container width or margins/padding, never hard wrapping.
• In HTML text,   should always be used for a non-breaking space and never a UTF-8 character, and this is frequently discussed for best practices for HTML web content.

See this Gist for more on GitHub flavored Markdown.

That said, if those few trivial formatting issues are truly the only reason you are blocking the merge, I'll update those today, right now.

Best regards, Andy

[Myndex]

More for @xi

The CS curve defines the relation between color contrast and spatial frequency at threshold, right? So as far as I understand, there should be different font sizes for different contrasts at threshold. Why is the font size the same in all of your examples then?

As I said, I was trying to me minimally invasive to your intent. But as you asked, in the most recently PR #20 I added code to work with a variety of font sizes, from 32px bold down to 16px normal. This really drives home the concept, I probably should have created this sooner.

And PR#20 also adds the formatting fix requests (i.e. using * instead of _)

[xi]

I think my first question is answered, and I understand (and appreciate) that you used the same font size in order to be minimally invasive.

I am not quite sure yet whether I understand your answer to my second question.

The examples use a font-size of 120%, which equates to 16.8px in my setup. I believe most setups use a base font size of 16px, which would result in 19.2px for the examples. According to the APCA lookup table, this gives us a minimum contrast values somewhere between 43 and 60. Some of my examples are in that range, some are below, and some are above. On the other hand, if I were to use 14px and normal weight, the minimum contrast would be 100, so all examples would fail. I don't see how that would be better.

Regarding your other remarks: I would be happy to discuss them, but this issue is complicated already and I would like focus on a single topic at a time. Can you please make comments in the relevant issues (#11 and #13)?

[Myndex]

Hi @xi

...if I were to use 14px and normal weight, the minimum contrast would be 100...

That actually depends on the conformance model and use case. The public facing APCA tool at Myndex is intentionally "extra strict". This was done because there were a few very bad implementations that were incorrect in presenting APCA, and resulted in unfortunate controversy. I've spent much of the last few months getting them taken down, and I'll only mention in passing that this is partly why I am sensitive to APCA being wrongly implemented.

There is the SAPC research tool which has a use-case matrix, where you'll find a greater variety of "minimum cases."

...I believe most setups use a base font size of 16px...

The base body font size at GitHub appears to be 14px for desktop/laptop. BUT

It is not the SIZE that I object to, it is the WEIGHT.

The critical spatial frequency modulator as it affects contrast perception is the font weight. Size is the factor for acuity more than contrast per se, but size affects contrast in that it affects the rasterized stroke width for the given weight. This is followed by glyphs design characteristics, then letter and line spacing in terms of spatial frequency importance.

Contrast Arising from Text Spatial Frequency

Order of importance:

1. Weight (normalized per reference)
2. Size (normalized per reference)
3. Glyph (i.e. serif, sans, aspect etc. strongly interrelated to weight and size)
4. Letter spacing (kerning and tracking, relative to glyph characteristics)
5. Line spacing (leading, relative to x-height for Latin writing systems)
6. Justification (aligned to entry point, I.e. for L to R, aligh left)
7. Other layout and contextual factors have various levels of importance, depending.

Therefore

You can not use a larger BOLD font and hope to honestly demonstrate the functioning of a visual contrast metric.

The typical font weight used for readable body text today is usually 400 or less, some poor designs as thin as 200. The thresholds for columns of body text are the most critical, and therefore form the key nexus point for readability guidelines.

It is for this reason that the APCA tool uses blocks of sample text for demonstration purposes.

Using larger and BOLD font for your examples shoves the spatial frequency so far down the CS curve, it approaches or is in the contrast constancy zone. Using contrasts in the contrast-constancy zone for comparisons is spurious and meaningless. We literally do not care about measuring contrast once we are above critical contrasts. But we DO very much care about contrasts near the critical point for a given use case.

IIR, the bold font you were using was lower than 8cpd (per stroke width). The spatial frequency band we are most concerned with is about 16cpd to 24cpd. If we assume a normal weight font x-height is 2.5 cycles, then these spatial frequencies relate:

• At a frequency of 24cpd that is 6.25 arc minutes or an 8px x-height. (About 15.5px Helvetica or 14.5px Verdana)

• At 16cpd, that is 9.4 arc minutes or 12px x-height. (About 23px Helvetica)

• The consensus (Legge et alia) on "best fluent critical size range" for text is 0.2° to 2.0°, and 0.2° equates to an x-height of about 9.4px, (7.4') which is roughly an 18px font (Helvetica).

In my revised version of your examples, where I added in font size, the sizes used are 32px Bold, which is well into the contrast-constancy range, roughly 7cpd, then 24px, 18px, 16px, 14px, which are roughly 15cpd to over 26cpd. (But please note that actual font layouts are not a simple spatial frequency, but fairly irregular—here I am rounding for simplicity and illustration purposes.)

At threshold, the CS curve indicates that the difference between 20cpd and 7cpd is an order of magnitude in terms of contrast sensitivity. 30cpd to 15cpd is also an order of magnitude in contrast sensitivity. In other words, this implies that the difference between 24px and 14px is 14px results in 10 times lower contrast sensitivity than 24px. And this is not considering the acuity issues.

The reality is much more nuanced and complicated, and simple linear math is not entirely accurate here, but as a thumbnail understanding, it serves the purpose.