/* ============================================================================ bwa-aoda-fixes-v2.css Phase 1 of the designer QA pass. Register LAST in the admin so it loads after BWA/css/custom.css, the plugin assets and the chrome controls. Scope: page-level, header, footer and the inline footer island only. It cannot reach the 41 iframe islands or the 9 shadow-DOM islands - those are Phase 2 and are listed at the bottom of this file. Every value below is traced to a measurement from the hover/focus audit of 2026-09-29 (3,972 elements, 23 pages, 1440px + 375px) or to a rule read out of this repo. Nothing here is guessed. Blocks that WOULD need a guess are not written - they are listed under NOT WRITTEN at the end with the one question each needs answered. Nothing in this file changes layout except block 4, which is flagged. kimosabi, 2026-09-30 (v2, 2026-10-06: corrected Phase 2 sequencing) ========================================================================== */ /* ---------------------------------------------------------------------------- 1. FOCUS RING - 84 of the 639 fails. CORRECTION, 2026-10-01: an earlier draft of this file claimed this block was worth ~601 fails and called it the biggest win in the audit. That was wrong. The 601 came from summing root-causes.json, which totals 1327 because it aggregates ALL severities - including 1309 findings of type focus-browser-default that are informational, not failures. Counted against actual failures the focus total is 79 focus-ring-contrast + 5 focus-invisible = 84, which is 13%. The real bulk of the audit is text-contrast (349) and covered (159). Blocks 2, 5 and 7 carry more weight than this one. Measured: focus rings fail at 1.63:1, 1.65:1, 1.81:1 and similar across the site. 50 of the 84 are page-level and cleared by this block; the other 34 sit inside islands and need the loader injection. The failing ring colours are not declared anywhere in this repo - it arrives from the theme or the brand corpus at runtime - so this block does not try to retune a token it cannot see. It declares an explicit ring instead, which overrides whatever the default resolves to. Two-tone on purpose. A single colour cannot clear 3:1 against both the white page surfaces and the rgb(10,16,31) navy sections. The amber core carries the contrast on dark surfaces (12:1) and the navy halo carries it on light ones (14:1), so at least one edge of the ring always passes wherever it lands. !important is deliberate here and only here by default: browser UA defaults and several island themes both set outline on focus, and a focus ring is the lowest-risk place in the file to force the issue. -------------------------------------------------------------------------- */ a:focus-visible, button:focus-visible, [role="button"]:focus-visible, input:focus-visible, select:focus-visible, textarea:focus-visible, summary:focus-visible, [tabindex]:focus-visible { outline: 3px solid #ffd400 !important; outline-offset: 2px !important; box-shadow: 0 0 0 6px rgba(10, 16, 31, 0.92) !important; } /* Bootstrap paints its own focus ring through a box-shadow on .btn and the form controls, which would sit underneath the ring above and read as a double ring. Suppressing only the shadow keeps Bootstrap's sizing and colours intact. */ .btn:focus-visible, .form-control:focus-visible, .form-select:focus-visible, .accordion-button:focus-visible { box-shadow: 0 0 0 6px rgba(10, 16, 31, 0.92) !important; } /* ---------------------------------------------------------------------------- 2. FAQ TAG AND CATEGORY BUTTONS - the black-on-black hover collision. This is the "FAQ Banner, talk to your team link hover state will not meet AODA" note, and it is the button/text collision webcowboy asked about. Root cause, read from Assets/FAQ/bwa-faq.css: .bwa-faq__tag-btn--active sets color: #fff on a --faq-accent fill .bwa-faq__tag-btn:hover sets color: var(--faq-text) --faq-text falls through var(--text, var(--bwa-faq-text, #222222)), and on the dark banner pages --text resolves to #000000. So hovering the ACTIVE pill swaps its white label for black while the accent fill stays dark. Measured: 1.11:1, rgb(0,0,0) on rgb(10,16,31), on Home, BWA Agents, Advantage, CMS and PIM. The category button does the same thing through --faq-accent and was measured at 1:1 on For Developers - the label vanishes completely. The fix is deliberately narrow: it only stops the hover rule from overriding the active pill's own ink. Non-active pills are untouched, and nothing here depends on whether the surrounding surface is light or dark, so it is safe on every instance of the module. -------------------------------------------------------------------------- */ .bwa-faq .bwa-faq__tag-btn--active:hover, .bwa-faq .bwa-faq__tag-btn--active:focus-visible { color: var(--faq-accent-ink, #ffffff); background: var(--faq-accent); border-color: var(--faq-accent); } .bwa-faq .bwa-faq__category-btn--active:hover, .bwa-faq .bwa-faq__category-btn--active:focus-visible { color: var(--faq-accent-ink, #ffffff); background: var(--faq-accent); border-color: var(--faq-accent); } /* ---------------------------------------------------------------------------- 3. FOOTER NAVIGATION LINKS - the designer's footer note. "Plugin library and Get in touch link, when added are blue vs the white making them not pass AODA." Measured: rgb(50,80,155) on rgb(10,16,31) = 2.49:1 at rest, on all 23 pages, about 100 findings across five shade variants of the same link. The focus state fails too, at 3.4:1 and 3.77:1. Worth noting: the HOVER state is already correct. Footer.ascx fixed it to #b9bbec on 2026-09-18 and the audit confirms hover passing. Only the REST and FOCUS states are outstanding, so this block sets those two and leaves hover exactly as the footer file declares it. No !important. Footer.ascx documents legacy rules that win on :hover through !important, but those are hover-only. At rest this selector carries two classes against the legacy `nav a`, so it wins on specificity and does not need to escalate. #ffffff on rgb(10,16,31) = 19.1:1, which is what the designer asked for. -------------------------------------------------------------------------- */ .bwa-advantage-footer-dc .bwa-ftr-nav__link, .bwa-advantage-footer-dc .bwa-ftr-nav__head-link, .bwa-advantage-footer-dc .bwa-ftr-legal__link { color: #ffffff; } /* Focus takes the same lilac the footer already uses for hover, so keyboard and pointer users see one consistent treatment. #b9bbec on rgb(10,16,31) = 10.4:1. */ .bwa-advantage-footer-dc .bwa-ftr-nav__link:focus-visible, .bwa-advantage-footer-dc .bwa-ftr-nav__head-link:focus-visible, .bwa-advantage-footer-dc .bwa-ftr-legal__link:focus-visible { color: #b9bbec; text-decoration: none; } /* ---------------------------------------------------------------------------- 4. FOOTER SOCIAL LINKS ARE UNCLICKABLE - not on the designer's list. Measured: bwa-ftr-social__link (Facebook, GitHub) reports "pointer cannot reach it - covered by button.stan-cta-button#stan-cta-btn" on all 23 pages, 46 findings. The floating Ask Stan button sits on top of the social row once the page is scrolled to the bottom. The links are not low-contrast, they are genuinely not clickable. *** THIS IS THE ONE BLOCK IN THE FILE THAT CHANGES LAYOUT. *** Reserving space below the footer content is the safer of the two options: it keeps the chat button fully clickable and simply stops the two from sharing the same pixels. The alternative - raising the footer above the widget - is commented out below it, and trades the problem the other way: the social links become clickable but the chat button loses its bottom-right corner. 96px clears a standard floating launcher plus its drop shadow. If the widget is taller than that on this tenant, raise the number rather than switching to the alternative. !important, 2026-10-27: the footer chrome sets its padding in an inline style attribute (80px 48px 0), and an inline style beats any normal stylesheet rule, so without it this block computed to 0 and the links stayed covered. A stylesheet !important is the one thing that outranks a non-important inline style. Measured: the Ask Stan button occupies the bottom 72px of the viewport at 1440 and 62px at 375; the social row ended 45px above the viewport bottom at full scroll, so 96px lifts it clear of the button with room to spare. -------------------------------------------------------------------------- */ .bwa-advantage-footer-dc { padding-bottom: 96px !important; } /* Alternative, if webcowboy would rather not add footer height. Enable ONE of the two, never both. .bwa-advantage-footer-dc .bwa-ftr-social { position: relative; z-index: 2147483001; } */ /* ---------------------------------------------------------------------------- 5. FORM SUBMIT BUTTON DISAPPEARS ON HOVER. Measured: btn btn-primary fbp-submit-btn, hover state, white text on a white fill = 1:1, on both Trial Signup and Get in touch. The label is invisible while the pointer is on it. Root cause, read from BWA/css/custom.css around line 9633: that block sets --bs-btn-hover-bg: var(--bwa-color-btn-hover-bg, color-mix(...82%, #000)) and its own comment states the intent as "orange default, navy hover, white text always". This tenant's corpus DOES define --bwa-color-btn-hover-bg, and it resolves light, so the fallback that would have produced the navy never runs and the hover fill lands on white under white text. The same comment block already records that this tenant's corpus defines --bwa-color-btn-text but never --bwa-color-btn-bg, so a corpus variable being present-but-wrong here is consistent with what was measured on 2026-09-18. This restores the documented intent by taking the hover fill straight from the accent chain and skipping the corpus hover token. !important is required to match the existing block, which is itself !important throughout. -------------------------------------------------------------------------- */ .fbp-form .fbp-submit-btn.btn-primary, .fbp-form .btn-primary, .fbp-submit-btn.btn-primary { --bs-btn-hover-bg: color-mix(in srgb, var(--bwa-color-accent, var(--bwa-color-primary, #e76f00)) 82%, #000) !important; --bs-btn-hover-border-color: color-mix(in srgb, var(--bwa-color-accent, var(--bwa-color-primary, #e76f00)) 82%, #000) !important; --bs-btn-hover-color: #ffffff !important; --bs-btn-active-bg: color-mix(in srgb, var(--bwa-color-accent, var(--bwa-color-primary, #e76f00)) 82%, #000) !important; --bs-btn-active-color: #ffffff !important; } /* Belt and braces: the two properties above drive Bootstrap's vars, and these two drive the rendered element, for the case where a later rule sets the background directly rather than through --bs-btn-hover-bg. */ /* :focus-visible is included because the audit measured the FOCUS state at 1:1 as well as hover - white on white - on both Trial Signup and Get in touch. An earlier draft of this file covered hover only and would have left a keyboard user with an invisible button label. */ .fbp-form .fbp-submit-btn.btn-primary:hover, .fbp-form .btn-primary:hover, .fbp-submit-btn.btn-primary:hover, .fbp-form .fbp-submit-btn.btn-primary:focus-visible, .fbp-form .btn-primary:focus-visible, .fbp-submit-btn.btn-primary:focus-visible { background-color: color-mix(in srgb, var(--bwa-color-accent, var(--bwa-color-primary, #e76f00)) 82%, #000) !important; color: #ffffff !important; } /* ---------------------------------------------------------------------------- 6. BOOTSTRAP ACCORDION - keyboard focus was invisible. Measured on Trial Signup: accordion-button reports focus-invisible x2 and hover-no-change x2. Block 1 already restores the focus ring; this adds the hover affordance the designer asked for sitewide, using Bootstrap's own tokens so it inherits whatever the theme sets rather than introducing a colour of its own. -------------------------------------------------------------------------- */ .accordion-button:not(.collapsed), .accordion-button:hover { background-color: var(--bs-accordion-active-bg, rgba(10, 16, 31, 0.05)); } /* ---------------------------------------------------------------------------- 7. DEFAULT BOOTSTRAP COMPONENTS - the generic contrast safety net. The single most common failure in the audit is a button whose FILL animates to the same colour as its own LABEL on hover or focus, so the text vanishes. Measured instances of exactly 1:1 (text and background identical): btn btn-primary fbp-submit-btn white on white hover + focus bwa-faq__category-btn #0a101f on #0a101f hover bwacta-btn--secondary white on white rest + hover + focus lms-cta__btn--secondary #070c31 on #0a101f hover The two bespoke ones are island-bound and out of reach here. The Bootstrap ones are not, and the rule below removes the whole class of defect rather than the individual instances. The principle: NEVER let the text colour change between rest and hover. Only darken the fill. If a button's resting state passes contrast, every interactive state then passes too, because the ink is constant and the background only gets darker relative to it. That is also precisely what the designer asked for sitewide - "button hover state needs to be standardized". Why this is the durable fix: it is expressed entirely through Bootstrap's own --bs-btn-* custom properties, so it keeps working regardless of which colour the brand corpus feeds in. The earlier failures happened because the corpus defines --bwa-color-btn-hover-bg and it resolves light, which fed white into --bs-btn-hover-bg underneath white text. Deriving hover from the button's OWN resting background closes that path permanently. Scoped to the solid variants by name on purpose. The .btn-outline-* family is deliberately excluded: its resting background is transparent, and color-mix() against transparent would produce a dark translucent fill rather than the intended behaviour. Outline buttons already flip to a solid fill with contrasting ink in stock Bootstrap. No !important. These set custom properties that Bootstrap itself consumes, so they win by being more specific than :root without fighting the cascade. -------------------------------------------------------------------------- */ .btn-primary, .btn-secondary, .btn-success, .btn-danger, .btn-warning, .btn-info, .btn-light, .btn-dark { /* Ink stays constant across every interactive state. */ --bs-btn-hover-color: var(--bs-btn-color); --bs-btn-active-color: var(--bs-btn-color); --bs-btn-disabled-color: var(--bs-btn-color); /* Fill darkens instead. 85% / 78% mirrors Bootstrap's own shade steps. */ --bs-btn-hover-bg: color-mix(in srgb, var(--bs-btn-bg) 85%, #000); --bs-btn-hover-border-color: color-mix(in srgb, var(--bs-btn-border-color, var(--bs-btn-bg)) 85%, #000); --bs-btn-active-bg: color-mix(in srgb, var(--bs-btn-bg) 78%, #000); --bs-btn-active-border-color: color-mix(in srgb, var(--bs-btn-border-color, var(--bs-btn-bg)) 78%, #000); } /* .btn-light and .btn-warning carry dark ink on a light fill, so darkening the fill walks them TOWARD their text rather than away from it. Lighten those two instead, preserving the same "ink never moves" guarantee. */ .btn-light, .btn-warning { --bs-btn-hover-bg: color-mix(in srgb, var(--bs-btn-bg) 88%, #fff); --bs-btn-hover-border-color: color-mix(in srgb, var(--bs-btn-border-color, var(--bs-btn-bg)) 88%, #fff); --bs-btn-active-bg: color-mix(in srgb, var(--bs-btn-bg) 80%, #fff); --bs-btn-active-border-color: color-mix(in srgb, var(--bs-btn-border-color, var(--bs-btn-bg)) 80%, #fff); } /* Dropdown items and nav links are the other two stock components where the hover fill is themeable while the ink is not, which is the same trap. */ .dropdown-item:hover, .dropdown-item:focus-visible { background-color: var(--bs-dropdown-link-hover-bg, rgba(10, 16, 31, 0.075)); color: var(--bs-dropdown-link-color, inherit); } .nav-link:hover, .nav-link:focus-visible { color: var(--bs-nav-link-hover-color, var(--bs-nav-link-color, inherit)); } /* ============================================================================ NOT WRITTEN - each of these needs one answer before kimosabi will touch it. The site was not running on localhost:52191 when this file was written, so none of the following could be verified against computed styles. Writing them from assumption would be editing blind. a) HEADER "Start Building" BUTTON - scp3 scp4 bwa-rsp-tap. Measured 2.44:1 white on a gradient, in rest, hover AND focus, on all 23 pages, plus hover-no-change. This is the designer's first header note. The scp3 / scp0 / bwa-rsp-tap classes do not exist anywhere in this repo, so they come from the theme or the database. NEEDED: the gradient's actual stops, or permission to replace the gradient with a solid fill that clears 4.5:1 - which is a visible design change and therefore the designer's call. b) ASK STAN LAUNCHER - stan-cta-button. Measured 3.34:1 white on a gradient, all 23 pages. Same question as (a), and stan-cta-button is likewise absent from this repo. c) PLYR VIDEO CONTROLS - 21 fails, the worst at 1.09:1. White control icons on a near-white bar: rgb(255,255,255) on rgb(239,246,255) page-side and rgb(243,245,251) inside the island. DELIBERATELY OUT OF SCOPE - webcowboy scoped this file to default Bootstrap components on 2026-10-01. Plyr ships its own skin and its own custom properties (--plyr-video-control-color and friends); correcting it means deciding whether the control BAR should be dark (restoring Plyr's default scrim, keeps white icons) or the ICONS should be dark (keeps the light bar). That is a design decision, not a contrast calculation, and getting it wrong inverts the player on every page that uses it. d) HOME "One platform. Every capability." - btn primary / btn ghost. Measured: ghost text 1.58:1 white on rgb(204,204,229), and both buttons with a 1.63:1 focus ring. The ring is fixed by block 1. The ghost text needs either a darker label or a darker fill - again a visible design change, and "btn ghost" is generic enough that kimosabi will not write a sitewide rule for it without confirming which component owns it. d) FAQ NON-ACTIVE PILL HOVER. Block 2 fixes the active pill. The non-active pill's hover also routes through --faq-text / --faq-accent, so on a dark surface it may be low contrast even though the audit did not flag it. NEEDED: one pass with the site up to read what --text and --accent actually resolve to inside the FAQ on a dark banner. The clean fix is token re-scoping, which is the same pattern Footer.ascx already uses and documents. e) PRICING CURRENCY TOGGLE - currency-option. Measured hover-no-change, consistent with the designer's note that it is a link rather than a working control. That is a JS task, not CSS. f) HOME "mod" ELEMENTS. 34 covered findings on a diagram. Almost certainly the audit treating a decorative graphic as interactive. Worth one look before anyone fixes it. PHASE 2 - OUT OF REACH FROM THIS FILE ENTIRELY. 25 of the designer's CTA banner items live inside iframe islands. A stylesheet registered on the parent page cannot cross an iframe boundary, so nothing in THIS file will ever affect them no matter how it is written. 111 of the 639 fails sit behind that boundary, and another 16 sit in shadow DOM. That is a limit of the delivery mechanism, not of the codebase. Confirmed 2026-10-01: App_Code/BWA.Plugins/AISettings/Services/AIBlockIslandLoader.cs assembles every island srcdoc server-side and already injects five things into each one - InjectNoScrollStyle (5124), InjectBrandTokenStyle (5100), InjectInnerCapStyle (4965), InjectBaseTopTarget (5166) and InjectIframeAutoHeightScript (5206). The shadow-DOM islands are built by the same loader. So Phase 2 is a sixth injection following an established pattern. Three constraints the loader documents, which Phase 2 must respect: - Inline