mirror of
https://github.com/lrnselfreliance/wrolpi.git
synced 2026-10-26 19:01:39 -04:00
664c7d2219
The title contrast was verified by hand and by nothing else. jsdom cannot check it: it resolves no `var()`, so the title's colour there is the literal string `var(--mantine-color-white)` and every contrast assertion passes. Six browser tests now cover it -- title and description at WCAG AA in each of the four themes, the title staying heavier than the message where night and amber drop its muting, and the toast taking `--panel` for its surface. The three that can fail were checked against the fix removed: 1.13:1 in dark, night and amber. Light passes either way, correctly, because Mantine's light-scheme title uses `--mantine-color-black`, which the bridge maps to `--text`. Getting there took three corrections, all of them mine: * `cy.mountUI` never set `forceColorScheme`, so every theme rendered against Mantine's LIGHT scheme. Mantine keys its own rules on data-mantine-color-scheme, and ThemeProvider sets it from the theme -- night and amber ride on dark. Any per-theme test could therefore pass on a page that was broken in the app. This is the harness the tag contrast tests use too. * The support file never imported `@mantine/notifications/styles.css`, which App.js does, so a Notification rendered unstyled and had no surface or title colour of Mantine's to be wrong about. * The spec's own helper mounted a second time to raise the toast, which reset the theme to the default. All four per-theme cases ran in light. For the record, the chain the fix breaks: `.m_3feedf16` (the title) in dark scheme is `color: var(--mantine-color-white)`, the bridge aliases that to `--btn-text`, and `--btn-text` is the text drawn on a filled button -- near-black in dark, night and amber. Mantine writes it through `:where(...)`, which has zero specificity, so a single-class override plus `html` outranks it. |
||
|---|---|---|
| .. | ||
| e2e | ||
| fixtures | ||
| support | ||