/* ============================================================
   wcag-s0075-zen-garden.css
   WCAG 2.1 Level AA override for the S0075-Zen-Garden Kentico template
   (TemplateId 1387).

   Selectors verified against the live base CSS pulled from
   https://loneoakapartments.com on 2026-05-07.

   This template does NOT use a template-namespace prefix — base
   selectors are global. Bootstrap is loaded separately and
   suppresses outlines on .navbar-toggle / .dropdown-toggle as
   usual.

   Specificity strategy:
   Every selector is prefixed with `body #form` (ASP.NET WebForms
   page-level form ID) to lift specificity above widget CSS that
   loads after our override.
   ============================================================ */


/* ------------------------------------------------------------
   WCAG 2.4.7 Focus Visible
   The Zen-Garden CSS itself has no outline-suppression rules,
   but Bootstrap removes outlines on .navbar-toggle, .dropdown-
   toggle, .form-control:focus, etc. Restore visible focus rings
   via :focus-visible.
   .footer-widget footer a:focus { outline:none } also lives in
   the shared footer.min.css — covered here too.
   ------------------------------------------------------------ */
body #form .navbar-toggle:focus-visible,
body #form .dropdown-toggle:focus-visible,
body #form .btn:focus-visible,
body #form .form-control:focus-visible,
body #form input.form-control:focus-visible,
body #form select.form-control:focus-visible,
body #form textarea.form-control:focus-visible,
body #form a:focus-visible,
body #form button:focus-visible,
body #form input:focus-visible,
body #form select:focus-visible,
body #form textarea:focus-visible,
body #form [tabindex]:focus-visible,
body #form [role="button"]:focus-visible,
body #form .footer-widget footer a:focus-visible {
  /* Webkit-style two-ring halo: blue inner ring + white outer ring
     gives focus visibility on both light AND dark backgrounds.
     The `outline` declaration is intentionally omitted — outline
     paints on top of box-shadow and would cover the white ring. */
  outline-offset: 2px;
  box-shadow: 0 0 0 2px #005fcc, 0 0 0 3px #fff;
}


/* ------------------------------------------------------------
   WCAG 2.4.11 Focus Not Obscured
   Base: #topHeaderBar { position:fixed; top:0; padding:15px 0;
                         font-size:18px; ... } ≈ 50px tall.
   Reserve scroll space below the sticky bar.
   ------------------------------------------------------------ */
html {
  scroll-padding-top: 80px;
}

body #form :focus-visible {
  scroll-margin-top: 80px;
}


/* ------------------------------------------------------------
   WCAG 1.4.11 Non-text Contrast (form controls)
   Base: input.form-control, select.form-control, textarea.form-control
         { border:none; border-bottom: solid 1px #c1c1c1; ... }
   #c1c1c1 on white ≈ 1.85:1 — fails 3:1.
   ------------------------------------------------------------ */
body #form input.form-control,
body #form select.form-control,
body #form textarea.form-control {
  border-bottom-color: #595959;
}

body #form input::placeholder,
body #form textarea::placeholder {
  color: #595959;
  opacity: 1;
}


/* ------------------------------------------------------------
   WCAG 1.4.1 Use of Color (inline links)
   Base inline content links:
     .mainContent a, .contentPrivacy a, .content404 a,
     .thankyoublurb a, .readmoreWrapper a
       { color:#799c0b; font-size:24px; }
   No underline → fails 1.4.1 (color-only distinction).
   We add underline ONLY (no color change). Reasons:
     1. The 24px font-size qualifies as WCAG large text — only
        3:1 contrast required. #799c0b on white ≈ 3.5:1 PASSES
        large-text contrast, so 1.4.3 is not technically failed.
     2. Brand colors vary per property. A blanket color override
        in this template-level injection would clash with any
        property whose brand replaces the default green.
   If Silktide flags 1.4.3 anyway on a specific property, fix it
   at that property's site-CSS level, not here.
   ------------------------------------------------------------ */
