/* =====================================================================
 * Premier Restoration Hawaii (premhi.com) — accessibility remediation
 * Enqueued by src/accessibility.php as the 'superpath-a11y' handle.
 * The child theme's own style.css is header-only and is not enqueued, so the
 * fixes live here rather than being appended to it.
 *
 * Theme: Total + child "superpath-total", WPBakery + Total's vcex modules.
 *
 * Brand palette as found on the site:
 *   --wpex-accent       #3c98cd   brand blue
 *   --wpex-accent-alt   #f9981e   brand orange
 *   --wpex-bg-color     #022253   navy page background, AND the body text
 *                                 colour is #fefefe to suit it
 *   palette-1437        #f04324   brand red
 *   palette-1439        #2bb34a   brand green
 *
 * Two new values, both derived from existing brand colours:
 *   #2f7aa4   brand blue one step darker — 4.73:1 under white text
 *   #d63c20   brand red one step darker  — 4.64:1 under white text
 *
 * The brand blue #3c98cd is KEPT as-is: it is 4.84:1 against the navy page
 * background and darkening it globally breaks accent text there. See the
 * tally for the measurements.
 *
 * TICKET LOG
 *   T1  Insufficient color contrast of content in main
 * ===================================================================== */


/* ---------------------------------------------------------------------
 * T1 — Insufficient color contrast (WCAG 1.4.3)
 *
 * Cited element: <span class="vcex-icon-box-button theme-button">Learn More</span>
 * on /fire/ — white on #3c98cd = 3.20:1 against a 4.5:1 requirement.
 *
 * Site sweep (98 URLs) found 22 confirmed failing combinations from the same
 * handful of root causes. This file covers the ones that are theme-level;
 * the rest are content-level and are listed in the tally.
 * ------------------------------------------------------------------- */

/* --- Buttons -------------------------------------------------------- */
/* Buttons take their fill from --wpex-btn-bg, falling back to --wpex-accent.
   Setting the button token alone fixes every .theme-button, .button,
   .color-button and submit input site-wide, without touching the accent
   colour where it is still passing.

   The hover state was a worse failure than the one the auditor cited:
   white on the orange #f9981e is 2.20:1. The site had overridden
   --wpex-hover-btn-color to white; Total's own default for that slot is
   --wpex-on-accent-alt (#022253), which gives 7.03:1. This puts it back. */

:root{
  --wpex-btn-bg:#2f7aa4;             /* white on this = 4.73:1 (was 3.20:1) */
  --wpex-hover-btn-color:#022253;    /* navy on orange hover = 7.03:1 (was 2.20:1) */
  --wpex-active-btn-color:#022253;
}

/* --- Accordions ----------------------------------------------------- */
/* Blue fill under white text, 3.17:1, on 25 pages. The fill comes from
   var(--wpex-accent) through a per-group generated rule, so it needs an
   explicit override rather than a token change. */

.vcex-toggle--boxed,
.vcex-toggle-group .vcex-toggle{
  background-color:#2f7aa4 !important;
}

/* --- Blog / archive cards ------------------------------------------- */
/* The worst failures on the site, and not ones the auditor's example hints
   at: the body text colour is #fefefe (chosen for the navy page), and the
   white cards on the 24 category archives never reset it. Excerpt text and
   the category list render near-white on white at 1.01:1 — effectively
   invisible, not merely low contrast.

   Verified: these two rules take a category page from 3 failures to 0. */

