[miguel-heygen]

What changed

hyperframes check now judges SVG text filled with a gradient (fill="url(#id)") by the gradient's own stop colours, and stops reading it as black. Near-white gradient titles on a dark backdrop no longer fail contrast_aa_failure at about 1:1.

The rule: a gradient fill is judged by its weakest stop, the one with the lowest contrast against the measured backdrop, since some glyph pixels really are that colour. Stops come from the gradient itself or, when it has none, from the gradient its href names. Stop opacity counts, and fully transparent stops are left out. A fill that points at a pattern or at nothing has no colour to judge, so that text is skipped. HTML gradient text (background-clip: text with transparent color) is already skipped in the same way.

Why

The audit read SVG text's colour from fill only when fill was a solid colour; for url(#...) it fell back to CSS color. That is not the paint SVG text uses, and it is usually the initial black. Every gradient title was judged as black text. Reported from the field on animated multicolour gradient text that was visibly white.

What I measured

• Reproduced on the released CLI first: a fixture with near-white gradient SVG text (stops #fff, #ffe3f1, #e3f6ff, two animated with GSAP) on #0b0b14 fails hyperframes@0.9.16 check with contrast_aa_failure, severity error, fg rgb(0,0,0), 1.07:1.
• fails without the fix: contrast-svg-gradient.browser.test.ts runs the audit in Chromium on four SVG texts and expects the light gradient and the href-borrowed gradient to pass, judged on their weakest stop (#e3f6ff), a gradient with one dark stop (#202030) to fail on that stop, and the pattern fill to be skipped. With main's audit every one of the four is read as rgb(0,0,0). With the fix the contrast tests (this file, the clip, solid, occlusion and fg tests) pass 45/45 three runs in a row on Linux Chromium.
• contrast-fg.test.ts: the TypeScript mirror of the foreground rule returns null for a url(...) fill instead of color.

What I did NOT exercise

• Gradients whose visible part of the text covers only some stops (userSpaceOnUse spans wider than the text, gradientTransform, spreadMethod): every stop is judged, so such text can be held to a stop it never shows.
• A url(#missing) <colour> fallback paint: skipped rather than judged by the fallback colour.
• The whole hyperframes check command built from this branch: the fixture ran on released 0.9.16 only; the fix is proven through the audit script in Chromium.

Size

About 40 lines in the browser audit, the mirror's rule and test, and one browser test file.

[heygengenesis]

Approving at 8cfe7350. I found no blockers.

• Fix: url(#id) fills on SVG text no longer fall back to CSS color, which was the black at 1.07:1. They resolve through the gradient's stops, following href/xlink:href for at most 8 hops. Stops are scaled by stop-opacity, and transparent stops are dropped. The ratio comes from the stop with the lowest contrast, and the reported fg is that stop. Pattern fills and missing references are skipped, which matches the existing background-clip:text skip. The stroke override still compares against the weakest-stop ratio, as it should.
• fails without the fix: contrast-svg-gradient.browser.test.ts checks the four selectors with an exact toEqual. On main's audit, all four come back rgb(0,0,0) and #pattern-text is still emitted, so the test can't pass there. On this head it ran green in CI: the flake gate passed it 10/10 and the chrome vitest project passed it. CI, Comments, preview-regression, regression and CodeQL are green. Windows render was still running when I posted this.
• The contrast-fg.ts mirror now returns Rgba | null. Its only caller is its own test, so nothing downstream breaks.

Non-blocking, and already listed under "did NOT exercise": judging every stop can be too strict for userSpaceOnUse or gradientTransform spans the glyphs never reach. A url(#missing) <colour> fallback is skipped rather than judged by its colour. Both are fine to leave as follow-ups.