APCA vs WCAG Contrast: What to Ship in 2026

APCA vs WCAG Contrast: What to Ship in 2026

Ship to the WCAG 2.2 contrast ratio. It is the published W3C Recommendation, the numbers (4.5:1 for normal text, 3:1 for large text and for user interface components) are what conformance claims and audits use, and nothing in the current WCAG 3 draft replaces it. APCA, the Accessible Perceptual Contrast Algorithm, is a separate project that reports a signed Lc value and is aimed at future standards. It is useful as a second opinion on text, especially light text on dark backgrounds, but it is not a substitute for the WCAG 2.2 test today.

The two methods can disagree sharply on the same pair: #767676 on white passes WCAG at 4.54:1 yet scores about Lc 72 in APCA, under the Bronze body-text minimum of Lc 75. Every pair below states its inputs and tools, so you can reproduce each number. We checked the W3C documents and the APCA project's own pages on October 22, 2026, and the colour pair results are our own calculations.

The status of each method, as published

Three facts frame everything else.

WCAG 2.2 is a W3C Recommendation. The version we read is labelled "W3C Recommendation 12 December 2024". Its contrast criteria are written in terms of a contrast ratio, and it defines how the ratio is computed.

WCAG 3 is a Working Draft and does not name a contrast algorithm yet. The draft we read is "W3C Working Draft 10 September 2026", and the W3C says it "may be updated, replaced, or obsoleted by other documents at any time" and that it is "inappropriate to cite this document as other than a work in progress." Its text contrast requirements, "Text contrast sufficient (minimum)" and "Text contrast sufficient (enhanced)", both carry the status "Developing", and the requirement text says the default presentation of text meets a "contrast measure to be determined." An editor's note adds: "The contrast algorithm used in WCAG 3 is yet to be determined." APCA is not named in that draft as we read it. The draft's plain-language summary also says: "WCAG 3 does not replace WCAG 2. WCAG 2 is used around the world and will still be required by different countries for a long time to come."

APCA is its own project. Its repository describes it as "a new method for predicting contrast for use in emerging web standards (WCAG 3) for determining readability contrast", derived from SAPC, "an accessibility-oriented color appearance model designed for self-illuminated displays." The same documentation set carries a "Bronze Simple Mode" guide whose own page warns that its content "is still under active development and should be considered beta. It may change, move, antecede, or be deleted with or without notice."

Put those together and the answer to "is APCA a replacement for WCAG contrast?" is clear. It is a candidate method promoted by its authors, in a project the WCAG 3 draft does not currently adopt. The WCAG 2.2 ratio stays the test you can cite.

The last row is our reading, not a quote. WCAG 2.2's success criteria are written as ratio thresholds, so a claim that a page meets 1.4.3 rests on the ratio. A page can pass APCA-based guidance and fail 1.4.3, and the reverse.

What WCAG 2.2 actually requires

The criteria are short, and it helps to have the numbers in one place.

• 1.4.3 Contrast (Minimum), Level AA. Text and images of text have a contrast ratio of at least 4.5:1, with exceptions: large-scale text at 3:1; incidental text (inactive components, pure decoration, invisible text, or text in a picture with significant other visual content) has no requirement; and text that is part of a logo or brand name has no requirement.
• 1.4.6 Contrast (Enhanced), Level AAA. At least 7:1, with large-scale text at 4.5:1 and the same exceptions.
• 1.4.11 Non-text Contrast, Level AA. User interface components and graphical objects need at least 3:1 against adjacent colours.

"Large scale" is defined in the glossary as text "with at least 18 point or 14 point bold or font size that would yield equivalent size for Chinese, Japanese and Korean (CJK) fonts." On the web that is commonly read as 24 CSS pixels, or about 18.66 pixels in bold, because a point is 1.333 CSS pixels; we show the arithmetic rather than quote the W3C on the pixel figure, since the glossary speaks in points.

The ratio itself is defined as (L1 + 0.05) / (L2 + 0.05), where L1 is the relative luminance of the lighter colour and L2 that of the darker. Relative luminance for sRGB is L = 0.2126 R + 0.7152 G + 0.0722 B, with each channel linearised first (divide by 12.92 at or below 0.04045, otherwise ((value + 0.055) / 1.055) raised to 2.4). Our contrast checker works the formula step by step, so we will not repeat it here.

Two rules matter in practice. First, the Understanding document for 1.4.3 says the computed ratio should not be rounded: "4.499:1 would not meet the 4.5:1 threshold." A tool that shows 4.5 for a 4.499 pair is rounding in your favour. Second, the ratio is symmetrical. Dark on light and light on dark give the same ratio for the same two colours. That is the property APCA drops.

What APCA reports instead

APCA takes a text colour and a background colour, in that order, and returns a signed number called Lc (lightness contrast). The code header of apca-w3 states how to read it: "Negative values mean light text and a dark background, positive values mean dark text and a light background. 60.0, or -60.0 is a contrast 'sort of like' the old WCAG 2's 4.5:1." It also warns: "APCA is polarity sensitive!" and "Do Not Mix Up Text and Background inputs."

