Hi @Myndex,

I'm testing a local implementation of APCA using APCAonly.98e_d12e.js. I have a test suite with the four test cases you have illustrated here: https://github.com/Myndex/SAPC-APCA/tree/master/JS#testing-your-implementation

However, my results do not match the expected results you've posted. I have tried transposing colors (assuming perhaps I had erroneously placed the text/background colors in the incorrect order). I am wondering if the test cases are incorrect, or if there's something I am missing?

Example of test case running locally:

test('should provide APCA contrast for first test case', function() {
  let contrastValue = APCAcontrast(0xfff, 0x888);

  expect(contrastValue).toBe(66.89346308821438);
});

Result of test:

 Expected: 66.89346308821438
 Received: 11.399627561736908

Using typescript can help understand at a glance what the function will require and output.

The function that calculates the minimum px per weight instantly concatenates with html, please separate.
If I understand correctly it would be

minPixel(lc: number, weight: nummer): number
minPixelToHtml(minPx: number): string

Hello.

I'm very much excited by the APCA contrast, and am looking to start using it.

Now the contrast calculation is situation-aware. That is, it differentiates between the text color and the background color.

However, how should one calculate the contrast between foreground objects? I'm currently looking to make accessible data visualization. So, I want to check if differently colored slices in pie chart can be recognized, for example.

Thank you in advance.

First, thank you very much for your ongoing work on color contrast.

I am confused about the definition of the APCA/SAPC contrast values, as the available articles seem to contain contradicting information. The calculators show Lc values, but the wiki page https://www.w3.org/WAI/GL/task-forces/silver/wiki/Visual_Contrast_of_Text_Subgroup talks about percentages. Also, on that page, #0A0 on #000 is said to have "-80% contrast". However, the APCA calculator gives an Lc value of -47.88, and the SAPC calculator a value of -44.54.

Could you please clarify if the Lc values and percentages are identical, or maybe represent different versions of the algorithm?

Also, how is the contrast reference of 100% defined?

I understand that everything is a work in progress and documentation is incomplete, but I think even a very short introduction at the top of the GitHub readme including a definition of the contrast values would be very helpful.

Using the apca-w3 NPM package, version 0.0.98-g-4g.4b does not match the result calculated with the online contrast checker at https://www.myndex.com/SAPC/.

For example, the following code:

import { APCAcontrast, sRGBtoY } from 'apca-w3';
console.log(sRGBtoY([255, 151, 198, 1]));
console.log(sRGBtoY([113, 45, 68, 1]));
console.log(APCAcontrast(sRGBtoY([255, 151, 198, 1]), sRGBtoY([113, 45, 68, 1])));

Returns

0.4553507281777737
0.04431087650514489
-52.260847224115004

In contrast, in the tool at https://www.myndex.com/SAPC/,
Plugging in #ff97c6 as the text color and #852d44 as the background color results in:
Y: 47.4748 for #ff97c6
Y: 7.28211 for #852d44
Contrast: -49.236

Is there any reason for this difference?
Am I misunderstanding the use of the API?

Thank you in advance.

Many research ventures that build tools (especially those based on existing empirical models) will validate their tool not just based on how well it performs against other models (which APCA does well) but also what practitioners think when using the tool.

I don't see validation studies for APCA and I think that if this is done as soon as possible, it could help improve APCA to be as simple and usable as possible. I really believe in this project, but there could be a chance to study and improve how it is used.

The plain English version is really great! As a starting point, perhaps bring in expert accessibility analysts and have them use WCAG 2.x contrast calculator (as a control/comparison) and then have them use APCA. This will be a great chance to gather thoughts about what could be improved/etc (like from a qualitative empirical perspective at the bare minimum). This is also a chance to put some research out on APCA (as a beta/prototype).

Since WCAG is primarily a document that gains its power from international political consensus, convincing political bodies that APCA is easily usable by practitioners is important. This study will go a long way in making the case that it should be in WCAG 3 and that WCAG 3 should be the new policy standard.

If you need research resources, perhaps there is an opportunity to connect and collaborate on this.

Describe the bug

In fontLookupAPCA() from apca-w3, a contrast less than 5 returns 500, 600, 700, 800 and 900 instead of 999