body #form .mainContent a,
body #form .contentPrivacy a,
body #form .content404 a,
body #form .thankyoublurb a,
body #form .readmoreWrapper a {
  text-decoration: underline;
  text-underline-offset: 2px;
}


/* ------------------------------------------------------------
   TFS 2985969 — WCAG 1.4.1, interaction states
   The rest-state underline above is correct and wins (the base
   content-link rule at RPcssMaster_S0075-Zen-Garden.css:1101 sets
   only color + font-size). But the base ALSO carries a global,
   unscoped !important strip:
     RPcssMaster_S0075-Zen-Garden.css:134-136
       a:focus, a:hover, a:active { text-decoration: none!important; }
   Specificity (0,1,1) + !important, so it beats our plain
   rest-state rule the instant the link is hovered or keyboard-
   focused, and the link is colour-only again during interaction.
   Confirmed live on cctancenter.com/Neighborhood.aspx: all 10 POI
   prose links compute `underline` at rest and `none` on
   hover/focus/active. Reproduces on every S0075-Zen-Garden site
   by construction, because the base rule is global.

   Nesting note (corrected TFS 2985969): the containment is
   `.page_neighborhood > #neighborhoodTopContent.mainContent`, i.e.
   `.mainContent` is INSIDE `.page_neighborhood` — not the reverse,
   as an earlier draft of the plan stated. Measured live: 10 anchors
   under `.mainContent`, 12 under `.page_neighborhood`. Scoping to
   `.mainContent` is still correct and is what is used below; the
   two extra `.page_neighborhood` anchors are `a#getDirections` and
   `a#scroll-down`, which sit OUTSIDE `.mainContent` and are
   therefore correctly left un-underlined without needing an
   explicit opt-out.

   Counter it with an !important scoped to the SAME five content
   containers as the rest-state rule — no new containers are
   introduced here, this is purely a state fix. Each selector
   (e.g. `body #form .mainContent a:hover` = (1,2,2))
   out-specifies the base `a:hover` (0,1,1), so among competing
   !important declarations ours wins. Deliberately NOT a bare
   `a:hover` counter: the nav/header/footer/button opt-out block
   below is plain `text-decoration:none` with no !important, so a
   global counter would defeat it and underline the whole chrome.
   Those containers are safe by construction anyway —
   S0075-Zen-Garden-Master_1.ascx renders `<header>` and
   `<footer>` as siblings outside `<main id="main-content">`,
   which is where `.mainContent` lives.
   ------------------------------------------------------------ */
body #form .mainContent a:hover, body #form .mainContent a:focus, body #form .mainContent a:active,
body #form .contentPrivacy a:hover, body #form .contentPrivacy a:focus, body #form .contentPrivacy a:active,
body #form .content404 a:hover, body #form .content404 a:focus, body #form .content404 a:active,
body #form .thankyoublurb a:hover, body #form .thankyoublurb a:focus, body #form .thankyoublurb a:active,
body #form .readmoreWrapper a:hover, body #form .readmoreWrapper a:focus, body #form .readmoreWrapper a:active {
  text-decoration: underline !important;
  text-underline-offset: 2px;
}

/* Companion opt-out: keep button/utility-shaped links inside the
   content zones un-underlined on interaction. Needs the same
   !important to compete with the rule directly above, since the
   plain opt-out block further down cannot. Mirrors that block's
   shape list, re-scoped per content container. */
