/* =========================================================================
   Homepage accessibility fixes — front page only.
   Companion to src/js/home-a11y.js, enqueued from the same is_front_page()
   block in functions.php.

   Loaded LAST among the homepage's stylesheets on purpose: both rules below
   override something that already won — a Bricks-generated id rule and an
   inline <style> block — so source order and !important are load-bearing
   here, not decoration.

   Audited 2026-07-26 (docs/marketing/homepage-audit-2026-07-26.md).
   ========================================================================= */

/* [A1] Social-proof label failed WCAG AA.
   "Businesses & Agencies Using Social Champ" rendered #7c8697 on #ffffff =
   3.68:1, against the 4.5:1 minimum for 16px text.
   The colour is set by Bricks' generated page stylesheet as
   `#brxe-gghpgr { color: rgb(124,134,151) }` (post-345684.min.css), so this
   needs equal-or-greater specificity plus !important to land.
   #666666 = 5.74:1 and is ALREADY one of the homepage's text colours (54
   elements) — deliberately reusing an existing token rather than minting an
   eleventh grey, since token drift is itself a live finding in that audit.

   UPDATE 2026-07-26: the first version of this rule listed ONLY #brxe-gghpgr,
   because that is the element the audit happened to name. A later full-page
   sweep found the same failing #7c8697 on two MORE labels in the same stats
   band. The lesson, written down because it will recur: fix the failing
   COLOUR everywhere it appears, not the one element a report cites. If a new
   stat is added to this band, re-sweep — a Bricks id list cannot self-extend.
     #brxe-gghpgr  "Businesses & Agencies Using Social Champ"
     #brxe-xnrrzb  "Posts Published in the Last 30 Days"
     #brxe-gdnnfq  "Social platforms supported"                            */
#brxe-gghpgr,
#brxe-xnrrzb,
#brxe-gdnnfq {
  color: #666666 !important;
}

/* [A2] The hero email field had NO visible focus indicator.
   Measured at 1440 with real keyboard Tab: :focus-visible = true,
   outline: none, box-shadow: none. It is the primary conversion element on
   the page and it was invisible to keyboard users — WCAG 2.4.7.
   `outline: none` comes from an inline <style> block, so this must be
   !important to win.
   The ring goes on the WRAPPER: the input is a borderless flex child inside
   .sc-email-box (which also holds the submit button), so a ring on the box
   is what actually reads as "this control is focused". :focus-within also
   covers the button, which is correct — both are in the same control group.
   #464646 is the homepage's ink; on the cream hero it is ~9.4:1, far above
   the 3:1 required for non-text focus indicators (WCAG 1.4.11). */
.sc-email-box:focus-within {
  outline: 3px solid #464646 !important;
  outline-offset: 2px;
}

/* NOTE: there is deliberately NO companion `.sc-email-input:focus-visible`
   rule. :focus-within and :focus-visible match SIMULTANEOUSLY when the input
   is keyboard-focused — they do not resolve in sequence — so adding one draws
   a second ring inside the first rather than acting as a fallback. One ring,
   on the wrapper. */

/* [A3] PAGINATION DOTS WERE BELOW THE MINIMUM TARGET SIZE — fixed by
   SPACING, not by a bigger hit area. Read this before "improving" it.

   Measured: dots 10x10 with `margin: 5px`, so a 20px pitch.

   The first attempt overlaid a 24x24 ::before on each dot. That was WORSE
   than the problem: at a 20px pitch the 24px regions overlap by 4px, later
   siblings win hit-testing in the overlap, and a click aimed at one dot
   activates its neighbour. Measured with elementFromPoint over a 24x24 grid:
   24 of 144 sample points on a dot resolved to a DIFFERENT dot. The original
   10px dots had no such mis-activation — the "fix" introduced one.

   WCAG 2.5.8 offers a Spacing exception: undersized targets pass if a 24px
   diameter circle centred on each does not intersect another target's circle.
   `margin: 0 7px` on a 10px dot gives an outer box of 24px, so the centres
   sit exactly 24px apart and the circles are tangent, not intersecting.
   That satisfies the SC with no overlap and no restyling — the dots simply
   sit 4px further apart.

   Deliberately NOT resizing the buttons: the painted dot IS the button
   (background + border-radius:100%), so width/height changes would resize the
   visible dot, and the same selector also matches a second pagination variant
   on this page whose items are 0x30 bars. Margin is the only lever that is
   safe for both. The arrows measure 60x44 and already pass. */
.splide__pagination__page {
  margin: 0 7px !important;
}

/* [A4] REDUCED MOTION. home-a11y.js already stops video autoplay and pauses
   Splide autoplay for these users, but 577 elements still carry CSS
   transitions/animations against only 2 reduced-motion rules in the
   homepage's stylesheets. This closes the CSS half.
   Scoped to the front page. `animation: none` on a Splide track would break
   its transform-driven positioning, so transitions are neutralised rather
   than transforms, and the carousel keeps working — it simply stops easing. */
@media (prefers-reduced-motion: reduce) {
  body.home *,
  body.home *::before,
  body.home *::after {
    animation-duration: 0.001ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.001ms !important;
    scroll-behavior: auto !important;
  }
}