To Reproduce

for (let i = 0; i < 6; ++i)
  console.log(fontLookupAPCA(i).join(', '));

0.00, 999, 999, 999, 999, 999, 999, 999, 999, 999
1.00, 999, 999, 999, 999, 500, 600, 700, 800, 900
                          ~~~  ~~~  ~~~  ~~~  ~~~
2.00, 999, 999, 999, 999, 500, 600, 700, 800, 900
                          ~~~  ~~~  ~~~  ~~~  ~~~
3.00, 999, 999, 999, 999, 500, 600, 700, 800, 900
                          ~~~  ~~~  ~~~  ~~~  ~~~
4.00, 999, 999, 999, 999, 500, 600, 700, 800, 900
                          ~~~  ~~~  ~~~  ~~~  ~~~
5.00, 999, 999, 999, 999, 999, 999, 999, 999, 999

Expected behavior

All values should be 999.

Additional context

The bug is here: https://github.com/Myndex/apca-w3/blob/master/src/apca-w3.js#L571 which selects index 0 corresponding to a header.

  const factor = 0.2; // 1/5 as LUT is in increments of 5
  const index = (contrast == 0) ?
                 1 : (contrast * factor) | 0 ; // LUT row... n|0 is bw floor

The formula should probably look like

  const index = Math.max(1, (contrast * factor) | 0); // LUT row... n|0 is bw floor

Or else everything is out of sync and it should be

  const index = ((contrast * factor) | 0) + 1; // LUT row... n|0 is bw floor

This does not happen using APCAcontrast since the minimum value returned is greater than 7.3 and less than -7.3.

There is a lot of explanation why a better contrast formular is needed and how it can be used, but I have not yet found the actual formular. I would have expected it in "APCA in a nutshell". I would also have expected to get a reference implementation in an easy to find file (I guess it exists somewhere in this repo, but I was not able to find it yet).

Does this relate to a web app or tool (i.e. you're an end user) OR is this about code or code integration (you're a developer).

Regarding deployed version of APCA Contrast Calculator.

Describe the bug
SSL cert for www.myndex.com expired on Sunday, June 25th 2023.

To Reproduce
Visit https://www.myndex.com/APCA/

Screenshots redacted

Thanks for this really useful project.

I noticed in the source that the license is AGPU v3. Am I right in thinking that this should be AGPL v3?

I am unsure which parts of APCA are actually influenced by which empirical studies. It would be really helpful from a scientific standpoint to know this information and have it readily available either in the repo, documented in the code as comments, or main site for APCA.

I found a list of papers here, akin to a bibliography:
https://www.w3.org/WAI/GL/task-forces/silver/wiki/Visual_Contrast_of_Text_Subgroup/Resources#Key_References

But these don't seem to point to specific parts of APCA. It is very difficult to figure out which studies influenced which parts of the model without reading every study and examining the model. In academic science (for example), typically models are rigorously documented. Perhaps progress towards this work can be used to develop the methodology section of a research paper? (As a way to maximize the labor involved in this project, since I assume there will be a paper eventually.)

In particular, knowing which empirical studies influenced which parts of APCA will:

• Help generate trust in the model's rigor
• Provide opportunities for scientists/practitioners to improve parts of the model or contribute
• Help scientists/practitioners recognize potential gaps or unaddressed areas (such as text outlines/etc)

This addition to the growing body of materials will really help drive consensus towards adopting APCA (not just consensus among the academic community but political and practitioner spaces as well).

Does this relate to a web app or tool (i.e. you're an end user) OR is this about code or code integration (you're a developer).

This relates to the https://www.myindex.com website

Describe the bug

The website https://www.myndex.com, containing the APCA calculator web app, has an expired TLS certificate. The certificate expired on the 24th.

To Reproduce

Visit https://www.myndex.com/APCA/ in a modern browser, or run curl https://www.myndex.com/APCA/.

Expected behavior

The website loads.

This behavior is device- and OS-independent; it appears in any correct implementation of webpki.