body #form .mainContent a.btn:hover, body #form .mainContent a.btn:focus, body #form .mainContent a.btn:active,
body #form .mainContent a.button:hover, body #form .mainContent a.button:focus, body #form .mainContent a.button:active,
body #form .mainContent a.more-link:hover, body #form .mainContent a.more-link:focus, body #form .mainContent a.more-link:active,
body #form .mainContent a.less-link:hover, body #form .mainContent a.less-link:focus, body #form .mainContent a.less-link:active,
body #form .mainContent a.cta-header-btn:hover, body #form .mainContent a.cta-header-btn:focus, body #form .mainContent a.cta-header-btn:active,
body #form .mainContent a.header-CTA-button:hover, body #form .mainContent a.header-CTA-button:focus, body #form .mainContent a.header-CTA-button:active,
body #form .mainContent a.footer-CTA-Button:hover, body #form .mainContent a.footer-CTA-Button:focus, body #form .mainContent a.footer-CTA-Button:active,
body #form .readmoreWrapper a.more-link:hover, body #form .readmoreWrapper a.more-link:focus, body #form .readmoreWrapper a.more-link:active,
body #form .readmoreWrapper a.less-link:hover, body #form .readmoreWrapper a.less-link:focus, body #form .readmoreWrapper a.less-link:active,
body #form .thankyoublurb a.btn:hover, body #form .thankyoublurb a.btn:focus, body #form .thankyoublurb a.btn:active,
body #form .thankyoublurb a.button:hover, body #form .thankyoublurb a.button:focus, body #form .thankyoublurb a.button:active,
body #form .content404 a.btn:hover, body #form .content404 a.btn:focus, body #form .content404 a.btn:active,
body #form .content404 a.button:hover, body #form .content404 a.button:focus, body #form .content404 a.button:active {
  text-decoration: none !important;
}


/* ------------------------------------------------------------
   WCAG 1.4.3 (footer disclosure opacity)
   Shared footer.min.css: .footer-widget footer .footer-disclosure
     { opacity:.6 }  — bump so 4.5:1 passes comfortably.
   ------------------------------------------------------------ */
body #form .footer-widget footer .footer-disclosure {
  opacity: 0.85;
}


/* ------------------------------------------------------------
   Footer link / nav / button opt-outs
   These are distinguishable by container or shape, so they do
   NOT need underline.
   ------------------------------------------------------------ */
body #form .btn,
body #form .button,
body #form header a,
body #form nav a,
body #form .navbar a,
body #form .cta-header-btn,
body #form .header-CTA-button,
body #form .footer-CTA-Button,
body #form .footer-widget footer a,
body #form a.more-link,
body #form a.less-link {
  text-decoration: none;
}

/* ------------------------------------------------------------
   TFS 2985969 — Google Maps bleed opt-out (measured live on sibling templates)
   The Maps JS API injects its own colour-only anchors ("Terms",
   "Report a map error", "Open this area in Google Maps") into
   `.gm-style` INSIDE our content containers, so a container-scoped
   underline rule reaches them. Confirmed live on Elan /About.aspx,
   themckenzieapts.com home, and both Balcony homepages (see
   sibling override files). Not independently re-verified on this
   Zen-Garden template — added defensively, since the existing
   `.mainContent` underline rule would otherwise reach these
   third-party map anchors too. These are third-party map chrome,
   not site prose — never underline them.

   `!important` and the `body #form` prefix are both required so
   this beats the content-container counters in this file family,
   including the `underline !important` interaction-state counters
   on Jackson-Square and Zen-Garden. States are listed explicitly
   because those counters are state-scoped.
   ------------------------------------------------------------ */
body #form .gm-style a,
body #form .gm-style a:hover,
body #form .gm-style a:focus,
body #form .gm-style a:active,
body #form .google-map-container a,
body #form .google-map-container a:hover,
body #form .google-map-container a:focus,
body #form .google-map-container a:active,
body #form .gm-style-cc a,
body #form a[href*="maps.google.com/maps?ll="],
body #form a[href^="https://www.google.com/maps/@"] {
  text-decoration: none !important;
}

/* ------------------------------------------------------------
   TFS 2905632 - WCAG 1.4.1 Use of Color (selected state)
   The Floor Plans bed/bath filter and view-switch tabs mark the
   selected item with a brand-color background + #fff text only
   (base rule sets border-color:transparent, no weight/underline).
   Add an underline so the selection is perceivable in greyscale
   and for color-blind users. `body #form` prefix keeps specificity
   above the rpWebpartCss_Floorplan* base bundles. No color changed.
   ------------------------------------------------------------ */
