/* =========================================================================== BGL-3569 - contrast fixes that are NOT dark-mode-specific =========================================================================== bg-dark.css is scoped entirely to html.bg-dark-mode, so it can only ever fix the dark theme. Everything here is either light-mode-only or applies to both, which is why it is a separate file rather than more of that one. Two rules for reading this file: 1. Anything light-specific is scoped `html:not(.bg-dark-mode)`. The dark theme has been measured screen by screen and every value in it is accounted for; nothing here is allowed to move it. 2. Colours come from the brand guide (Battleground Brand Colours, April 2024), not from picking a darker shade until a number passed: Victory #00a886 Earth #ac937d Sky #a7d3d3 Grass #e6ecd1 Clarity #fbf6ea Steel #5e8a8a Rich Black #000104 AI Pink #FF57BE The guide says plainly that **Rich Black is the primary font colour**, and that core colours may carry text "for headlines and callouts" - i.e. large text, where 1.4.3 asks 3:1 rather than 4.5:1. That single line resolves most of what follows. The light theme had white text sitting on brand fills - white on Victory is 3.02:1, on the teal badge 2.30:1, on the danger red 3.37:1 - and the fix is not to darken the brand colour but to use the ink the brand already specifies. Rich Black clears AA on every core colour: Victory 6.88 Earth 7.13 Steel 5.42 AI Pink 7.31 Sky, Grass, Clarity all far higher The dark theme reached the same answer independently: --bg-on-brand is #000104, which is Rich Black. The two halves agree. The one place the guide does not answer is brand colour used as SMALL text on a light ground - Victory is 3.06:1 on white, fine for a headline and short of AA for a link. Rather than invent a shade, this reuses the darkened Victory the dark theme already carries as --bg-teal-nav (#007e65), which is 5.05:1 on white. Same hue, and a value already in the codebase rather than a fourth copy of the teal. =========================================================================== */ :root { --bg-rich-black: #000104; --bg-victory: #00a886; /* Victory darkened for small text on a light ground. Same value the dark theme uses for the nav fill, deliberately - see the note above. */ --bg-victory-text: #007e65; /* The same tone doing the other job: the fill of an INTERACTIVE element - a filled button, a badge - chosen so white ink clears AA on it (5.05:1). Named separately from --bg-victory-text because they are two different decisions that happen to land on one value today; if the text tone ever moves, the button tone should not follow it by accident. */ --bg-victory-action: #007e65; /* Metronic's danger red darkened in its own hue until white clears AA: #F4516C is 3.37:1 against white, this is 5.57:1. */ --bg-danger-action: #c0304a; /* A neutral that clears AA on the light chrome. Metronic's own greys here (#a9a9aa, #a4a2bb, #a7a9c1) are 2.2-2.5:1 and were never adjusted. Pitched just past the 4.5:1 line rather than well past it - these are secondary text and secondary icons, and the first value here was 5.05:1, which made them louder than the content. "Just past" measured against the surface they actually sit on. The value before this one was #757577, chosen off a calculation against WHITE and landing at 4.41:1 on the footer's #FAFAFA - under the line, by a margin small enough that only the measurement caught it. This is 4.75:1 there and 4.94:1 on white. */ --bg-muted-ink: #707072; } /* --------------------------------------------------------------------------- 1. Focus visible - BOTH themes (WCAG 2.1 AA, 2.4.7) Metronic ships `html a, html button { outline: none !important }`, so until now nothing in the app drew a focus ring except the dark-mode toggle, which restored one for itself. Keyboard users had no visible focus anywhere. The shape follows the toggle's, which is the house pattern and already reviewed: paint the ring on :focus, then remove it again on :focus:not(:focus-visible). A browser without :focus-visible support keeps the first rule and shows a ring on mouse clicks - visually noisy, but it fails SAFE rather than failing invisible, which is the right way round. Ring colours are checked against 1.4.11's 3:1 for the surfaces they land on: #007e65 is 5.05:1 on white and 4.86:1 on #FAFAFA; #14be9c is 6.8:1 on the dark card. Full Victory was measured first and is 2.90:1 on #FAFAFA - it would have been a focus indicator that itself failed the criterion it exists to satisfy. --------------------------------------------------------------------------- */ html a:focus, html button:focus, html input:focus, html select:focus, html textarea:focus, html summary:focus, html [tabindex]:focus, html [role="button"]:focus, html [role="tab"]:focus, html [role="link"]:focus, html [role="menuitem"]:focus, html [role="checkbox"]:focus, html [role="option"]:focus { outline: 2px solid var(--bg-victory-text) !important; outline-offset: 2px !important; } html a:focus:not(:focus-visible), html button:focus:not(:focus-visible), html input:focus:not(:focus-visible), html select:focus:not(:focus-visible), html textarea:focus:not(:focus-visible), html summary:focus:not(:focus-visible), html [tabindex]:focus:not(:focus-visible), html [role="button"]:focus:not(:focus-visible), html [role="tab"]:focus:not(:focus-visible), html [role="link"]:focus:not(:focus-visible), html [role="menuitem"]:focus:not(:focus-visible), html [role="checkbox"]:focus:not(:focus-visible), html [role="option"]:focus:not(:focus-visible) { outline: none !important; } html.bg-dark-mode a:focus, html.bg-dark-mode button:focus, html.bg-dark-mode input:focus, html.bg-dark-mode select:focus, html.bg-dark-mode textarea:focus, html.bg-dark-mode summary:focus, html.bg-dark-mode [tabindex]:focus, html.bg-dark-mode [role="button"]:focus, html.bg-dark-mode [role="tab"]:focus, html.bg-dark-mode [role="link"]:focus, html.bg-dark-mode [role="menuitem"]:focus, html.bg-dark-mode [role="checkbox"]:focus, html.bg-dark-mode [role="option"]:focus { outline-color: #14be9c !important; } /* A text input already shows focus by other means and sits inside dense forms where an offset ring collides with its neighbours. Keep the ring, drop the offset so it hugs the field. */ html input:focus, html select:focus, html textarea:focus { outline-offset: 0 !important; } /* --------------------------------------------------------------------------- 2. Light mode - move the TONE, not the ink The first version of this section flipped white ink to Rich Black wherever white failed on a brand fill, and cited the brand guide's "Rich Black should be used as primary font colour" for it. That was the wrong reading, and the result was a light theme that had quietly become a high-contrast theme: black labels on teal buttons, black on the tan pills, black on the red chip. Reported as "light mode isn't as nice as it was", which it wasn't. Two corrections. The guide's line is about body copy. Its own artwork puts WHITE on Victory - the tagline lockup is white on a Victory bar - so the brand plainly does reverse text out of its own fills. And the arithmetic is kinder than it looked. White on Victory is 3.02:1, which PASSES 1.4.3 for large text and fails only below 24px (or 18.66px bold). So the defect was never "white on Victory"; it was "white on Victory at 13px button-label size". Fixing that at the ink end was fixing the wrong end. What every mature system does instead: the brand hex stays the brand hex for headlines and fills, and the INTERACTIVE role gets a derived, darker tone picked so white clears AA on it. Material, Carbon, Lightning and GOV.UK all work this way. So white ink comes back, and the fill moves to --bg-victory-action (#007e65) - which is not a new colour: it is the tone this app already uses for the active nav item, carrying white at 5.03:1. The exception, and it is a real one: a fill that is genuinely LIGHT cannot carry white at any tone. Earth (#AC937D) is 2.91:1 against white and would have to stop being Earth to fix that. Those keep Rich Black - see section 3. --------------------------------------------------------------------------- */ /* The notification count on the topbar bell: white on #34BFA3 was 2.30:1. Also brings the badge onto Victory rather than Metronic's own off-brand teal, which it should arguably have been all along. */ html:not(.bg-dark-mode) .m-badge--new, html:not(.bg-dark-mode) .m-topbar .m-topbar__nav .m-nav__item .m-nav__link .badge, html:not(.bg-dark-mode) #bell_badge { background-color: var(--bg-victory-action) !important; color: #ffffff !important; } /* Metronic's danger badge - the "LOCAL" environment chip and every status pill that uses it: white on #F4516C was 3.37:1. Darkened in its own hue so it still reads as the same red, and white returns at 5.57:1. 11px BOLD, which is worth stating because bold only counts as large text at 18.66px and up - so this needs the full 4.5:1, not 3:1. */ html:not(.bg-dark-mode) .m-badge.m-badge--danger, html:not(.bg-dark-mode) .m-badge--wide.m-badge--danger { background-color: var(--bg-danger-action) !important; } html:not(.bg-dark-mode) .m-badge.m-badge--danger, html:not(.bg-dark-mode) .m-badge.m-badge--danger a, html:not(.bg-dark-mode) .m-badge.m-badge--danger span, html:not(.bg-dark-mode) .m-badge--wide.m-badge--danger { color: #ffffff !important; } /* The sidebar item under the pointer fills with Victory and kept white text at 3.02:1. The ACTIVE item is a different case and is left alone: it fills with Victory darkened 25%, where white is 5.03:1 and already passes - which is also what keeps hover and active telling apart. The selector has to out-specify bog.css, which sets the white. Its rule is .m-aside-menu.m-aside-menu--skin-dark .m-menu__nav > .m-menu__item :not(--parent):not(--open):not(--expanded):not(--active):hover > .m-menu__link .m-menu__link-text { color: #fff !important } and each `:not()` argument counts, so it scores eleven classes. A short, readable `.m-aside-menu .m-menu__item:hover .m-menu__link-text` scores seven, carries !important, looks correct in the source and does nothing at all - which is exactly how the first version of this rule behaved. So the chain is mirrored, and `html:not(.bg-dark-mode)` supplies the margin. The second selector covers the ACTIVE item, which bog.css deliberately excludes and which therefore keeps white on Victory when hovered. */ html:not(.bg-dark-mode) .m-aside-menu.m-aside-menu--skin-dark .m-menu__nav > .m-menu__item:not(.m-menu__item--parent):not(.m-menu__item--open):not(.m-menu__item--expanded):not(.m-menu__item--active):hover > .m-menu__link .m-menu__link-text, html:not(.bg-dark-mode) .m-aside-menu.m-aside-menu--skin-dark .m-menu__nav > .m-menu__item:not(.m-menu__item--parent):not(.m-menu__item--open):not(.m-menu__item--expanded):not(.m-menu__item--active):hover > .m-menu__link .m-menu__link-icon, html:not(.bg-dark-mode) .m-aside-menu.m-aside-menu--skin-dark .m-menu__nav > .m-menu__item:not(.m-menu__item--parent):not(.m-menu__item--open):not(.m-menu__item--expanded):not(.m-menu__item--active):hover > .m-menu__link .m-menu__ver-arrow, html:not(.bg-dark-mode) .m-aside-menu.m-aside-menu--skin-dark .m-menu__nav > .m-menu__item.m-menu__item--active:hover > .m-menu__link .m-menu__link-text, html:not(.bg-dark-mode) .m-aside-menu.m-aside-menu--skin-dark .m-menu__nav > .m-menu__item.m-menu__item--active:hover > .m-menu__link .m-menu__link-icon, html:not(.bg-dark-mode) .m-aside-menu.m-aside-menu--skin-dark .m-menu__nav > .m-menu__item.m-menu__item--active:hover > .m-menu__link .m-menu__ver-arrow, html:not(.bg-dark-mode) .m-aside-menu.m-aside-menu--skin-dark .m-menu__nav .m-menu__submenu .m-menu__item:not(.m-menu__item--active):hover > .m-menu__link .m-menu__link-text { color: #ffffff !important; } /* ...and the states that chain deliberately excludes. An OPEN parent and the `--parent` item inside its submenu are outside bog.css's `:not()` list, so nothing there sets their hover ink and the low-specificity `.m-menu__link:hover > .m-menu__link-text` (two classes) supplies the white instead. Keyed on the hovered LINK rather than on the item's state, so it holds whatever combination of --open / --parent / --expanded the item is in. Eight classes is enough to beat that rule and not enough to disturb the chain above, which is what should win for an ordinary item. */ html:not(.bg-dark-mode) .m-aside-menu.m-aside-menu--skin-dark .m-menu__nav .m-menu__item > .m-menu__link:hover .m-menu__link-text, html:not(.bg-dark-mode) .m-aside-menu.m-aside-menu--skin-dark .m-menu__nav .m-menu__item > .m-menu__link:hover .m-menu__link-icon, html:not(.bg-dark-mode) .m-aside-menu.m-aside-menu--skin-dark .m-menu__nav .m-menu__item > .m-menu__link:hover .m-menu__ver-arrow, html:not(.bg-dark-mode) .m-aside-menu.m-aside-menu--skin-dark .m-menu__nav .m-menu__item > .m-menu__link:hover .m-menu__link-bullet > span { color: #ffffff !important; } /* The bullet dot is drawn as a filled SPAN, so it needs `background-color` rather than `color` - and that declaration belongs ONLY to the bullet. Putting it on the block above, which also lists .m-menu__link-text and .m-menu__link-icon, painted every hovered LABEL with a white background: white text on a white box, 1:1, on the row under the pointer. Adding a declaration to a shared selector list gives it to every selector in the list, which is obvious written down and was not obvious while typing it. */ html:not(.bg-dark-mode) .m-aside-menu.m-aside-menu--skin-dark .m-menu__nav .m-menu__item > .m-menu__link:hover .m-menu__link-bullet > span { background-color: #ffffff !important; } /* The fill those white inks sit on. style.blade.php fills a hovered item with Victory at full strength, where white is 3.02:1. Pinned to the same --bg-victory-action the ACTIVE item already uses, so white returns at 5.03:1 and the sidebar has one teal rather than two. That does make a hovered item the same colour as the active one. It is not a loss worth solving with a third tone: the active item is still teal when your pointer is elsewhere, and the one under the cursor is the one that moves with it. If the two ever need separating, the answer is a left edge or a weight change rather than another shade of Victory to keep in step. */ html:not(.bg-dark-mode) .m-aside-menu.m-aside-menu--skin-dark .m-menu__nav > .m-menu__item:not(.m-menu__item--parent):not(.m-menu__item--open):not(.m-menu__item--expanded):not(.m-menu__item--active):hover, html:not(.bg-dark-mode) .m-aside-menu.m-aside-menu--skin-dark .m-menu__nav > .m-menu__item:not(.m-menu__item--parent):not(.m-menu__item--open):not(.m-menu__item--expanded):not(.m-menu__item--active):hover > .m-menu__link, html:not(.bg-dark-mode) .m-aside-menu.m-aside-menu--skin-dark .m-menu__nav .m-menu__submenu .m-menu__item:not(.m-menu__item--parent):not(.m-menu__item--open):not(.m-menu__item--expanded):not(.m-menu__item--active):hover, html:not(.bg-dark-mode) .m-aside-menu.m-aside-menu--skin-dark .m-menu__nav .m-menu__submenu .m-menu__item:not(.m-menu__item--parent):not(.m-menu__item--open):not(.m-menu__item--expanded):not(.m-menu__item--active):hover > .m-menu__link, html:not(.bg-dark-mode) .m-aside-menu.m-aside-menu--skin-dark .m-menu__nav .m-menu__item > .m-menu__link:hover { background-color: var(--bg-victory-action) !important; } /* The bullet dot on the ACTIVE submenu item, which is drawn in full Victory on that item's darker Victory fill: 1.66:1, so it reads as a missing bullet on the one row that has a fill. Not a 1.4.11 failure - every row has a bullet, so it carries no state of its own and losing it costs no information - but it looks like a rendering fault, and white matches the label beside it. */ html:not(.bg-dark-mode) .m-aside-menu.m-aside-menu--skin-dark .m-menu__nav .m-menu__submenu .m-menu__item.m-menu__item--active > .m-menu__link .m-menu__link-bullet > span, html:not(.bg-dark-mode) .m-aside-menu.m-aside-menu--skin-dark .m-menu__nav > .m-menu__item.m-menu__item--active > .m-menu__link .m-menu__link-bullet > span { background-color: #ffffff !important; } /* The secondary button's hover is handled with the rest of the buttons below, by deepening the fill rather than darkening the ink - its Steel fill is too dark for Rich Black. */ /* Action buttons on a brand fill - the "BIA List" / "Audit" pair at the top of a record, and every button that shares their classes. The first version of this rule set the ICON and forgot the LABEL, so the buttons rendered with a near-black glyph beside white text and looked broken - reported, correctly, as looking odd. A button is one object; its glyph and its label have to agree, and the way to write that is to set `color` on the button and let the icon inherit rather than to name the icon separately. White is not an option here, on any of them. It fails on every core colour in the brand palette, not just these two: Victory #00a886 3.02:1 Steel #5e8a8a 3.83:1 Earth #ac937d 2.91:1 Sky, Grass, Clarity far lower ...at FULL STRENGTH. That is the sentence the first version of this rule was missing, and it concluded from the table that no white-text version of these buttons could pass, so the ink had to go dark. Both of those buttons then rendered as black-on-brand and light mode read as a high-contrast theme. The table is right and the conclusion was wrong: the fill does not have to stay at full strength. Darkening the tone of an interactive element until white clears AA is what design systems do, and it leaves the brand hex untouched everywhere it is actually a brand mark. So these split by the only question that matters - can this fill carry white at ANY tone of itself? .btn-success / .btn-primary / .btn-accent Victory family, mid-tone. Yes. The fill moves to --bg-victory-action (5.05:1 with white), which is the tone the active nav item already uses. This is the pair the "New BIA" button was reported on. .btn-default (m-btn--air) Earth, #AC937D, genuinely light. No. White is 2.91:1 on Earth and every tone of Earth light enough to still be Earth is worse. Keeps Rich Black at 7.18:1. Next to a filled primary this reads as an ordinary primary/secondary pair rather than as two high-contrast buttons. .btn-danger, .btn-warning and .btn-info are deliberately left out: their fills are not brand colours, bg-dark.css records that near-black on them is wrong once a theme has neutralised them, and they have not been measured here. */ html:not(.bg-dark-mode) .btn.btn-success, html:not(.bg-dark-mode) .btn.btn-primary, html:not(.bg-dark-mode) .btn.btn-accent { background-color: var(--bg-victory-action) !important; border-color: var(--bg-victory-action) !important; } html:not(.bg-dark-mode) .btn.btn-success, html:not(.bg-dark-mode) .btn.btn-success i, html:not(.bg-dark-mode) .btn.btn-success span, html:not(.bg-dark-mode) .btn.btn-primary, html:not(.bg-dark-mode) .btn.btn-primary i, html:not(.bg-dark-mode) .btn.btn-primary span, html:not(.bg-dark-mode) .btn.btn-accent, html:not(.bg-dark-mode) .btn.btn-accent i, html:not(.bg-dark-mode) .btn.btn-accent span { color: #ffffff !important; } html:not(.bg-dark-mode) .btn.m-btn--air.btn-default, html:not(.bg-dark-mode) .btn.m-btn--air.btn-default i, html:not(.bg-dark-mode) .btn.m-btn--air.btn-default span { color: var(--bg-rich-black) !important; } /* .btn-secondary is NOT in that list, and the reason is worth keeping. It was, briefly. style.css pins it to a Steel background, but a DARK one - #507676, not the #5e8a8a from the palette - and on that fill white is already 5.00:1 while Rich Black is only 4.17:1. Adding it here made the Column Chooser / Excel / Delete / Archive row WORSE than it started, which is precisely the trap bg-dark.css warns about a few hundred lines up: this treatment is only right while the fill is still a light brand colour. Its hover is the one real failure: the fill goes to #00876C and white lands at 4.49:1, which is short of AA by a rounding error and still short. Fixed by deepening the hover along the same Steel hue rather than flipping the ink, so the button does not change ink colour halfway through an interaction. */ html:not(.bg-dark-mode) .btn.btn-secondary:hover, html:not(.bg-dark-mode) .btn.btn-secondary:focus, html:not(.bg-dark-mode) .btn.btn-secondary:hover:not(:disabled):not(.active), html:not(.bg-dark-mode) .btn.btn-secondary:focus:not(:disabled):not(.active) { background-color: #3f5c5c !important; color: #ffffff !important; } html:not(.bg-dark-mode) .btn.btn-secondary:hover i, html:not(.bg-dark-mode) .btn.btn-secondary:hover span, html:not(.bg-dark-mode) .btn.btn-secondary:focus i, html:not(.bg-dark-mode) .btn.btn-secondary:focus span, html:not(.bg-dark-mode) .btn.btn-secondary:hover:not(:disabled):not(.active) i, html:not(.bg-dark-mode) .btn.btn-secondary:hover:not(:disabled):not(.active) span { color: #ffffff !important; } /* Hover and focus, where every one of these buttons ends up on a Victory tone and so takes white ink - see the fill rule below this one. The job of this rule is to make the ink agree across the whole control, and to beat Metronic's own :hover rules, which would otherwise recolour the icon alone and put the button back into the half-and-half state. The `:not(:disabled):not(.active)` chain is Metronic's, mirrored rather than copied for neatness. Its rule is .btn.m-btn--air.btn-default:hover:not(:disabled):not(.active) i { color: #fff !important } and both `:not()` arguments count, so it scores six classes to the five that `html:not(.bg-dark-mode) …:hover i` scores. Without the chain this rule reads as correct, carries !important, and loses - the icon went white again on hover while the label stayed dark, which is the same half-and-half state one interaction later. Second time this file has been caught by a Metronic `:not()` chain; the menu rules further up were the first. */ html:not(.bg-dark-mode) .btn.m-btn--air.btn-default:hover, html:not(.bg-dark-mode) .btn.m-btn--air.btn-default:hover i, html:not(.bg-dark-mode) .btn.m-btn--air.btn-default:hover span, html:not(.bg-dark-mode) .btn.m-btn--air.btn-default:hover:not(:disabled):not(.active), html:not(.bg-dark-mode) .btn.m-btn--air.btn-default:hover:not(:disabled):not(.active) i, html:not(.bg-dark-mode) .btn.m-btn--air.btn-default:hover:not(:disabled):not(.active) span, html:not(.bg-dark-mode) .btn.m-btn--air.btn-default:focus, html:not(.bg-dark-mode) .btn.m-btn--air.btn-default:focus i, html:not(.bg-dark-mode) .btn.m-btn--air.btn-default:focus span, html:not(.bg-dark-mode) .btn.m-btn--air.btn-default:focus:not(:disabled):not(.active), html:not(.bg-dark-mode) .btn.m-btn--air.btn-default:focus:not(:disabled):not(.active) i, html:not(.bg-dark-mode) .btn.m-btn--air.btn-default:focus:not(:disabled):not(.active) span, html:not(.bg-dark-mode) .btn.btn-success:hover:not(:disabled):not(.active), html:not(.bg-dark-mode) .btn.btn-success:hover:not(:disabled):not(.active) i, html:not(.bg-dark-mode) .btn.btn-success:hover:not(:disabled):not(.active) span, html:not(.bg-dark-mode) .btn.btn-primary:hover:not(:disabled):not(.active), html:not(.bg-dark-mode) .btn.btn-primary:hover:not(:disabled):not(.active) i, html:not(.bg-dark-mode) .btn.btn-primary:hover:not(:disabled):not(.active) span, html:not(.bg-dark-mode) .btn.btn-accent:hover:not(:disabled):not(.active), html:not(.bg-dark-mode) .btn.btn-accent:hover:not(:disabled):not(.active) i, html:not(.bg-dark-mode) .btn.btn-accent:hover:not(:disabled):not(.active) span, html:not(.bg-dark-mode) .btn.btn-success:hover, html:not(.bg-dark-mode) .btn.btn-success:hover i, html:not(.bg-dark-mode) .btn.btn-success:hover span, html:not(.bg-dark-mode) .btn.btn-success:focus, html:not(.bg-dark-mode) .btn.btn-success:focus i, html:not(.bg-dark-mode) .btn.btn-success:focus span, html:not(.bg-dark-mode) .btn.btn-primary:hover, html:not(.bg-dark-mode) .btn.btn-primary:hover i, html:not(.bg-dark-mode) .btn.btn-primary:hover span, html:not(.bg-dark-mode) .btn.btn-primary:focus, html:not(.bg-dark-mode) .btn.btn-primary:focus i, html:not(.bg-dark-mode) .btn.btn-primary:focus span, html:not(.bg-dark-mode) .btn.btn-accent:hover, html:not(.bg-dark-mode) .btn.btn-accent:hover i, html:not(.bg-dark-mode) .btn.btn-accent:hover span, html:not(.bg-dark-mode) .btn.btn-accent:focus, html:not(.bg-dark-mode) .btn.btn-accent:focus i, html:not(.bg-dark-mode) .btn.btn-accent:focus span { color: #ffffff !important; } /* ...and the fill they are white ON. Every one of these buttons - Earth included - already swings to a Victory tone on hover, because style.blade.php sets `.btn:hover { background-color: adjustBrightness(victory, -0.2) }` for all of them. That hue change on hover is existing behaviour and not something this file introduces; what it does mean is that the Earth button cannot keep Rich Black through hover, because the surface under it stops being Earth. So the hover fill is pinned to the same --bg-victory-action as the filled buttons at rest, and the ink is white throughout. Victory darkened 20% would have carried white at 4.55:1 - passing, but by half a point, and dependent on a tenant's configured Victory. Pinning the tone puts it at 5.05:1 and makes it the same colour the primary buttons already are. */ html:not(.bg-dark-mode) .btn.m-btn--air.btn-default:hover, html:not(.bg-dark-mode) .btn.m-btn--air.btn-default:focus, html:not(.bg-dark-mode) .btn.m-btn--air.btn-default:hover:not(:disabled):not(.active), html:not(.bg-dark-mode) .btn.btn-success:hover, html:not(.bg-dark-mode) .btn.btn-success:focus, html:not(.bg-dark-mode) .btn.btn-success:hover:not(:disabled):not(.active), html:not(.bg-dark-mode) .btn.btn-primary:hover, html:not(.bg-dark-mode) .btn.btn-primary:focus, html:not(.bg-dark-mode) .btn.btn-primary:hover:not(:disabled):not(.active), html:not(.bg-dark-mode) .btn.btn-accent:hover, html:not(.bg-dark-mode) .btn.btn-accent:focus, html:not(.bg-dark-mode) .btn.btn-accent:hover:not(:disabled):not(.active) { background-color: var(--bg-victory-action) !important; border-color: var(--bg-victory-action) !important; } /* The tag pills in a register - business unit, geography, department. They fill with Earth and carried white text at 2.91:1, ten to a screen. Same treatment and same reason as the buttons above; --bg-on-brand in dark mode already inks them this way. These only surfaced once a table had rows in it. An audit of an empty grid is an audit of nothing, which is a lesson this ticket has now taught twice. */ html:not(.bg-dark-mode) .m-badge--metal, html:not(.bg-dark-mode) .m-badge--metal a, html:not(.bg-dark-mode) span.m-badge.m-badge--metal, html:not(.bg-dark-mode) td .m-badge.m-badge--wide { color: var(--bg-rich-black) !important; } /* Hovering a register row fills it with Victory and left the cell text white at 3.02:1 - a whole row of data, and only while the pointer is on it. The dark theme hit the identical defect on expired rows. The fill is tenant-driven (`table_row_hover_bg`), so the ink moves, not the fill. */ html:not(.bg-dark-mode) .dataTables_wrapper table tbody tr:hover, html:not(.bg-dark-mode) .dataTables_wrapper table tbody tr:hover td, html:not(.bg-dark-mode) .dataTables_wrapper table tbody tr:hover td a, html:not(.bg-dark-mode) .dataTables_wrapper table tbody tr:hover td span, html:not(.bg-dark-mode) .m-datatable__row:hover .m-datatable__cell, html:not(.bg-dark-mode) .m-datatable__row:hover .m-datatable__cell span { color: var(--bg-rich-black) !important; } /* The sorted column heading is Steel on the #F0F0F0 header strip: 3.36:1. Steel is a brand colour but this is small body text, so it takes the same darkened treatment as Victory does elsewhere in this file. */ html:not(.bg-dark-mode) .m-datatable__cell.sorting_asc, html:not(.bg-dark-mode) .m-datatable__cell.sorting_desc, html:not(.bg-dark-mode) th.m-datatable__cell.sorting_asc span, html:not(.bg-dark-mode) th.m-datatable__cell.sorting_desc span, html:not(.bg-dark-mode) th.m-datatable__cell.sorting_asc, html:not(.bg-dark-mode) th.m-datatable__cell.sorting_desc { color: #3f5c5c !important; } /* --------------------------------------------------------------------------- 3. RAiDAR - AI Pink, in BOTH themes `#fdf2f8` on `#FF57BE` is 2.61:1. The dark theme already inks this surface with Rich Black at 7.31:1; light mode was still on the near-white and had simply never been measured. Unscoped, so the two agree by construction. --------------------------------------------------------------------------- */ .global-raidar-chat-button, .global-raidar-chat-button .m-nav__link-text, .global-raidar-chat-button i, .global-raidar-chat-button svg { color: var(--bg-rich-black) !important; } .global-raidar-chat-refresh-icon svg, .global-raidar-chat-refresh-icon svg *, .global-raidar-chat-settings-icon svg, .global-raidar-chat-settings-icon svg * { stroke: currentColor !important; } .global-raidar-chat-settings-icon svg [fill]:not([fill='none']), .global-raidar-chat-refresh-icon svg [fill]:not([fill='none']) { fill: currentColor !important; } /* --------------------------------------------------------------------------- 4. Light mode - Metronic's own greys, which were never retuned These are stock Metronic values sitting on Battleground's lighter chrome (#FAFAFA rather than Metronic's white), so they read a little worse here than they did in the theme they shipped with. All three are secondary text or secondary icons; --bg-muted-ink keeps them secondary and clears AA. --------------------------------------------------------------------------- */ html:not(.bg-dark-mode) .m-footer .m-footer__copyright, html:not(.bg-dark-mode) .m-footer .m-footer__copyright a:not(.m-link) { color: var(--bg-muted-ink) !important; } html:not(.bg-dark-mode) .m-aside-menu.m-aside-menu--skin-dark .m-menu__nav > .m-menu__section .m-menu__section-icon { color: var(--bg-muted-ink) !important; } html:not(.bg-dark-mode) .m-list-search .m-list-search__form .m-list-search__form-input-wrapper .m-list-search__form-icon, html:not(.bg-dark-mode) .m-input-icon .m-input-icon__icon i, html:not(.bg-dark-mode) .la-search { color: var(--bg-muted-ink) !important; } /* --------------------------------------------------------------------------- 5. Light mode - Victory as small text `.m-link` is the footer's "Battleground" link and a general link class: 2.90:1 on #FAFAFA. Headline use of Victory is untouched, which is the use the brand guide actually sanctions. --------------------------------------------------------------------------- */ html:not(.bg-dark-mode) .m-link, html:not(.bg-dark-mode) a.m-link { color: var(--bg-victory-text) !important; } /* The same colour doing the same job on the profile tab strip - "Update Profile", "Security", "Appearance", "Two Factor Authentication" - which go Victory on hover at 3.02:1. Found only once the profile page itself was swept, which happened because the appearance control moved there: a page nobody had audited had its own instance of the defect the rest of this file is about. */ html:not(.bg-dark-mode) .m-tabs__link:hover, html:not(.bg-dark-mode) a.m-tabs__link:hover, html:not(.bg-dark-mode) .m-tabs-line .m-tabs__link:hover, html:not(.bg-dark-mode) .nav.nav-tabs .nav-link:hover { color: var(--bg-victory-text) !important; } /* Form help text - "All mobile numbers should start with...". Metronic's `m--font-info` resolves to Victory here, so it is the same 3.02:1 as every other use of the brand teal at body size. */ html:not(.bg-dark-mode) .m-form__help.m--font-info, html:not(.bg-dark-mode) .m-form__help, html:not(.bg-dark-mode) .m--font-info { color: var(--bg-victory-text) !important; } /* --------------------------------------------------------------------------- 6. Light mode - two more the profile page turned up Both pre-existing, and both found only because the appearance control moved to this page and it got swept for the first time. --------------------------------------------------------------------------- */ /* select2's placeholder, #9699A2 on the #F4F5F8 field: 2.61:1. A placeholder is text and 1.4.3 applies to it. */ html:not(.bg-dark-mode) .select2-selection__placeholder, html:not(.bg-dark-mode) .select2-container--default .select2-selection__placeholder { color: var(--bg-muted-ink) !important; } /* Metronic's form section headings - "1. Personal Details" - are #7B7E8A on white, 4.04:1. Under the line, and not large enough to qualify for the 3:1 that would have excused it. Kept deliberately soft rather than promoted to ink: it was a muted heading by design and --bg-muted-ink is 4.94:1, so the character survives and the contrast clears. */ html:not(.bg-dark-mode) .m-form__section, html:not(.bg-dark-mode) h3.m-form__section { color: var(--bg-muted-ink) !important; } /* The SCIM notice - "Your profile details are under management by your organisation" - is white on Steel at 3.83:1. Steel is a core colour and the fill stays; Rich Black on it is 5.42:1, which is the figure from the brand table. bg-dark.css already inks this notice with --bg-on-brand in dark mode, so this is the light half of a decision already taken. */ html:not(.bg-dark-mode) .bg-scim-notice, html:not(.bg-dark-mode) .bg-scim-notice a, html:not(.bg-dark-mode) .bg-scim-notice span { color: var(--bg-rich-black) !important; } /* Metronic paints hovered nav text its stock indigo #716ACA - 4.36:1 on the light footer, 3.62:1 on the dark one. Off-palette in both, and short of AA in both. Dark mode answers this in bg-dark.css; this is the light half. The RAiDAR button is excluded - it carries a brand fill and its own ink. */ html:not(.bg-dark-mode) .m-footer .m-nav .m-nav__item:hover > .m-nav__link:not(.global-raidar-chat-button) .m-nav__link-text, html:not(.bg-dark-mode) .m-topbar .m-nav .m-nav__item:hover > .m-nav__link:not(.global-raidar-chat-button) .m-nav__link-text { color: var(--bg-victory-text) !important; } /* Victory on the pale teal wash the topbar buttons use for hover and focus is 2.63:1. The wash is a tint of the brand and worth keeping, so the ink moves instead: Rich Black on #E4F2F2 is 17.8:1. */ html:not(.bg-dark-mode) .m-topbar .m-nav .bg-feedback-btn:hover, html:not(.bg-dark-mode) .m-topbar .m-nav .bg-feedback-btn:focus, html:not(.bg-dark-mode) .bg-feedback-btn:hover, html:not(.bg-dark-mode) .bg-feedback-btn:focus, html:not(.bg-dark-mode) .bg-feedback-btn:hover i, html:not(.bg-dark-mode) .bg-feedback-btn:focus i, html:not(.bg-dark-mode) .bg-feedback-btn:hover .bg-feedback-btn__label, html:not(.bg-dark-mode) .bg-feedback-btn:focus .bg-feedback-btn__label { color: var(--bg-rich-black) !important; } /* ...and the same two buttons at REST, which the block above does not cover. Victory on the topbar's #FBFBFB is 2.93:1 - short for the label at 4.5:1 and, by a hair, for the glyph at 3:1 too. Fixing only hover and focus was the first pass here; resting state is the one a user actually looks at. */ html:not(.bg-dark-mode) .bg-feedback-btn, html:not(.bg-dark-mode) .bg-feedback-btn i, html:not(.bg-dark-mode) .bg-feedback-btn .bg-feedback-btn__label, html:not(.bg-dark-mode) .m-topbar .m-nav .bg-feedback-btn { color: var(--bg-victory-text) !important; } /* The pale mint chip behind a module icon: Victory on #DBF3EE is 2.60:1. An icon needs 3:1, and the darkened Victory gives 4.18:1 while still reading as teal-on-teal rather than as a black mark. */ html:not(.bg-dark-mode) .m-widget4__icon i, html:not(.bg-dark-mode) .m-widget-icon i, html:not(.bg-dark-mode) .flaticon-layers { color: var(--bg-victory-text) !important; }