Found while reviewing spec #25's accessibility ticket (#52), by building the renderer and grepping the compiled Tailwind CSS. Pre-existing and sitewide — not introduced by that ticket, which only inherited the convention by following it faithfully.
What is wrong
focus-visible:ring-ring produces no compiled CSS rule for the ring colour. The width and offset utilities (ring-2, ring-offset-1, ring-offset-2, ring-offset-background, outline-none) all compile to real rules — only the colour is missing.
Cause: @theme inline never maps --color-ring to the raw --ring custom property. The same gap exists for --color-primary / --primary, so ring-primary and border-primary are affected identically.
Tailwind's ring utility falls back to currentcolor, so a focus ring still renders — it is simply the current text colour instead of the intended theme tint. The accessibility impact is therefore mild (focus remains visible) but the intent is silently lost, and contrast is not what the theme specifies.
Where it shows up
Not specific to the board. The same already-shipped pattern appears in at least:
apps/emdash-desktop/src/renderer/lib/ui/sidebar-primitives.tsxIntegrationRow.tsxThemeCard.tsxMcpModal.tsx
plus every focus ring spec #25 added (cards, the card Move handle, the hover-open arrow, column collapse toggles, the column "+" creation button, the collapsed-column drop zone, Ghost Cards).
Fix
Wire the missing theme tokens so @theme inline maps --color-ring → --ring and --color-primary → --primary (and audit the rest of the token set for the same omission while there). Then verify by building the renderer and grepping the compiled CSS for an actual --tw-ring-color rule — a unit test cannot catch this, because the browser test harness injects only a hand-picked CSS subset rather than the compiled stylesheet.
That harness limitation is worth noting on its own: it is why this went unnoticed. Any criterion about visible styling needs the compiled-CSS check, not a harness assertion.
Why it was not fixed in the spec #25 PR
Wiring theme tokens is a cross-cutting change to the design-system layer, affecting every component that uses these utilities. Doing it inside an accessibility-keyboard ticket would have widened that PR's blast radius well beyond its scope, with no focused review of the visual result.
Found while reviewing spec #25's accessibility ticket (#52), by building the renderer and grepping the compiled Tailwind CSS. Pre-existing and sitewide — not introduced by that ticket, which only inherited the convention by following it faithfully.
What is wrong
focus-visible:ring-ringproduces no compiled CSS rule for the ring colour. The width and offset utilities (ring-2,ring-offset-1,ring-offset-2,ring-offset-background,outline-none) all compile to real rules — only the colour is missing.Cause:
@theme inlinenever maps--color-ringto the raw--ringcustom property. The same gap exists for--color-primary/--primary, soring-primaryandborder-primaryare affected identically.Tailwind's ring utility falls back to
currentcolor, so a focus ring still renders — it is simply the current text colour instead of the intended theme tint. The accessibility impact is therefore mild (focus remains visible) but the intent is silently lost, and contrast is not what the theme specifies.Where it shows up
Not specific to the board. The same already-shipped pattern appears in at least:
apps/emdash-desktop/src/renderer/lib/ui/sidebar-primitives.tsxIntegrationRow.tsxThemeCard.tsxMcpModal.tsxplus every focus ring spec #25 added (cards, the card Move handle, the hover-open arrow, column collapse toggles, the column "+" creation button, the collapsed-column drop zone, Ghost Cards).
Fix
Wire the missing theme tokens so
@theme inlinemaps--color-ring→--ringand--color-primary→--primary(and audit the rest of the token set for the same omission while there). Then verify by building the renderer and grepping the compiled CSS for an actual--tw-ring-colorrule — a unit test cannot catch this, because the browser test harness injects only a hand-picked CSS subset rather than the compiled stylesheet.That harness limitation is worth noting on its own: it is why this went unnoticed. Any criterion about visible styling needs the compiled-CSS check, not a harness assertion.
Why it was not fixed in the spec #25 PR
Wiring theme tokens is a cross-cutting change to the design-system layer, affecting every component that uses these utilities. Doing it inside an accessibility-keyboard ticket would have widened that PR's blast radius well beyond its scope, with no focused review of the visual result.