body #form .fp2-bed-bath ul li.active > a,
body #form .FloorPlansV2 .fp-switch-tabs .btn-default.active,
body #form .FloorPlansV3 .fp-switch-tabs .btn-default.active {
  text-decoration: underline;
  text-underline-offset: 3px;
}

/* ------------------------------------------------------------
   TFS 2905631 - WCAG 1.4.11 Non-text Contrast (form controls)
   The full-width Neighborhood search input has no perceivable
   resting border: base CSS (rpWebpartCss_NeighborhoodFullWidth.css)
   sets `border:none; background:none; color:#fff` on a dark
   rgba(0,0,0,.83) search overlay. Add a light 1px boundary at
   #cfcfcf (~9.6:1 on that dark surface; matches the widget's
   existing placeholder color). All 21 priority templates use this
   dark default - none override it to a light surface.
   ------------------------------------------------------------ */
body #form .neighborhood-widget .neighborhood-widget__search .form-group .form-control {
  border: 1px solid #cfcfcf;
}

/* WCAG 2.2 AA 2.5.8 Target Size (Pointer) — real fix (native checkbox can't be padded;
   appearance:none + explicit 24px sizing; :checked::after re-draws the check so consent UX is preserved) */
body .contact-mobile-form input[type="checkbox"],
#contactusPrivacy input[type="checkbox"],
#privacyDiv input[type="checkbox"],
#contactUsV1Privacy input[type="checkbox"] {
    -webkit-appearance: none;
    appearance: none;
    width: 24px; height: 24px;
    min-width: 24px; min-height: 24px;
    margin: 4px; padding: 0;
    border: 2px solid currentColor; border-radius: 3px;
    background: #fff; cursor: pointer; position: relative;
    vertical-align: middle; flex: 0 0 auto;
}
body .contact-mobile-form input[type="checkbox"]:checked::after,
#contactusPrivacy input[type="checkbox"]:checked::after,
#privacyDiv input[type="checkbox"]:checked::after,
#contactUsV1Privacy input[type="checkbox"]:checked::after {
    content: ""; position: absolute; left: 7px; top: 3px;
    width: 6px; height: 11px;
    border: solid #1a1a1a; border-width: 0 2px 2px 0;
    transform: rotate(45deg);
}
body .contact-mobile-form input[type="checkbox"]:focus-visible,
#contactusPrivacy input[type="checkbox"]:focus-visible,
#privacyDiv input[type="checkbox"]:focus-visible,
#contactUsV1Privacy input[type="checkbox"]:focus-visible {
    outline: 2px solid; outline-offset: 2px;
}

/* TFS 2987209 — WCAG 2.2 AAA 2.5.5 Target Size (Enhanced): expand the consent
   checkbox's pointer hit-area to 44×44 without changing anything visually
   (Option B, plan §4.4/§0.5 J — live-prototyped pixel-identical to today).
   The painted box stays 24×24 (position:relative already set above); this
   adds a transparent ::before centred over the box that only widens the
   clickable/tappable region. Do not touch :checked::after or :focus-visible
   above, and do not remove min-width/min-height:24px on the box rule above —
   on ContactUsFloating templates that min-width is the only reason the box
   is 24px wide at all (rpWebpartCss_ContactUsFloating.css sets width:auto
   !important, §0.4 D). Uses symmetric inset offsets, not
   left/top:50%+transform: live click-testing found percentage-based
   centering lands ~1-2px off-centre (asymmetric vs. the border-box),
   which stole clicks from an adjacent control (Submit button /
   privacy-policy link) on 3 of 16 templates — insets centre reliably
   regardless of border width. */
body .contact-mobile-form input[type="checkbox"]::before,
#contactusPrivacy input[type="checkbox"]::before,
#privacyDiv input[type="checkbox"]::before,
#contactUsV1Privacy input[type="checkbox"]::before {
    content: "";
    position: absolute;
    top: -12px; left: -12px; right: -12px; bottom: -12px;
}