The project's Bronze Simple Mode is the beginner-friendly set of levels, intended "for users migrating from WCAG 2 contrast." As published on its page (labelled beta), the minimums are:

Two caveats come from the same page. It defines body text as "a block or column of more than two continuous lines of content text that uses a readable font with an x-height of ~19px or less," so the 75 minimum is for blocks of reading text, not labels. And it presents these as a simplified starting point; its fuller guidance depends on font size and weight, which is part of what APCA's authors say WCAG 2's two-bucket approach misses. We have not verified the fuller tables and do not quote them.

Side-by-side: real pairs, stated inputs

To see where the two methods agree and disagree, we computed both for a set of colour pairs. Inputs: sRGB hex colours, WCAG 2.2 formula as above, and APCA via the apca-w3 npm package, version 0.1.9 (G-4g constants), calling calcAPCA(text, background) with the text colour first. Lc values are rounded to whole numbers; ratios are rounded to two decimals (4.48 for #777777, whose exact value is about 4.478), whereas a tool that truncates instead of rounding, such as our own contrast checker, may show 4.47. Either way the pair fails 4.5:1. These are our calculations, so run them yourself if a decision rests on them.

The table is dense, so here are the lessons it holds.

Lesson 1: the two methods disagree most on dark backgrounds

Look at #888888 on #121212. WCAG gives 5.28:1, a clear AA pass for normal text. APCA gives Lc -38, far below even the lowest text guideline in Bronze. Grey text at that tone on a near-black page is a familiar complaint: it passes the ratio test and still looks weak. The #CCCCCC on #121212 pair sits at Lc -75, right at the body minimum, with a WCAG ratio of 11.67 that says nothing about being borderline. If you design dark interfaces, APCA flags borderline pairs that the ratio waves through. Our dark mode design guide takes that further, and the accessible color systems guide shows how to build token pairs that survive both checks.

Lesson 2: polarity matters

The pairs #767676 on #FFFFFF and #FFFFFF on #767676 have the same WCAG ratio, 4.54, by definition. APCA reports Lc 72 for grey text on white and Lc -77 for white text on grey. The same two colours are rated differently depending on which one carries the text. APCA's authors argue this matches human perception, since light-on-dark and dark-on-light text are not equally readable at the same luminance difference. Whether you accept that, the practical effect is that you can no longer check a pair once; you check it in the direction you will use it.

Lesson 3: saturated mid-tone colours behave differently

Orange (#FF6600) is an instructive case. Black on orange passes WCAG comfortably at 7.15:1 and sits at Lc 49 in APCA, below the lowest Bronze text level. White on orange fails WCAG at 2.94:1 and reaches Lc -60, which is the "other content text" minimum. The two methods rank the same two text colours the opposite way round. If you have ever chosen black text on an orange button because the ratio said so and then felt it looked dull, this is the kind of gap APCA is trying to measure. Treat it as a prompt to look at the pair, not as proof either rating is wrong.

Lesson 4: the common AA boundary is not an APCA boundary

#767676 on white is the lightest grey that clears 4.5:1 and is often quoted as the boundary. In APCA it is Lc 72, under the Bronze body minimum of 75. A design that is "just AA" on grey text is, by APCA's beta levels, a little light for body copy. That does not make it non-conforming under WCAG 2.2. It makes it a candidate for darkening, if the design allows.

Lesson 5: blue on white

Pure blue (#0000FF) rates well on both. The WCAG ratio of 8.59 is a pass, and Lc 86 is between the body minimum and the preferred value. Not every saturated colour is a problem for APCA, so it would be wrong to read the orange result as "APCA dislikes saturation".

Neither contrast method says whether two colours of similar lightness stay distinguishable for colour-blind viewers; we computed that for published palettes in color-blind friendly palettes: hex codes, tested.

What neither method covers for you

Non-text contrast. WCAG 1.4.11 asks for 3:1 for components and graphical objects. The APCA project's non-text guidance appears on its documentation index as a placeholder ("coming soon"), at the time we read it. If you check icons, borders of inputs and focus indicators, the WCAG 3:1 ratio is the only published test.

Colour-only cues. Contrast is not the same as colour independence. Charts and status indicators need a second cue regardless of ratio. Our chart colour accessibility checklist covers that.

Text rendering. Anti-aliasing, font hinting and thin weights change real-world legibility. Neither algorithm sees them. APCA's authors address weight through the Lc-per-size guidance; WCAG addresses it only through the large-text bucket.

Images, gradients and overlays. Text on a photograph or gradient has no single background colour. WCAG requires the criterion to be met against the background in use, and for APCA the same problem applies. Measure the worst case region or put a scrim behind the text.

Transparency. APCA's code includes a function for blending alpha-transparent colours before calculating. The WCAG draft notes that "transparency can cause testing issues, but should be tested as the rendered color." In both cases, test the colour as rendered.

A decision framework for 2026

Here is a rule set that keeps you conformant and also takes APCA's information seriously. It is our recommendation, not a standard.

1. Make WCAG 2.2 the gate. No text or component pair ships unless it meets 1.4.3 and 1.4.11 at the level you target. This is what an auditor, a procurement document or a legal reviewer will test.
2. Add APCA as a review flag on text. For body text and long reading, check the pair in its real direction. If the Lc magnitude is below the Bronze body minimum (75), review the pair for a darker or lighter tone. Treat it as a design prompt, not a failure.
3. Check dark mode separately. Do not assume a light theme's tokens flip to a dark theme with the same results. Run each direction of each pair.
4. Use size and weight. Where the design allows, bigger and heavier text needs less contrast. Do not use small light-weight text on mid-tone backgrounds just because the ratio technically passes.
5. Record both numbers in your tokens. A contrast column with the WCAG ratio and the Lc value, labelled with the tool version, makes later decisions faster if WCAG 3 settles on an algorithm.
6. Re-check when WCAG 3 changes. The Working Draft says the algorithm is to be determined. Subscribe to the status, not to a blog's prediction.

A short table of what to do with typical disagreements:

The third row is the one to be firm about. APCA scoring well does not rescue a pair that fails the ratio when you are working to WCAG 2.x, because the success criterion is the ratio.

How to run APCA yourself

The apca-w3 package is on npm and its repository describes it as "the approved code intended for public guidelines." In JavaScript the call is short:

import { calcAPCA } from "apca-w3";
// text colour first, background second
const lc = calcAPCA("#767676", "#ffffff"); // positive: dark on light

Round to a whole number for reporting and keep the sign. The package's README and licence are the authority on how you may use it; read them before bundling it into a product, since we did not review the licence terms.

For your own tests, vary one thing at a time: swap polarity, move one tone, change the background by a step. APCA's results are not linear in the way a ratio feels, and a few experiments teach more than any table.

Standards and tools cited

All read October 22, 2026.

• W3C, Web Content Accessibility Guidelines (WCAG) 2.2, Recommendation of 12 December 2024 (success criteria 1.4.3, 1.4.6, 1.4.11; contrast ratio and relative luminance definitions; large-scale text).
• W3C, Understanding Success Criterion 1.4.3 (no rounding of computed ratios).
• W3C, W3C Accessibility Guidelines (WCAG) 3.0, Working Draft of 10 September 2026 (status, contrast requirements marked Developing, "contrast algorithm ... yet to be determined", "WCAG 3 does not replace WCAG 2").
• Myndex, SAPC-APCA documentation repository and apca-w3 source (description, Lc sign convention, polarity warning, version 0.1.9).
• APCA/ARC project, Bronze Simple Mode (beta levels Lc 75, 90, 60, 45).
• Our own calculations: WCAG ratios from the formula above; Lc values from apca-w3 0.1.9, calcAPCA(text, background). Not verified: APCA's font-size and weight lookup tables, third-party research on APCA's accuracy, and APCA's licence terms.

Questions teams ask about APCA

Is APCA part of WCAG 3?

Not as of the Working Draft dated September 10, 2026. That draft says the contrast algorithm "is yet to be determined" and does not name APCA. APCA's authors describe it as intended for use in emerging web standards including WCAG 3.

Can I claim WCAG 2.2 conformance using APCA?

No. WCAG 2.2's contrast success criteria are written as ratio thresholds, so conformance is judged against the ratio.

Which is stricter, APCA or WCAG?

It depends on the pair. Grey text on white at #767676 passes the WCAG normal-text threshold at 4.54:1 and falls below the Bronze body minimum in APCA at Lc 72. Black on orange passes WCAG at 7.15:1 and scores Lc 49. Neither method is stricter in every case.

What Lc value matches 4.5:1?

There is no exact conversion. The apca-w3 code header says Lc 60 is "sort of like" 4.5:1, while the Bronze Simple Mode body-text minimum is Lc 75. Our table shows the two scales do not map one to one.

Do I need APCA for dark mode?

You do not need it, but it is where the two methods disagree most in our results. Mid-grey text on near-black can pass the ratio and score far below APCA's text guidance, as with #888888 on #121212.

Does the same colour pair give the same APCA result both ways?

No. APCA is polarity sensitive: dark text on a light background and light text on a dark background yield different Lc values for the same two colours.

Will WCAG 3 replace WCAG 2.2?

The WCAG 3 draft states that it does not replace WCAG 2 and that WCAG 2 will still be required by different countries for a long time.

Misreadings to avoid

1. Calling APCA "WCAG 3 contrast". The current WCAG 3 draft states the algorithm is yet to be determined.
2. Dropping the WCAG ratio because APCA looks newer. The ratio is the Recommendation.
3. Checking a pair in one direction only. APCA is polarity sensitive; check the real foreground and background.
4. Treating Bronze levels as final. Their own page labels them beta.
5. Applying the body-text threshold to everything. Bronze separates body, other content text and large text.
6. Trusting a tool that rounds. WCAG says a 4.499:1 pair fails; some tools show it as 4.5.
7. Ignoring non-text contrast. Icons and input borders still need 3:1 under 1.4.11.

Taking both checks into a palette

To turn these checks into a palette, the accessible color systems guide shows how to build tokens where each text pair is checked in both themes. For the broader accessibility criteria beyond colour, the WCAG compliance guide is the next stop.