SAPC-APCA: the documentation repository behind a new contrast model

A docs repo, with the algorithm deliberately elsewhere

The README states the scope in its first lines. APCA is the Accessible Perceptual Contrast Algorithm, a new way to predict contrast for text and non-text content on self-illuminated displays, and this repository is for the documentation, for issue tracking, and for the discussion forum. The code, apps, variants and supporting libraries are in separate repositories. That separation is the most important thing to understand before evaluating the project, because the thing most people arrive looking for, a function that computes a contrast value, is deliberately not here.

The approved code is in the apca-w3 repository, described as the approved code intended for public guidelines and as the only code that should be used for any development purpose, and it is published to npm as apca-w3, installed with npm i apca-w3.

The repository itself is a site rather than a package. The top level holds a CNAME, a _config.yml, _includes/ and _layouts/ for the site generator, a CSS/ directory, a documentation/ directory, a WEBTOOLS/ directory, an images/ folder and a WhyAPCA.md. The primary language of the repository is CSS for that reason, the licence is a custom non-commercial one kept in LICENSE.md, and the last push was on 2026-07-25.

What APCA is, and what it is derived from

The project description gives the derivation chain. APCA is a new method for predicting contrast for use in emerging web standards, specifically WCAG 3, for determining readability contrast, and it is derived from the SAPC, the S-LUV Advanced Predictive Color, which is described as an accessibility-oriented color appearance model designed for self-illuminated displays. The point of deriving from a color appearance model rather than from a luminance ratio is that the traditional WCAG 2 contrast ratio treats all pairs of foreground and background colours as if they were printed on white paper, which is not what a screen does.

The documentation set is organised by audience. For people who want the plain-language version there is an Easy Intro to APCA and a Bronze Simple Mode guideline, the latter described as a most basic design guideline intended for users migrating from WCAG 2 contrast. For people who want the reasoning, there is a Main Readme Doc with a discussion of the math and code walkthroughs, a Why APCA overview at the shallow end of the pool, an APCA in a nutshell page described as an early minimum user guide, and an APCA FAQ which the README marks as work in progress.

There is also a curated link collection described as a Linktree and a larger main catalog of articles, repos and white papers, and the APCA tool itself has moved to APCAcontrast.com, as the README's own note says.

The draft criterion and its three conformance levels

The APCA Readability Criterion is described as a draft independent criterion that is up as a work in progress, with sections still to be added or adjusted. It is hosted under the ARC site, and the subpages are what make the design guidance usable.

There are two of them under the Visual Contrast and Non Text Contrast headings. Visual Readability Contrast is the multi-level conform guideline, with Bronze, Silver and Gold levels for basic to enhanced accessibility, and the APCA in a nutshell page notes that it has been largely superseded by that Bronze Simple Mode document. Bronze Simple Mode is the migration path, the most basic design guideline intended for users coming from WCAG 2 contrast. Non Text Contrast is marked in the README as a placeholder for the non-text guidelines, coming soon, and its companion Design Guide is also a placeholder.

There are three Design Guides that are not placeholders: a Visual Contrast guide with practical design advice and examples, a Paper Reading Experience guide for a reduced-fatigue design in light mode that is marked as work in progress, and the Non Text Contrast guide. For an implementer, the practical reading order is Bronze Simple Mode first, since it is the least demanding, and the Visual Readability Contrast levels second if you need the conformance structure.

The forums, the tools listing and the one place to post

The README is unusually firm about where discussion belongs. For comments or questions, the SAPC-APCA forum is the place, and the instruction is to post all comments, questions and discussions regarding theory, math, code and third-party tools there, and not in the satellite repositories, so that they can be tracked and resolved. The rationale given is that discussion here may eventually become part of the FAQ and the guidelines. The forum is the GitHub Discussions area of this repository.