/* TFS 2987209 — WCAG 2.2 AAA 2.5.5 Target Size (Enhanced): mobile-nav
   hamburger. Live-measured: `button#hamburgerMenuButton` is 40.2×41 at
   ≤767px (fails) but already 67.2×62 at ≥768px (passes) — the box is
   driven entirely by the glyph's own font-size (40px→60px), not by any
   width/height/padding, so this fix is gated to Bootstrap's own mobile
   breakpoint (confirmed live at the exact 767/768 boundary) to avoid
   touching the passing desktop state. A first candidate grew the box
   directly via min-width/min-height:44px — live-tested clean, but shifted
   the glyph ~2px down-left (button is right-anchored `position:absolute`,
   so growth is asymmetric). Switched to the same transparent ::before
   hit-area overlay already used for the consent checkbox above (button
   already `position:absolute`, so it anchors correctly): confirmed live
   0-pixel diff — glyph does not move at all — while the enlarged
   ~46.2×47 hit area clears 44×44 and the ≥768px state is confirmed
   unaffected (media-gated). `body #form` prefix per this file's
   specificity strategy (see header comment). */
@media (max-width: 767px) {
  body #form button#hamburgerMenuButton::before {
    content: "";
    position: absolute;
    top: -3px; left: -3px; right: -3px; bottom: -3px;
  }
}

/* ------------------------------------------------------------
   TFS 2982346 - WCAG 2.2 AA 2.5.8 Target Size (Pointer): footer links

   Live-measured on zengarden011226.sat-ws.realpage.com/Contact.aspx at 1280x900 (headless Chrome,
   border-box heights): 11 of 13 footer targets render under 24px tall.

     footer ul#CMSListMenu2 li a     12px tall, display:block, line-height 12px,
                                     9 links stacked at a 33.7px pitch
     footer ul#mobileMenuElem
       li.footerLink a               20px tall, display:block, ~60px pitch
     footer a#link-rp                16px tall, display:INLINE (RealPage mark)

   `line-height` alone does not fix any of these. On an inline element it does
   not change the border-box height at all; on the block ones the base already
   sets line-height equal to the text height. Only min-height plus real padding
   grows the hit area.

   No negative-margin cancel is used on CMSListMenu2, unlike Tableau. Measured
   both ways on the live page: padding-only and padding+cancel produce the
   IDENTICAL result here (11 -> 3 remaining, footer height +0.0px, document
   height +0px). The links sit in a floated `.menu.clearfix` container whose
   height is driven by its float context, not by the anchors' own boxes, so the
   padding does not push the footer taller and there is nothing to cancel.
   Padding-only is kept because a negative margin that buys nothing is pure
   overlap risk if this list ever wraps.


   SCOPE PREFIX: scoped on the `footer` element, NOT `.footer-widget footer`.
   This is one of the three templates in this ticket where that matters -
   this template nests `footer > .footer-widget` (reversed), so the Tableau/Ascension
   prefix selects NOTHING here. Verified against the live SAT DOM.
   ------------------------------------------------------------ */
footer ul#CMSListMenu2 li a.CMSListMenuLink,
footer ul#CMSListMenu2 li a.CMSListMenuLinkHighlighted {
    min-height: 24px;
    padding: 6px 0;
}

footer ul#mobileMenuElem li.footerLink a {
    min-height: 24px;
    padding: 2px 0;
}

/* Inline element - inline-block is what makes min-height apply at all.
   Deliberately NO `svg { height: 20px }` guard here, unlike Tableau and the
   other templates in this ticket. Zen-Garden's RealPage mark is a 76px-tall
   SVG overflowing a 16px inline anchor; pinning it to 20px shrank the visible
   logo and took 57px off the document height (measured live). inline-block
   plus min-height does NOT stretch it - the SVG stays 76px and the document
   height is unchanged at +0px. Do not add the guard back without re-measuring.
   ------------------------------------------------------------ */
footer a#link-rp {
    display: inline-block;
    min-height: 24px;
}
