color-contrast silently skipped when computed colors contain CSS Color 4 `none` components

[michieldbruin-ux]

Product

axe-core

Product Version

4.12.1

Latest Version

• I have tested the issue with the latest version of the product

Issue Description

When a computed color serializes with a CSS Color 4 none component (for example oklch(0.7 0.15 180 / none) or lab(40 none 20)), the color parser fails and the color-contrast check is silently skipped for those nodes. They appear in neither violations nor incomplete.

Expected: color-contrast evaluates these elements, or at minimum reports them as incomplete.

Actual: no result at all for color-contrast on the affected nodes, which is indistinguishable from a page that genuinely passes.

Steps to reproduce:

1. Create a page with low-contrast text whose color is set via oklch() with one component written as none. Modern browsers serialize interpolation results this way, and recent Tailwind CSS versions emit it for achromatic colors.
2. Run axe with the wcag2aa tag set.
3. Observe the element is absent from both violations and incomplete for color-contrast.
4. Change the none component to 0 and run again: the violation now appears, so the page itself is unchanged and the difference is in the parser.

Impact: silent false negatives on WCAG 1.4.3. Because the rule produces no result rather than an error, automated audits report no contrast findings on affected pages. This affects a growing share of production sites built with frameworks that emit oklch by default. A fallback to incomplete would preserve honesty even where parsing is not implemented.

Workaround we apply: normalizing none components to 0 in computed styles before invoking axe, which restores measurement.

I can provide a minimal HTML reproduction if that is useful.

[straker]

Thanks for the issue. I tested both the oklch(0.7 0.15 180 / none) and lab(40 none 20) for color contrast. the oklch passes color contrast while lab incompletes. This is expected as #4959 fixed the issue that caused those to both crash the rule. The true fix would be to update our version of colorjs, but when we did that we ran into an issue and had to revert. I created #5313 to track the upgrade.