The tools section links to a Color and Contrast Tools Listing described as many third party tools as well as canonical technology demonstrators. That listing is the place to see what implementations exist outside the reference package, and it is also where the two competing kinds of tool are separated, since a contrast checker that only implements the WCAG 2 ratio and one that implements APCA will produce different answers for the same colour pair and it matters which one a user is looking at.

The Sciency Stuff section points at the resources that explain why the model behaves the way it does. The base APCA-W3 formula is available as LaTeX math, there is a Standard Observer Model page described as the setting for a mathematical eyeball, a page on exponents that explains why the algorithm uses a power function rather than a straight ratio, an independent review page saying that APCA and APC-RC are derived from decades of peer-reviewed science, and a Visual Contrast draft whitepaper that is an early draft from the W3C Silver working group.

The peer review and the W3C draft are worth noting, because they are the difference between APCA being an individual's model and being a candidate for a standard.

The licence and the beta status are both stated up front

Two facts sit in the README's badge row rather than being buried, and both matter for a decision. The licence badge reads Beta Non-Com, and the licence file is LICENSE.md, so this is a source-available, non-commercial licence rather than an open source one. The project is research funded work at Myndex Research, with its own site at git.myndex.com and a Twitter account for the research group, and the licence choice is consistent with a research programme whose goal is to influence a standard rather than to be adopted as a dependency.

The beta designation is on the licence badge rather than on the algorithm, and it should be read as what it is: the criterion is a draft, the docs are explicitly a work in progress in several places, the FAQ is work in progress, and the non-text contrast side of the guideline is a placeholder. There are no GitHub releases, so the repository has no version history to pin against.

That combination, a non-commercial beta licence, a draft criterion and a separate code repository, means APCA is a proposal you evaluate rather than a dependency you adopt. Nothing in the repository contradicts that reading; the placeholders are marked as such, and the README says directly that the APCA tool is now at APCAcontrast.com.

Where APCA is the wrong tool today

Two cases point elsewhere, and one of them is about status rather than quality.

The first is a project with a compliance deadline. If a product has to pass an accessibility audit against a published standard today, the standard to meet is WCAG 2 and its contrast ratios, and the draft APCA criterion cannot be cited as conformance. Using APCA numbers in a design system that is audited against WCAG 2 creates a mismatch, because the two models disagree about which pairs pass, and an audit will use the one it knows. The Bronze Simple Mode guideline exists precisely as the migration bridge, which tells you the project's own authors expect adoption to be gradual.

The second is a product that needs a contrast check at runtime with no human in the loop. APCA is designed to predict the readability of text and non-text content for a human looking at a self-illuminated display, and the documentation here is written for designers and developers making judgements, with the reasoning exposed so that a judgement can be defended. It is not packaged here as a validator with a pass or fail verdict, and a decision engine that needs a binary answer is a different kind of problem.

The alternative worth weighing is staying with the WCAG 2 contrast ratio and treating APCA as input into design decisions rather than as a gate. The difference in approach is that WCAG 2 asks whether a pair of colours clears a fixed ratio, while APCA models what a person with a given vision would actually perceive on a screen with its own luminance, so the answer depends on the display, the text size and the polarity of the pair. The research pages in the repository are what make that difference legible rather than mystical.

Editorial conclusion

SAPC-APCA fits a designer or developer who needs to understand how APCA differs from the WCAG 2 contrast ratio, who wants to see the reasoning behind the model rather than just a calculator, and who is willing to follow a draft criterion that is still being written. It does not fit a team that needs a stable, standardised rule to ship against today, because the APCA Readability Criterion is described as a work in progress with sections still to be added. Before you rely on it, read the Bronze Simple Mode guideline, which is the intended migration path for anyone coming from WCAG 2, and take the code from the apca-w3 package rather than from any satellite repository, since the README says that package is the only code that should be used for development purposes.

Frequently asked questions

Official sources

1. Issues
2. Myndex/SAPC-APCA on GitHub
3. Project website
4. README