.wpex-card-inner{ color:#022253; }
.wpex-card-inner a{ color:#2f7aa4; }

/* Hover state on those card links (T3). Two reasons this rule is here rather
   than left to the theme:
   1. The theme's a:hover uses --wpex-hover-link-color (#f04324), which is
      3.80:1 on a white card — it would fail on hover even after the resting
      state is fixed, and the auditor's note counts state changes.
   2. The rule above and the theme's `a:hover` have identical specificity, so
      the child theme's wins and hover would otherwise stop changing colour at
      all. Setting it explicitly keeps the red-on-hover the design intends,
      one shade deeper: 4.64:1. */

.wpex-card-inner a:hover,
.wpex-card-inner a:focus-visible{ color:#d63c20; }

/* "Read More" appears on white cards (blue link, 3.20:1, 21 pages) AND on
   blue cards (white link, 3.20:1, 19 pages) — the same component failing
   from opposite directions. Navy is the one colour that clears both:
   15.8:1 on white, 4.84:1 on the blue card. */

.entry-details a.entry-readmore,
.entry-details a.entry-readmore .vcex-readmore-rarr{
  color:#022253 !important;
}

/* Hover for those links (T10). The colour rule above is !important, so it also
   beats the theme's a:hover — which means hover would otherwise stop responding
   at all. A colour change can't be used here: the same link sits on a white
   card and on a blue one, and nothing reads well on both. An underline does,
   and it needs !important because the site sets a{text-decoration:none
   !important} globally. Navy stays put: 15.5:1 on white, 4.84:1 on the blue
   card. */

.entry-details a.entry-readmore:hover,
.entry-details a.entry-readmore:focus-visible{
  text-decoration:underline !important;
}

/* --- Social share buttons (T5) --------------------------------------- */
/* Deliberately NOT fixed here. Total has first-class Customizer fields for
   these (General > Social Share > Background / Background: Hover) and the
   site's share style is already "custom", so those fields are live. Forcing
   the colour from CSS would need !important to beat the generated rule, and
   because the theme's :hover rule is not !important, that would also suppress
   the hover colour change entirely — the same silent side effect that turned
   up on the card links in T3. The values to set are in the tally. */

/* ---------------------------------------------------------------------
 * T12 — Links in body copy distinguished by colour alone (WCAG 1.4.1)
 *
 * Visible change — client (Premier Restoration Hawaii) approved 5 Oct 2026.
 *
 * The site carries `/*Remove Link Underline*​/ a{text-decoration:none
 * !important;}` in Customizer > Additional CSS, on top of the theme's link
 * decoration setting already being "none". So no link anywhere is underlined,
 * and an inline link in a paragraph is told apart from the text around it by
 * colour only.
 *
 * Scoped to .wpb_text_column — the WPBakery text block, which is where both
 * page body copy and blog article copy live — and to links with no class of
 * their own, which excludes buttons and module links. Measured across five
 * pages: 4, 9, 5, 0 and 0 links change. Nothing in the nav, the footer, the
 * icon boxes or the cards is touched.
 *
 * Needs !important only to beat the Additional CSS rule above. If that rule is
 * ever removed, this can drop to a plain declaration.
 *
 * The tidier-looking alternative — deleting that Additional CSS rule and
 * flipping the theme's link decoration to "underline" — was measured and
 * rejected: it underlines 66 of 121 links on a page, including the logo and
 * the skip link. The tally has the numbers.
 * ------------------------------------------------------------------- */

/* Widened 27 Oct (RAMP retest, /about/): a pasted link carrying inert
 * Tailwind classes ("underline underline-offset-2 ...") slipped past the
 * original :not([class]). Now excludes only links styled by the theme or
 * the builder (wpex/vcex/theme-/vc_ classes, buttons) - any other class is
 * treated as plain body copy, so pasted markup is covered. */
.wpb_text_column a:not([class*="wpex"]):not([class*="vcex"]):not([class*="theme-"]):not([class*="vc_"]):not([class*="button"]):not([class*="btn"]){
  text-decoration:underline !important;
}

/* ---------------------------------------------------------------------
 * T1 open item — links inside a filled icon box
 *
 * On /fire/ two links sit inside red-filled icon boxes, orange on red:
 * 1.72:1, and still 2.11:1 after the red is darkened. Neither brand colour
 * survives the other.
 *
 * `color: inherit` makes the link take the box's own text colour, so it is
 * correct by construction whatever the box is filled with — white in the red
 * boxes (4.64:1 once the red is darkened), navy in the orange and green boxes
 * once their text is switched. It also self-corrects if a box's fill changes
 * later.
 *
 * That leaves the link the same colour as the text around it, which is why the
 * underline is not optional here — without it the link would be WCAG 1.4.1
 * failing instead. !important because of the site's global
 * a{text-decoration:none !important}.
 *
 * Scoped to #main so the footer's address and phone links — 240 of them across
 * the site, in unfilled boxes on a dark background, currently fine — are not
 * touched. Verified: exactly 2 links change.
 * ------------------------------------------------------------------- */

#main .vcex-icon-box-content a:not([class]){
  color:inherit;
  text-decoration:underline !important;
}

/* ---------------------------------------------------------------------
 * H5 / H6 in post content (found 6 Oct, open decision 4).
 *
 * Total's Customizer only sets colours for H1-H4, so H5 and H6 fall back
 * to the theme default --wpex-heading-color (#222222). On this site's navy
 * page that is 1.03:1 - invisible. Inherit the post text colour instead,
 * as H1-H4 effectively do. Scoped to the post body so headings inside
 * cards and modules keep their own colours.
 * ------------------------------------------------------------------- */

.single-blog-content :is(h5, h6){
  color:inherit;
}