Why this exists
An accessibility review of the theme work looked at the prose link colour and concluded no fix is needed — it passes. This ticket exists so that conclusion has a record and a guard, rather than evaporating.
--ifm-link-color: #15803d (src/css/custom.css:48) on --ifm-background-color: #f6f3ec (:17) measures:
4.526:1 — AA minimum is 4.5:1
It clears the bar by +0.026, and the links are already underlined, so SC 1.4.1 (use of colour) is independently satisfied. Confirmed live on oh.mifune.dev — 9 such links on /blog/compound-engineering, 4 on /blog/containers-microvms-vms. /docs/intro and / carry no green prose links at all.
So: not a defect, and this is deliberately not a request to change the colour.
The actual gap
There is no contrast tooling anywhere in this repo — no axe-core, pa11y, or lighthouse in package.json, no workflow beyond pages.yml, no test mentioning contrast.
With a margin that thin, one half-shade token nudge — a designer darkening the background, or lightening the link — crosses AA and nothing catches it. The failure would be silent and invisible in review.
Suggested scope
Small and mechanical:
- assert the computed ratio of
--ifm-link-color on --ifm-background-color stays ≥ 4.5:1, in both light and dark blocks
- ideally cover
--ifm-background-surface-color too, since a link on a raised surface is a different pair
A node script reading the CSS variables and computing WCAG relative luminance is enough; a full axe-core run is more than this needs.
Precedent
The sibling website repo just hit the live version of this: two genuine AA failures on a raised surface (4.02:1 and 3.58:1 composited) that no scan caught because it had none. Same token family, same shade of green.
Filed because the review that produced it recorded "drop the fix, add a guard later" and then filed nothing — leaving it silently neither. Either this gets scheduled, or it gets closed with "margin accepted" on the record.
Why this exists
An accessibility review of the theme work looked at the prose link colour and concluded no fix is needed — it passes. This ticket exists so that conclusion has a record and a guard, rather than evaporating.
--ifm-link-color: #15803d(src/css/custom.css:48) on--ifm-background-color: #f6f3ec(:17) measures:It clears the bar by +0.026, and the links are already underlined, so SC 1.4.1 (use of colour) is independently satisfied. Confirmed live on
oh.mifune.dev— 9 such links on/blog/compound-engineering, 4 on/blog/containers-microvms-vms./docs/introand/carry no green prose links at all.So: not a defect, and this is deliberately not a request to change the colour.
The actual gap
There is no contrast tooling anywhere in this repo — no axe-core, pa11y, or lighthouse in
package.json, no workflow beyondpages.yml, no test mentioning contrast.With a margin that thin, one half-shade token nudge — a designer darkening the background, or lightening the link — crosses AA and nothing catches it. The failure would be silent and invisible in review.
Suggested scope
Small and mechanical:
--ifm-link-coloron--ifm-background-colorstays ≥ 4.5:1, in both light and dark blocks--ifm-background-surface-colortoo, since a link on a raised surface is a different pairA node script reading the CSS variables and computing WCAG relative luminance is enough; a full axe-core run is more than this needs.
Precedent
The sibling
websiterepo just hit the live version of this: two genuine AA failures on a raised surface (4.02:1 and 3.58:1 composited) that no scan caught because it had none. Same token family, same shade of green.Filed because the review that produced it recorded "drop the fix, add a guard later" and then filed nothing — leaving it silently neither. Either this gets scheduled, or it gets closed with "margin accepted" on the record.