217 small-text nodes across 44 blog SVGs clear 3:1 but miss WCAG AA 4.5:1 — the house secondary greys sit just under the floor

[hotlong]

Observation from the #166 sweep, recorded so the next sweep does not re-derive it. No action implied — this is a palette question about the site's secondary text colours, and it is much larger than any one card.

What was measured

Full sweep of content/blog/**/*.svg at head c9e76a7 (i.e. with #166's fixes applied): 102 files, 1,942 measurable text nodes. Method is #140/#167's — Chromium at native viewBox, getComputedStyle().fill per text leaf, ground sampled as the median of nine pixels across the glyph box in a second raster with text{visibility:hidden}.

Applying the floor #166's ruling states — 4.5:1 for text rendered under 18px (or under 14px bold), 3:1 at or above — the corpus is:

• 2 nodes below 3:1 — the accent-gold ? pair, filed separately as The accent-gold ? on enterprise-ontology-race-open-vs-closed/cover{,-en}.svg reads at 1.79:1 — but the mechanical darkening rule cannot be applied to it #181.
• 217 nodes between 3:1 and their 4.5:1 floor, across 44 files. 186 on light grounds, 31 on dark.
• everything else clears.

The 217 are not scattered mistakes; they are a handful of house colours used consistently, landing just under AA at small sizes:

fill	nodes	files	ratio range	rendered sizes
#647872	102	18	4.092–4.478	11–15px
#657872	23	4	4.174–4.463	13–14px
#b85c4d	18	2	4.021–4.453	14–15px
#c8ece2	14	3	4.318	14–16px
#7d8f88	10	1	3.128–3.202	12.5–13px
#8a9691	8	1	3.037	12px
#5d736b	7	5	4.352–4.491	14–16px
#9a6b8a	6	2	3.088	13px
(12 more fills)	29	—	3.218–4.491	11–15px

88 of the 217 are within 0.2 of the floor — #5d736b at 4.352–4.491 and #647872 at 4.09–4.48 are the site's ordinary secondary-text greys, missing AA by a hair rather than by a category.

Why this was not swept with #166

#166's population was the 19 nodes below 3:1, and its ruling was explicitly scoped so that "nobody is re-designing anything". This band is a different animal:

• It is 217 nodes in 44 files against 19 muted-grey text nodes in blog SVGs sit below WCAG 3:1 on light grounds — a palette decision, not a cascade bug #166's 19 in 5 — roughly half the blog corpus.
• It is dominated by two or three house colours. Fixing it is not a set of local decisions, it is re-picking the site's secondary text palette, and it would land the same way in the Astro components that use those greys, not just in the SVGs.
• Several are marginal enough (4.49 vs 4.50) that the answer may be to change the size rather than the colour, which is a layout decision.

If it is taken up

• The lever is small: #647872 → about #5d6f68 clears 4.5:1 on the #eef7f3-family grounds, and #5d736b is already within one or two 8-bit steps.
• Decide the floor first. WCAG's own large-text threshold is 18pt/24px (14pt/18.66px bold), not the 18px/14px used here; 19 muted-grey text nodes in blog SVGs sit below WCAG 3:1 on light grounds — a palette decision, not a cascade bug #166's ruling deliberately set a stricter px-based line. Whether the site holds itself to AA for all small text is the actual question.
• Worth deciding alongside whether a contrast gate ships at all. Blog SVGs: give dark-card text an explicit fill so it stops rendering dark-on-dark #167 concluded the check cannot be a static heuristic in content-lint — it needs Chromium — and suggested a scheduled or pre-release job. A gate is only worth building once the floor it enforces is settled.

Recording only; unassigned.

Generated by Claude Code