I'm doing some evaluation of Material Design's standards around high-emphasis and medium-emphasis text. If you're unfamiliar, the spec uses rgba to allow the same css styling to scale along with background colors. e.g. a white text with .87 opacity will render as a lighter grey as the background color lightens. This helps developers use one style across many backgrounds and still maintain contrast (up to a point).

Under WCAG 2.0, the medium-emphasis style (.6 opacity) would pass AA or AAA for small text, but it pretty marginal under the newer proposed specs. I've attached a graphic showing findings. Each panel has:
Material Design style | WCAG 2.0 ratings (small, large), APCA%
Text color (including opacity) | Background color | renders-as color (actual output of computed rgba rendered on background)
Recommended usage guidelines
(note that "all" is misleading - this check is only intended for the scope of body text styles, so we're not talking about weights <300)

I was surprised to see that the Medium Emphasis styles (right column) that passed AA or AAA under WCAG 2.0 are more marginal under the proposed new spec. My understanding was that light text on dark backgrounds was being under-rated in the old spec, but these findings seem counter to that idea.

So I guess the "issue" is more of a question: am I doing these test correctly, and are the results as expected?

I am attempting to write a custom implementation of APCA contrast calculation.

I was reading the plain English steps in the README.md, and came across the following description for the step of soft-clamping the color.

• Soft-clamp the colors but only if it is less than 0.022 Y

  "colors"(plural) implies that this operation should be done on both colors being compared

• Then add that result back to the Y of the darker color

  Here, the direction sounds like the clamping is only supposed to be done for darker of the 2 colors.

Should the soft-clamping be performed on both colors, or just the darker of the 2?

Thank you in advance.

I am trying to implement the APCA contrast algorithm into my PHP color library, and am trying to figure out what you're trying to do in your sRGBtoY function.

What it looks like you're doing is that you're converting from sRGB to CIEXYZ D65 (because you're not doing chromatic adaptation, and the sRGB input color is D65) but only using the Y lightness channel. However, when you do inverse companding you're not using the sRGB inverse companding algorithm but something like what other RGB profiles use (you don't max to 0 if negative and min to 1 if above 1 though) except with sRGB's 2.4 gamma (for the purposes of companding) instead of 2.2. For instance, if I feed your function 0x662d91 I get 0.05333370870294055 back for Y when if it used sRGB's inverse companding it'd be 0.06746021917230773.

function sRGBtoY (sRGBcolor) {
                  // send 8 bit-per-channel integer sRGB (0xFFFFFF)

  let r = (sRGBcolor & 0xFF0000) >> 16,
      g = (sRGBcolor & 0x00FF00) >> 8,
      b = (sRGBcolor & 0x0000FF);

  function simpleExp (chan) { return Math.pow(chan/255.0, mainTRC); }

		 // linearize r, g, or b then apply coefficients
		// and sum then return the resulting luminance

   return sRco * simpleExp(r) + sGco * simpleExp(g) + sBco * simpleExp(b);
}

Above is what you have now, but if you were to use sRGB's inverse companding it'd be like this:

function sRGBtoY (sRGBcolor) {
                  // send 8 bit-per-channel integer sRGB (0xFFFFFF)

  let r = (sRGBcolor & 0xFF0000) >> 16,
      g = (sRGBcolor & 0x00FF00) >> 8,
      b = (sRGBcolor & 0x0000FF);

  function simpleExp (chan) {
      chan = chan / 255.0;
      return (chan <= 0.04045) ? chan / 12.92 : Math.pow((chan + 0.055) / 1.055, mainTRC);
  }

		 // linearize r, g, or b then apply coefficients
		// and sum then return the resulting luminance

   return sRco * simpleExp(r) + sGco * simpleExp(g) + sBco * simpleExp(b);
}

Is there any particular reason for this?

• Maybe replace AuxTextgadby with Sample or user choice?
• Please file bug w/ Google wrt Chrome rendering of Jost font.
• How much work would it be for people to pick there own fonts for testing? Of the 11 you provide samples, I have only used one (Helvetica Neu), and I would not use that one a web site.

Hello there, thank you for all the work that you do in the color space.

I and my partner at Protean Studio are currently putting together a demo of the APCA as a general resource and I want to be sure that we are accurate and provide appropriate attribution. The goal of the demo is to show how color combinations score on the WCAG 3.0 scale with a live version of the lookup table and some samples; we are using the method in APCAonly.98e_d12e.js as a base with the updated constants.

How would you like us to provide attributions to you and the others involved in the research? To be clear, we have no intention to monetize this work.

Please let me know if there is any information that you would like us to highlight and if you have any reservations about this project.

Thanks,
Abdul

We are trying to provide a better UX in our charting library and we are facing some issues when we need to choose automatically the more readable text color when we need to render a text over a chart geometry (bar/slice).

We used the WCAG 2.0 color contrast code to determine the contrast and choose if a pure black or a pure white obtain the right color but there are always some cases where we haven't reached good results.
I've finally found your research and, since it will be applied to WCAG3, I'm really interested in testing it.
I've used your code and played a bit with various versions of the coefficients but I'm getting a strange result when the background has a particular pink/purple hue like #CC69FD

With APCA, the white text (-61) has better contrast than the black one (48), which is completely the opposite of the WCAG 2 contrast (2.9 for white, 7 for black)

I've also checked the white on purple contrast using your CDV simulator and the white text on the purple background get's completely unreadable with Monochromat (Blue Cone), Missing L & M cones (no red/green) where the black over purple still readable in most cases

Is there any specific reason for that huge difference? I know that the argument is very complex but I was wondering if there was something I can do to improve the text contrast under similar conditions.

What happened to the license file?

Was thinking about a small comment from a Microsoft design talk I attended years ago, in which the speaker mentioned slight background gradients on elements improved perceived contrast for text. Examples of visual illusions were used to demonstrate changes in contrast.

Checker board classic

If I enter 980000 in either field, the resulting color is wrong.
Generating a unique URL shows me that it's actually showing 989898 color.

It seems that the R value is duplicated when G and B are 0

Accessibility issues with APCA web tool

This is not so much a specific accessibility bug, but pointing out how the tool is currently built doesn't conform to correct (semantic) usage of HTML which will cause problems for users of assistive technologies and those who rely on keyboard navigation, for example.

Does this relate to a web app or tool (i.e. you're an end user) OR is this about code or code integration (you're a developer).

I've only looked at the APCA web tool.

Describe the bug
Improper use of HTML which leads to accessibility issues.

To Reproduce
Steps so we can reproduce the behavior:

N/A

Expected behavior
What were you expecting as correct behavior?

Correct / semantic usage of HTML.

Screenshots
Add screenshots or code snippets to help explain your problem.

System or device information (please complete the following):

• Device: [e.g. iPhone6 or iMac]
• OS: [e.g. MacOS]
• OS version
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

N/A

Additional context

I'd recommend reading this MDN article to learn how to better structure your web apps with HTML. For example, clickable elements should generally be <button> and not <span>; HTML <table> should be used for representing tabular data, not for UI layout, etc.

You may also want to use Deque's accessibility tools to find specific accessibility problems.

@Myndex this table is very helpful if you come to the problem with the question of "What font sizes and weights can I use for this foreground/background color pair?"

However, it's not very clear how an inverse of this would be resolved -- "What contrast value do I need to meet for text of font-weight X and font size Y on background color Z"? On top of that, I see there are also "Levels"/"Scores", so it would be nice to inject that variable into the same question --* "...and for score level 5"*.

Is that logic, or the table of requirements already somewhere in this codebase? The text version of the lookup table isn't much more helpful, since it doesn't specify score level ranges.

Here's an example use case for what I'm trying to accomplish:
As a designer, I have already chosen a background color for my application (#f5f5f5) and a typography scale (14px, 16px, 18px, 22px ...). I also support font weights of 400, and 700. For each of these combinations, I would like to run a simple function such as:

function APCAContrastValue(fontSize, fontWeight, backgroundColor, scoreLevel) {
    // look up table?
   return contrastValue;
}

For example:

var desiredContrastValue = APCAContrastValue('14px', 400, 0xf5f5f5, 5);
// returns 100

Please enter a descriptive title.

Does this relate to a web app or tool (i.e. you're an end user) OR is this about code or code integration (you're a developer).

Describe the bug

In this documentation
https://github.com/Myndex/SAPC-APCA/blob/master/documentation/APCA_in_a_Nutshell.md#use-case-ranges
it is states that:
Lc30 should be “no less than 4px solid in its smallest dimension.”
Lc15 “is no less than 6px (solid) in its smallest dimension” 

This document as well says the same for Lc15
https://github.com/Myndex/SAPC-APCA/blob/master/documentation/WhyAPCA.md
Lc15 “is no less than 6px in its smallest dimension”

Whereas on this page: https://www.myndex.com/APCA/, under APCA Guidelines: Bronze Level, it states:
Lc30 should be “no less than 10px in its smallest dimension”
Lc15 “is no less than 15px in its smallest dimention”

To Reproduce
Steps so we can reproduce the behavior:

Expected behavior
The same correct values on all pages.

Screenshots
Add screenshots or code snippets to help explain your problem.

System or device information (please complete the following):

• Device: [e.g. iPhone6 or iMac]
• OS: [e.g. MacOS]
• OS version
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Additional context
It would be helpful if minimum widths were listed for Lc45, 60, 75, and 90, as well. For example, which Lc should a 1px form field border be vs. a 2px border?

This is about the following section:

• For simplicity, you can also use the “simple key levels” method (Lc 45, 60, 75), which compares to WCAG 2 contrast (with one very light color) as:

  • Lc 45 is “sort of” like 3:1
  • Lc 60 is “sort of” like 4.5:1
  • Lc 75 is “sort of” like 7:1

The web tool makes no mention of these "simple key level". Instead it defines the levels "bronze" (use cases that consider spatial frequency) and "silver" (look up table based on spatial frequency). The "simple key levels" on the other hand do not consider spatial frequency at all.

These "simple key levels" are attractive for people coming from WCAG 2 because you don't have to learn a lot of new concepts. I certainly fell into that trap. But if I understand correctly, these levels are not actually recommended.

So I believe the "simple key levels" do more harm than good. I therefore propose to remove them from the documentation.

Is this about a tool (you're an end user) or about a code library (you're a developer)?

Yes. I already have RGBA arrays for my colors, so I don't need colorparsley in the APCA algorithm, but the library forces me to bundle it in. Would love an alternative calcAPCAFromRGBA that does the same thing but doesn't call colorparsley, so that I can avoid bundling the library when I wouldn't actually use it.

Does this relate to a problem with using a tool or implementing code? Or is this something that would help expand use and application?.
it would just reduce bundle size by a few kb.

How do you think it would be best implemented?
super easily, i can shoot out a PR.

Have you considered other alternatives?
I was thinking about packaging my own version of apca-w3 that has all the goodies I'd like (written in typescript, a somewhat simpler API, convenience helpers) but the license on this repo is confusing to a mere web developer like myself so I'm not sure what's OK and what isn't.

Additional context

Does this relate to a web app or tool (i.e. you're an end user) OR is this about code or code integration (you're a developer).
Web app

Describe the bug
When visiting https://www.myndex.com/APCA/?BG=023e1f&TXT=509d75&DEV=G4g&BUF=A22 sometimes this results in an invalid response (see screenshot)

To Reproduce
This happened the first time i visited the URL in chrome. then it started working consistently. I tried opening an Incognito window and it happened again.

Expected behavior
No SSL issues.

Screenshots

System or device information (please complete the following):

• Device: Macbook Pro M1
• OS: MacOS
• OS version: Sonoma 14.5
• Browser: Chrome
• Version: 127

Not sure if this is the right place to report: on the SAPC tool beta, there is a section for Conformance Levels (color coded). It's unclear how (if at all) to apply these levels. Do they correspond in any way to AA/AAA ratings in the old standards?

Hi

This is feedback on the beta version that was demoed on the Silver call on November 3rd. I've put a couple of values into the tool (#00c7fd and #ffffff) and am trying to make sense of the results.

If I look at the Font Weight 400 column, these are the results:

My assumption is that:

1. These two colors have poor contrast so there's no preferred size and weight, hence the ⊘ symbol.
2. If I want Score 4 conformance, my computed font size at 400 weight has to be at least 101px.
3. If I want Score 3 conformance, my computed font size at 400 weight has to be at least 89px.

After that is where I get confused. What do the 75 and 63 values refer to? I'm assuming it's not computed text size because "px" is missing. Is the reason those values are displayed in my chosen colors and in larger sizes relevant?

Thanks.

Hi,
Do you have any plans to release this code as a commonjs or es6 module ?
For now, it is impossible to use APCAcontrast() inside nodejs or using a web bundler.
I'd be glad to help if there is a need!

Thank you for your work anyways :)

Hi,

I am implementing APCA based on the Resources section of https://w3c.github.io/silver/guidelines/methods/Method-font-characteristic-contrast.html. One of the features I am working on is the possibility to suggest a text color with a good contrast. For this, I need to know the desired luminance of the color that'd satisfy the contrast. As far as I see, there is no way to compute it because, in some cases, the contrast percentage depends on the actual luminance of the color yet to be suggest (due to the part Ytxt = (Ytxt > blkThrs) ? Ytxt : Ytxt + abs(Ytxt - blkThrs) ^ blkClmp;). Am I right?

In other words, I want to understand if the following function is possible with APCA: getDesiredLuminance(bgColor, desiredContrast).

P.S. sorry if it's not the right place to discuss it. Any suggestions are welcome!

I do not think that

Minimum Size Type Examples for Testing Various Levels

is very clear. My suggestions:

1. add a horizontal rule above the heading
2. change the heading to "Type Samples (that use your selected colors)"

I am a UX professional with some amateur coding skills. I created an offline (MS Excel) accessible color theme tool to use on my independent projects. The tool originally calculated contrast based on the WCAG 2.1 Relative Luminance and Contrast equations. I discovered WCAG 3's draft and APCA. Now, I would like to update my Excel spreadsheet tool so that the contrast values are based on the APCA equations and constants.

I am encountering a few issues.

1. The W3 Silver Github repository references a different set of equation constants than the Myndex SAPC-APCA repository. I am not sure which version of the constants is the latest and/or most likely "approved" to use.

2. I've translated the equations several times based on the LaTeX graphic, the Pseudocode, and the Javascript functions. I've tested different versions of the constants. However, my spreadsheet is still returning Lc results that do no match the only known sources for "correct" calculated values: this repository's "Testing Your Implementation" listed test values, and the myndex.com/APCA and myndex.com/SAPC calculators.

"TESTING YOUR IMPLEMENTATION
If you've implemented the code and want a quick sanity check, Here are four keystone checks with no rounding, where the first colos is TEXT and the4 second color is BACKGROUND:
#888 vs #fff • 66.89346308821438
#aaa vs #000 • -60.438571788907524
#def vs #123 • -98.44863435731266
#123 vs #234 • 1.276075977788573"

To solve my problem, I need to determine if the equations, as I have translated them into Excel formulas, are incorrect, and/or if the constants are incorrect. However, I can't seem to find any "correct" calculated values for the individual functions (e.g. fclamp, Snorm, Srev, H, C, Lc) so I can identify which part of the whole equation is wrong.

I think you wrote that you may create an OpenOffice Calc in the future. Would you be able to provide any guidance?

Thank you so much for creating these accessible tools for us!

As I read through this thread, particularly one titled "shootout", there's two aspects I'm not getting that I hope someone can help with. These come from various experiences from usability testing, where I've seen quite a variety in which colour combinations cause issues for various people. I get uncomfortable when the visibility of a colour combination to people without an impairment is used as evidence for it's visibility from an accessibility point of view.

The two main questions I have are:

1. When talking about percentages of colour combinations that aren't right with a particular model, is that out of the whole colour space of combinations, or some sub-set?
2. Is it in comparison to a theoretical model, or the variety of human sight?

I think I need to show my current mental modal about this. I am assuming that if you looked at a colour space of hues, and mapped which people (with no visual impairment) could read against white text, it might look something like this:

Where anything under the line didn't have enough contrast against a white background. That line would probably wave up and down a bit with different hues, but just take that as a baseline for regular vision.

Then, if someone had low-vision with less acuity, presumably that line needs to move up?

Then, if we accounted for various colour deficiencies (e.g. protanopia) you'd need to adjust that line in various ways depending on the hue used.

Then, to produce an overall model that accounted for both you'd want to be failing anything under either line:

I'm also assuming that the WCAG 2 formula is similar to the straight line, and the formula behind APCA is more bendy (apologies for the technical language ;-) ) to better match (non-impaired?) perception.

However, when talking about percentages, what is it if you include all the colours that would fail both? Because (from my mental model above) there are a ton of combinations that are terrible and should fail both, so a ~50% incorrect rate just doesn't sound right.

Originally posted by @alastc in w3c/low-vision-a11y-tf#131 (comment)

Does this relate to a web app or tool (i.e. you're an end user) OR is this about code or code integration (you're a developer).
end user of https://www.myndex.com/APCA/

Describe the bug
web app is broken, the UI is empty

To Reproduce
Steps so we can reproduce the behavior:
Visit https://www.myndex.com/APCA/

Screenshots

System or device information (please complete the following):

• Device: Desktop
• OS: Windows 10
• Browser: both Firefox 126.0 and Chromium 124.0.6367.201

Additional context
It broke sometime in the last 1-2 weeks.

Does this relate to a web app or tool (i.e. you're an end user) OR is this about code or code integration (you're a developer).

Neither.

Describe the bug

The readme section Current APCA Constants ( 0.0.98G - W3 last changed Feb 15, 2021 ) lists linear sRGB to CIE Y constants for sRGB, only. The readme states that Display-P3 and Abobe RGB are also supported (which is good, given the current move towards display-p3 in CSS and Canvas) but these constants are not listed, nor is the transfer function given. Please put these values in the documentation.

Specifications and sample code are not the same thing.

To Reproduce
Steps so we can reproduce the behavior: read the readme

Expected behavior
What were you expecting as correct behavior? Values in the documentation

Screenshots
Add screenshots or code snippets to help explain your problem. n/a

System or device information (please complete the following):

• Device: [e.g. iPhone6 or iMac]
• OS: [e.g. MacOS]
• OS version
• Browser [e.g. chrome, safari]
• Version [e.g. 22]
• n/a

Many common UI patterns adopt an all caps styling for some interface elements, notably buttons. Typically in old shcool typographic standards, this effectively puts the x height of the resulting text string roughly equivalent to the cap height of the font size selected. It's not good for anything more than 1-2 words, at which point it starts to interfere with readability (as opposed to legibility).

Is this factored into any of the research? Will it be factored into the 3.0 standard?

Issues I see:
Typically, capital letters are very slightly heavier in weight than lower case letters. However, they're not a full weight step (e.g. 400 –> 500) up, so a blanket rule of "treat it as one step up" wouldn't necessarily work. Here's a test I did using Helvetica Neue 400 and 500, comparing lower case L to capital i.

Greater apparent x height won't necessarily produce better legibility based on the spatial frequency and contrast sensitivity curve. Or maybe the larger spaces inherent in capital letters do, in fact produce better legibility. This might need some empirical testing.

What does letter spacing do to the whole thing? Wider letter spacing should, hypothetically, create wider spatial frequency, improving both legibility and (to a point) readability. This is a classic typographic maneuver, especially with short titles (e.g. headlines, buttons). Letter spacing might want its own separate issue.

Looking really great! My first impression critiques from Silver call 11/3:

• Swap foreground text color and background color at top of page.

• It took me more than a minute (!) to spot where the selected text color / background color were being demonstrated (since it is in the middle).
  • Order at top is background / sample / text color. Since we (in the west) read left-to-right, this would ideally be sample / text color / background color. But that would really mix up the layout.
  • In any case, I strongly recommend swapping text color with background color (in the top section).

• Replace N/A as used for when Score 1 (or even Score 2) is automatic.

• not applicable is not an accurate label when any font size will achieved Score 1 (or 2).
  • I don't have a great suggestion, but even OK or np (for no problem) would be better.

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.

I would like to be able to give someone a URL to SAPC that starts with my chosen colors.

For example the WebAIM Contrast Checker has a "permalink" feature, so I can start with red on white:
http://webaim.org/resources/contrastchecker/?fcolor=FF0000&bcolor=FFFFFF

User Request for the TOOL: Add the ability to import a list such as a csv, and generate a list of results.