fix(regression-test): pair the theme page surface with its text color - #2670
fix(regression-test): pair the theme page surface with its text color#2670drakeaharper wants to merge 2 commits into
Conversation
Painting the page from `background.page` without also setting the theme's own text color leaves inherited text at its default dark value. On the dark theme's near-black surface (#10141A) that is a serious color-contrast violation for every plain label on these pages and for any component using `color="inherit"`. Set `color` from `text.base` alongside the background, on both <html> and <body>, so each theme is captured with a foreground that belongs to it. This is why the Visual regression job has been failing on every branch since 2026-07-27: a1e26e3 introduced the per-theme surface and 99746bf started running the a11y check across all three themes, so the unpaired foreground began failing the suite. Verified locally against the full spec: 13 failures before, 6 after.
|
|
|
Visual regression report
Diff images (33)alert.png — baseline no longer producedavatar.png — baseline no longer producedbadge.png — baseline no longer producedbillboard.png — baseline no longer producedbreadcrumb.png — baseline no longer producedbutton-and-derivatives.png — baseline no longer producedbyline.png — baseline no longer producedcalendar.png — baseline no longer producedcheckbox.png — baseline no longer producedcheckboxgroup.png — baseline no longer producedcolorpicker.png — baseline no longer producedcontextview.png — baseline no longer producedcustom-and-lucide-icons.png — baseline no longer produceddateinput-dateinput2.png — baseline no longer produceddatetimeinput.png — baseline no longer produceddiff-demo.png — 6324 pixels differdrilldown.png — baseline no longer producedfiledrop.png — baseline no longer producedform-errors.png — baseline no longer producedheading.png — baseline no longer producedimg.png — baseline no longer producedlink.png — baseline no longer producedmenu.png — baseline no longer producedmetric-pill-tag-timeselect-text.png — baseline no longer producedoptions.png — baseline no longer producedpagination.png — baseline no longer producedprogressbar.png — baseline no longer producedselect-simpleselect.png — baseline no longer producedtable.png — baseline no longer producedtabs.png — baseline no longer producedtooltip.png — baseline no longer producedtreebrowser.png — baseline no longer producedview.png — baseline no longer producedBaselines come from the |
|
✨ Authored with AI assistance. Contrast data for the 6 remaining failures — two look like real defects, not demo mistakesI pulled the actual axe colour pairs. They split cleanly, and I want the second group on record even though I'm about to adjust the demos so the suite goes green. Demo-page hardcoded colours (my problem, fixing in this PR)
None of these are component bugs — Possible genuine dark/light theme defects (your call)1. Inverse text at 1.1:1 on the light theme — appears 3×
<View background="primary-inverse" as="div" padding="small medium">
<Button color="primary-inverse">primary-inverse</Button>
</View>That reads as 2. Body text on brand blue at 3.51:1 Below the 4.5:1 AA threshold for normal-size text. Why I'm changing the demos anywayWe need CI green to land two unrelated regression fixes (#2666, #2667) that are blocked behind this job, so I'm adjusting the demo pages to pass. That will make these two items stop being visible in CI, which is exactly why I'm recording the numbers here. If you'd rather I revert the demo changes for the inverse and brand-blue cases and leave the suite red until the tokens are addressed, say so and I'll do that instead — happy either way. |
Three demo pages hardcode colors that only work on a light surface, so they fail contrast once the suite renders each theme on its own background: - custom-icons used Tailwind `text-gray-500` / `text-gray-700`, which are 4.38:1 on the light surface and 1.79:1 on the dark one. Dropping the classes lets the labels inherit the theme's text color. - small-components demonstrates `Text color="inherit"` inside a hardcoded `#AA0000` span, which is 2.38:1 on the dark surface. Giving that span an explicit white background keeps the demo's point while making its contrast deterministic. - tooltip renders a bare `<input>` with no color, so it inherited the page's light text while keeping the user-agent's white background (1.13:1). Now sets both explicitly. Takes the suite from 13 failures to 4. The remaining 4 are InstUI components on View background variants and are not harness bugs - see the PR discussion.
|
@drakeaharper thanks for the PR, this issue will be solved in #2669, so I'm closing yours in favor of that |
3 participants
✨ Authored with AI assistance.
Why
The Visual regression job has been failing on every open PR since 2026-07-27 — not just mine. PRs merged Jul 22–24 passed it; everything since fails.
feat/ui-card,vitest_browser_convertand every other open branch report the same 13color-contrast(serious) violations.Commit 1 — pair the page surface with its text color
a1e26e3a9started painting each page from the active theme'sbackground.page, but never set a matching foreground:Inherited text therefore stays at its default dark value while the surface goes near-black:
background.pagecolor.text.base#ffffff#273540#F2F4F5#273540#10141A#F2F4F5Roughly 1.2:1 instead of the ~15:1 the paired token gives.
99746bfa5then made the a11y check run across canvas + light + dark rather than canvas only, which turned it into a suite failure.Fixed by setting
colorfromtext.basenext to the background, on both<html>and<body>(the body needs it for the samecapture: 'fullPage'reason the existing comment describes for the background).Commit 2 — remove hardcoded colors from three demo pages
custom-iconstext-gray-500/text-gray-700small-componentsText color="inherit"inside a hardcoded#AA0000spantooltip<input>with no color, inheriting light text on the UA's white backgroundResult
Verified locally against the full spec, and commit 1's 13 → 6 was independently confirmed by this PR's own CI run.
The remaining 4 are not harness bugs — they need your call
All four are InstUI components sitting on InstUI's own
Viewbackground variants, using the idiomatic pattern yourheadingandprogressbarpages use:<span class="baseButton__children">primary-inverse</span>— inverse Button<a class="view-link">jumps</a>— Linkalert/success/danger/warningvariants with default textTextTwo distinct contrast pairs remain:
The 1.10:1 case looks like a genuine defect:
View background="primary-inverse"appears not to resolve to a dark surface under the light theme whilecolor="primary-inverse"still resolves to white, so the two stop agreeing. That would affect any consumer using inverse variants on the light theme, not just this suite. See the detailed comment.I deliberately have not forced these green. The only way to do that from the harness is to override the text colors on your components inside the demos, which would hide the behaviour rather than fix it. I tried the non-invasive route first — passing
style={{ background: ... }}to the wrappingView— and it's a no-op, sincestyleisn't in View'sallowedProps.Happy to go either way: tell me the inverse tokens are working as intended and I'll adjust the demos to suit, or leave these red until the tokens are addressed.
Context
Found while chasing red CI on #2666 and #2667 (two unrelated 11.7.4 regression fixes). Both add zero violations of their own and are blocked behind this job.