/* ============================================================
   wcag-c0050-gs-vintage.css
   WCAG 2.1 Level AA override for the C0050-GS-Vintage Kentico template
   (TemplateId 1365, DefaultCssFileName: RPcssMaster_C0050-GS-Vintage).

   Selectors verified against the live base CSS pulled from
   livesommery.com (cross-fetched) on 2026-05-12.

   This template does NOT use a .template-* wrapper.
   Header is confirmed sticky:
     #masterHeader { position:fixed; top:0; min-height:70px }
   ============================================================ */


/* ------------------------------------------------------------
   WCAG 2.4.7 Focus Visible
   Base: #contactUsEnhancedContainer .form-control:focus
     { outline:none; box-shadow:none; -webkit-box-shadow:none }
   Plus Bootstrap's standard suppressions.
   ------------------------------------------------------------ */
.navbar-toggle:focus-visible,
.dropdown-toggle:focus-visible,
.btn:focus-visible,
.form-control:focus-visible,
#masterHeader a:focus-visible,
#menuDesktop a:focus-visible,
#menuMobile a:focus-visible,
#menuDesktop #menuElem li a:focus-visible,
#contactUsEnhancedContainer .form-control:focus-visible,
a:focus-visible,
button:focus-visible,
input:focus-visible,
select:focus-visible,
textarea:focus-visible,
[tabindex]:focus-visible,
[role="button"]:focus-visible,
.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: #masterHeader { position:fixed; top:0; min-height:70px }
   ------------------------------------------------------------ */
html {
  scroll-padding-top: 100px;
}

:focus-visible {
  scroll-margin-top: 100px;
}


/* ------------------------------------------------------------
   WCAG 1.4.11 Non-text Contrast (UI components)
   Base failure:
     #menuDesktop #menuElem li a:hover
       { border-bottom:2px solid #efefef }
   #efefef on white ≈ 1.18:1 — the hover-state underline is
   barely visible. Bump to #595959 so the hover indicator is
   a proper UI cue.
   ------------------------------------------------------------ */
#menuDesktop #menuElem li a:hover {
  border-bottom-color: #595959;
}

body #contactUsEnhancedContainer .form-control {
  border-bottom: 1px solid #595959 !important;
}


/* ------------------------------------------------------------
   WCAG 1.4.3 Contrast Minimum (text)
   Base failures:
     #7e7e7e in 10+ rules across menu, floorplan specs, content
     blocks ≈ 4.4:1 — fails 4.5:1 by a hair.
     Shared footer-disclosure opacity 0.6 → 0.85.
   ------------------------------------------------------------ */
#menuDesktop #menuElem li a,
#menuMobile a,
.mmContain a,
.FloorPlansV3 .specification,
.FloorPlansV2 .specification {
  color: #595959;
}

.footer-widget footer .footer-disclosure {
  opacity: 0.85;
}


/* ------------------------------------------------------------
   WCAG 1.4.1 Use of Color (inline links)
   ------------------------------------------------------------ */
/* Scope: content containers only. Bare `p a` / `li a` / `dd a` selectors were dropped (same Balcony/Aurora/Bliss/Jackson-Square bleed bug — they would underline footer nav, header items, sidebar lists). */
.main-content-text a,
.inner-page-main a,
.main-content-wrapper a,
.container-fluid.main a {
  text-decoration: underline;
  text-underline-offset: 2px;
}

a.btn,
a.button,
.btn,
.btn-primary,
#masterHeader a,
#menuDesktop a,
#menuMobile a,
.cta-header-btn,
.header-CTA-button,
.footer-CTA-Button,
a.more-link,
a.less-link,
.footer-widget footer a {
  text-decoration: none;
}

/* ------------------------------------------------------------
   TFS 2870264 — WCAG 1.4.1 (homepage inline links)
   Vintage's homepage uses `.contentSection` (the welcome /
   floor-plan-search blurb) and a `.container.animateMe` row
   with `.col-xs-12` text columns for the features/about
   prose. A `.homeBottomImage` block holds a bottom-section
   blurb on some properties. Verified against
   livemonterraapts.com + windermerecay.com (multiple inline
   links to /Neighborhood.aspx, /Floor-plans.aspx, etc. in
   rich-text paragraphs).
   The "Get Directions" link (`a.bold[href*="maps.google.com"]`)
   sits inside `.contentSection .animateMe` too — opted out
   because it's a CTA, not prose.
   ------------------------------------------------------------ */
.contentSection .animateMe a,
.container.animateMe .col-xs-12 a,
.homeBottomImage a {
  text-decoration: underline;
  text-underline-offset: 2px;
}

.contentSection .animateMe a.bold,
.contentSection .animateMe a[href*="maps.google.com"],
.container.animateMe .col-xs-12 a.btn,
.container.animateMe .col-xs-12 a.button,
.homeBottomImage a.btn,
.homeBottomImage a.button {
  text-decoration: none;
}


/** ------------------------------------------------------------
   WCAG 2.2 AA 2.5.8 Target Size (Pointer)
   ------------------------------------------------------------ */
#homeContactContainer #btnSubmit {
    margin-top: 30px;
}
/* ------------------------------------------------------------
   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: `.mmButton a[data-toggle="collapse"]` is
   30×44 (width-only failure) at every viewport — height already clears
   44 because the anchor's `line-height` (55px ≤768 / 70px ≥769) happens
   to exceed it. The anchor is `display:inline`, so `width`/`min-width`
   are no-ops on it per spec — `display:inline-block` is required before
   `min-width` can apply. `min-height:44px` is added as pure hardening
   (a no-op today, confirmed live) so the height pass isn't silently
   dependent on an un-asserted line-height. Live-verified: icon
   (`i.fa.fa-bars`) does not move at all (0-pixel diff), and the grown
   44px-wide anchor still centers inside the 70×55 `.mmButton` parent
   (`hidden-lg` at desktop) with 13px clearance on each side — no
   overflow, no distortion at ≥769px either (parent grows to 70×70). */
.mmButton a[data-toggle="collapse"] {
    display: inline-block;
    min-width: 44px;
    min-height: 44px;
}

/* ------------------------------------------------------------
   TFS 2982346 - WCAG 2.2 AA 2.5.8 Target Size (Pointer): footer links

   Live-measured on test-vintage.sat-ws.realpage.com/Contact.aspx at 1280x900
   (headless Chrome, border-box heights): 2 footer target(s) under 24x24.

     footer .footer-property-logo a                 226.7 x 17, display:inline, wraps an <img>
     footer .footer-phone-content a.footer-phone    133 x 20, display:inline

   These are display:inline, where `line-height` cannot help - it does not
   change an inline element's border-box height. inline-block is what makes
   min-height apply. No padding and no negative-margin cancel is used: each
   target sits in a line box already at or above 24px, so the box grows into
   existing leading. Verified by injecting these rules into the live SAT page:
   0 targets remaining, document height +0px, no horizontal overflow.

   SCOPE PREFIX: scoped on the `footer` element. On THIS template
   `.footer-widget footer` also matches, so either prefix would work - the bare
   `footer` is used for consistency across the 18 template files in this ticket,
   three of which genuinely need it (Zen-Garden and Au-Courant nest
   `footer > .footer-widget`, reversed; Jackson-Square has no `.footer-widget`
   element at all). `footer` is a superset of both nestings. Verified against
   the live SAT DOM per template - not assumed.
   ------------------------------------------------------------ */

footer .footer-property-logo a {
    display: inline-block;
    min-height: 24px;
}

footer .footer-phone-content a.footer-phone {
    display: inline-block;
    min-height: 24px;
}

/* ------------------------------------------------------------
   TFS 2987209 — WCAG 2.2 AAA 2.5.5 Target Size (Enhanced), 44x44
   C0050-GS-Vintage header nav + phone. Measured live at
   375/768/1440 via CDP CSS.getMatchedStylesForNode. This template
   does not load assets/common/header/css/header.css; the header is
   template-native. Override loads at styleSheets[10], master at [0],
   so plain rules win — no !important is used.

   SPECIFICITY NOTE: the base rule is `#masterHeader #menuElem li a`
   — TWO IDs. A rule written as `#menuElem li a` would LOSE despite
   loading later. The selectors below carry #form + #menuDesktop /
   #menuMobile and beat it.
   ------------------------------------------------------------ */

/* Desktop nav (>=1200 only; #menuDesktop is display:none below the
   1199/1200 breakpoint). Links measure 20px tall — the active one
   adds a 2px border-bottom indicator. Widths already pass, narrowest
   "Home" at 46.58px, but that is only 2.58px of headroom so
   min-width is included as a guard.
   Clearance is the constraint: the nav row WRAPS to two lines at
   1440 with only 5.19px between rows. Growing 20 -> 44 is a direct
   box grow, so the rows reflow apart rather than overlapping — this
   is exactly why an overlay is not used here (an overlay would need
   ~12px per side and would sit on top of the adjacent row). */
body #form #menuDesktop #menuElem li a {
    box-sizing: border-box;
    display: inline-flex;
    align-items: center;
    justify-content: center;
    min-width: 44px;
    min-height: 44px;
}

/* Mobile drawer (<=1199, drawer open). 28px tall. min-width IS
   required here too: "FAQ" measures 42.34px wide in the drawer
   (and 30.95px on desktop) — the only label under 44px on this
   template. Every other drawer label is 94-289px, where min-width
   is a no-op. The anchor has NO author rules at all beyond
   Bootstrap's box-sizing, so this adds sizing rather than
   overriding anything. The li already carries a chevron via
   li::after and is position:relative — neither is touched. */
body #form #menuMobile #menuElem li a {
    box-sizing: border-box;
    display: inline-flex;
    align-items: center;
    justify-content: center;
    min-width: 44px;
    min-height: 44px;
}

/* Phone links. The header instance (#headerRight > a.seo-number)
   already passes at every viewport (60x55 / 192.67x55 / 186.67x70)
   and is deliberately EXCLUDED — its ::before carries the
   FontAwesome glyph and it needs no change. The two that fail are
   the body-contact and footer-widget instances (141.3x22 and
   132.98x20), both bare anchors with no author rules, so
   display:inline-block is required before min-height can apply. */
body #form #homeContactAddBottom > a.seo-number,
body #form a.footer-phone.seo-number {
    box-sizing: border-box;
    display: inline-block;
    min-height: 44px;
}
/* No header CTA buttons exist on this template (.header-ctas,
   a.button.cta1/.cta2 all match zero elements). The a.ctaButton
   elements are page-body content and already pass 44x44. */

/* ------------------------------------------------------------
   TFS 2979417 — WCAG 1.4.3 Contrast (Minimum): home-page
   text-over-image/gradient failures.

   Confirmed via live Silktide scan (2026-08-21) against
   https://test-vintage.sat-ws.realpage.com/ — the only one of
   three SAT hostnames on record for this template that actually
   resolves (the other two 302 to a dead call-support page and a
   CMS error page respectively). Root cause confirmed against the
   scanned page's own saved HTML for each selector below, not
   guessed:

   - #bannerCopy (home hero: "Welcome" h1, .special-home-message,
     body-copy link) sits inside #homeBannerRight, which carries
     class="backgroundTexture" — its background is a per-site
     brand color (RPcolor3) plus a texture image. The hero copy's
     hardcoded `color:#fff` (#homeBannerRightContent) doesn't
     reliably clear 4.5:1 against every site's configured
     RPcolor3.
   - #homeBottomHeader ("Your Private Retreat" h2 + link) sits
     inside #homeBottomBackground.fadedBackground > .fader — a
     faded/gradient-over-photo section.
   - #homeBottomMain #homeBottomContent (a body-copy link) — a
     second .backgroundTexture section further down the page,
     same mechanism as #bannerCopy.
   - #contactusBedBath select ("Select Bedrooms" default option)
     belongs to the ContactUsFloating webpart, which renders as a
     panel floating over the hero photo; its browser-default
     option text doesn't carry an explicit contrast-safe color.

   None of these four use the .innerBannerOverlay /
   rpSite.General.OverlayOpacity mechanism that fixed Aurora (TFS
   2979418) — that mechanism exists only on this template's
   INTERIOR page banners (confirmed structurally: the interior
   banner is a sibling-pane split layout, banner text sits in the
   solid brand-color panel, not over the photo), and the home page
   has no overlay/scrim class at all. Aurora's "floor the opacity"
   technique does not transfer here.

   Fix: a real `background-color` behind each element (not a
   `::before` pseudo-element or a `background` gradient) — Silktide
   measures ancestor `background-color` directly and does not
   credit either of those, a lesson already learned and documented
   on this ticket family's auto-contrast JS engine.

   POLARITY CORRECTION (caught via before/after screenshot review,
   not assumed): #bannerCopy's text is hardcoded white
   (#homeBannerRightContent{color:#fff}) — a dark `rgba(0,0,0,.55)`
   backing is correct there (~15:1 against worst-case white text).
   But #homeBottomHeader and #homeBottomMain #homeBottomContent's
   text computes to `rgb(105,105,105)` (#696969) — DARK gray, not
   white. The first version of this fix applied the same dark
   backing to all three, which made these two WORSE (dark-gray text
   on a new dark-gray panel) — confirmed visually by rendering both
   before/after states, not just measuring computed styles. Fixed by
   splitting into two rules: dark backing only where text is white,
   solid opaque white backing where text is dark (#696969 on #fff is
   ~5.5:1, clears 4.5:1 with margin; solid, not translucent, so the
   result doesn't depend on how dark the underlying photo is).

   NOT YET FIXED: Amenities.aspx and Contact.aspx also came back
   "found" on the same Silktide check in the same scan; at the time
   this comment was first written their exact flagged elements
   hadn't been isolated from the saved HTML alone. RESOLVED below
   by querying Silktide's own /inspector/checks API directly (the
   same one its UI calls when you click into a check), which
   returns a `points[].selectors[].match` CSS selector per flagged
   instance — real data, not a guess. See
   docs/silktide-validation/2979417/report.md for the scan writeup;
   the per-instance selector dump lives alongside it. */
#bannerCopy {
    background-color: rgba(0, 0, 0, .55);
}

#homeBottomHeader,
#homeBottomMain #homeBottomContent {
    background-color: #ffffff;
}

#contactusBedBath select {
    background-color: #ffffff;
    color: #1a1a1a;
}

/* ------------------------------------------------------------
   TFS 2979417 — WCAG 1.4.3 Contrast (Minimum): Amenities.aspx and
   Contact.aspx text-over-image/gradient failures.

   Confirmed via Silktide's /inspector/checks?checkId=aa-text-on-image-
   contrast API (2026-08-24), which returns every flagged instance's
   real CSS selector — not the generic panel-text labels used
   earlier. Amenities.aspx: 34 open instances, all descendants of
   just 3 containers. Contact.aspx: 100 open instances — every
   <label> and <option> in the form, all descendants of one
   container. Root cause confirmed against RPcssMaster_C0050-GS-
   Vintage.css and live computed styles for both pages:

   - #amenityTopPanel #communityAmenties (wraps #divAmenityContainerTitle
     and both amenity-list columns) carries BOTH
     `background-color:#fff` AND a `background-image` texture PNG
     (RPcssMaster line ~1837-1847).
   - #contactUsEnhancedContainer (wraps every form label/select on
     Contact.aspx) carries the identical pattern — `background-
     color:#fff` PLUS the same texture-PNG `background-image`
     (RPcssMaster line ~2530-2534).
   - #divPetPolicyDetails / #divParkingDetails each carry their OWN
     small no-repeat decorative icon (pet_policy_icon.png /
     parking_icon.png) as `background-image`, with a fully
     TRANSPARENT `background-color` (confirmed live: `rgba(0,0,0,0)`)
     — no safe fallback at all, from a separate global widget
     stylesheet (CMSScripts/Custom/Templates/Global), not this
     template's own CSS.

   KEY FINDING that shaped this fix: #contactUsEnhancedContainer
   ALREADY had `background-color:#fff` and Silktide still flagged
   every descendant as "over image" — proof that an opaque fallback
   color does NOT satisfy this check while a `background-image` is
   still present on the same element. Removing/neutralizing the
   image itself is what's required, not adding a color alongside it
   (the same lesson this ticket family's auto-contrast JS engine
   already learned about Silktide only crediting real, unobstructed
   `background-color`).

   VISUAL IMPACT, CONFIRMED via rendered before/after screenshots on
   test-vintage.sat-ws.realpage.com (docs/silktide-validation/2979417/
   before-after/ -- amenities-{before,after}-{communityAmenties,
   petPolicy,parking}.png, contact-{before,after}-form.png), not just
   reasoned from computed styles:
   - #amenityTopPanel #communityAmenties and #contactUsEnhancedContainer:
     BYTE-IDENTICAL before/after. On this SAT site the
     {#rpSite.General.BackgroundTexture#} macro resolves to an EMPTY
     filename (confirmed via network trace: the image request 302s to
     nothing), so the texture was never actually rendering here to
     begin with -- these two rules are a no-visible-op on this test
     site specifically. Silktide still flags the underlying
     `background-image` property regardless of whether the referenced
     image resolves, which is why the fix is still required even
     though nothing changes to look at here. On a live property where
     BackgroundTexture IS configured, this would visibly remove that
     texture -- same trade-off already accepted on Aurora/Elan
     (raising an overlay floor, replacing a fading gradient).
   - #divPetPolicyDetails / #divParkingDetails: real, visible change
     confirmed -- the small paw-print / parking corner icon is
     genuinely removed (these load successfully, HTTP 200, unlike the
     texture above). Text remains fully legible, no layout shift. */
#amenityTopPanel #communityAmenties {
    background-image: none !important;
}

#divPetPolicyDetails,
#divParkingDetails {
    background-color: #ffffff;
    background-image: none !important;
}

#contactUsEnhancedContainer {
    background-image: none !important;
}

/* ------------------------------------------------------------
   WCAG 2.2 AA 2.5.8 Target Size (Minimum) — TFS 3040687
   Shared-component block. IDENTICAL BYTES in every wcag-*.css —
   this issue spans 23 templates, so nothing here is template-tuned.

   Source of truth: Silktide check `ensure-minimum-target-size`
   pulled from PROD 2026-08-24 — 182 sites / 1,034 flagged elements
   (test/3040687-target-size/silktide-prod/raw-flagged.json). Every
   rule cites the bucket and the geometry Silktide reported, and each
   was measured in headless Chrome before being included.

   Specificity: `body` prefix + !important rather than this template's
   own namespace prefix. The namespace would narrow the match and miss
   elements rendered outside the template wrapper (the decoy anchor is
   one of those).

   *** NEVER ADD `display` TO A TEXT-LINK RULE HERE. ***
   MEASURED, then SEEN in a screenshot: `display:inline-block` on
   a[href*="greystar.com/privacy"] made that link drop ~9px BELOW its row-mates
   ("DISCLOSURES & LICENSES", "DMCA AGENT") in the elan08022023 footer — a
   visible zig-zag, because inline-block turns the link into an atomic box that
   carries its own padding into the line layout. Vertical padding on a plain
   INLINE link grows the hit box (what the scanner measures) while the glyphs
   stay exactly on the baseline. Padding alone is sufficient; `display` is not
   needed anywhere in this block except the decoy's `display:none`.

   *** 24.0px IS NOT ENOUGH — read before editing any value below. ***
   TFS 2955118 established empirically (see the Tableau and Ascension
   notes earlier in this file) that a target landing on EXACTLY 24.0px
   is still flagged by the scanner: ".CMSSiteMapLink at 32px passes,
   footer links at 24.0 do not." So every rule here OVERSHOOTS:
     - text links  -> vertical padding, which composes with any existing
                      padding instead of replacing it, and never caps the
                      box the way line-height does
     - icon/dots   -> 28px, not 24px
   Do NOT "tidy" these back to min-height:24px / line-height:24px. That
   reintroduces the 24.0 failure AND, because these rules carry
   !important, would override the working padding-based rules that some
   templates (e.g. Ascension) already ship.
   ------------------------------------------------------------ */

/* 1. Hidden decoy anchor — 85 rows / 29 sites, reported 54x22.
      <a href="#" tabindex="-1" aria-hidden="true" rel="nofollow"
         style="opacity:.01;position:absolute;z-index:-999">___</a>
      Not a real control. Its inline style carries no !important, so
      this wins and takes it out of hit-testing and the a11y tree. */
body a[aria-hidden="true"][tabindex="-1"][rel="nofollow"] {
    display: none !important;
}

/* 2. Site-map page links — 371 rows / 52 sites, the largest bucket.
      Reported ~71x19, stacked about one line-height apart.
      NOTE: a.CMSListMenuLink (5 rows) is deliberately EXCLUDED — that
      is the primary-nav class, and forcing line-height on it across 22
      templates risks every page's header for 5 rows. */
body a.CMSSiteMapLink {
    padding-top: 5px !important;
    padding-bottom: 5px !important;
}

/* 3. Social icon links — NOT handled here. 44 rows / 23 sites, flagged at
      11.4x24 / 17.2x24 (icon-font glyph on a `display:inline` anchor).

      MEASURED: every fleet-wide formulation broke something.
        - `display:inline-flex` + min-28  -> SHRANK compliant icons
                                             (balcony 44x44 -> 28x28, slate 33 -> 28)
        - `display:inline-block` + min-28 -> same shrink (the box comes from the
                                             parent's layout; any display override
                                             re-computes it)
        - `padding: 4px 8px` (no shrink)  -> the extra width WRAPS the icon row
                                             onto a second line: slateqanew
                                             UL.header-social 5 icons, vertical
                                             centre spread 0px -> 28.6px (visible
                                             zig-zag); emerald +8px, balcony +4px.

      The containers differ per template, so this needs a container-scoped rule,
      not a fleet-wide one. **TFS 2982346 owns social-icon target size** and has
      per-template branches for exactly this. Left to that ticket on purpose.
      Do not re-add a global `a.facebook`-style rule here. */

/* 4. Hero scroll-down affordance — 18 rows / 15 sites, reported 9x16. */
body a#scroll-down {
    padding: 6px 8px !important;
}

/* 5. Hamburger / nav toggle — reported 16x6. a.dropdown-toggle is already
      handled elsewhere in this file; only the button form is new.

      min-* rather than padding: a <button> is inline-block by default, so
      min-width/min-height apply and can only ever RAISE a dimension. An
      earlier `padding: 10px` shorthand REPLACED the button's own padding and
      grew emerald10262023's header button from 90.5x44 to 110.5x47 — 20px
      wider for no benefit, since it was already compliant. Verified with
      min-*: elan08022023 menu-toggle stays 40x35 @375 and 55x45 @1440. */
body button.menu-toggle {
    min-width: 28px !important;
    min-height: 28px !important;
}

/* 6. Carousel dots and gallery pagination.
      padding + background-clip:content-box grows the HIT AREA while the
      painted dot keeps its original size, so the carousel looks the same.
      The padding is per-widget because the dots differ in size, and with
      box-sizing:border-box the content box (= the painted area) is
      28px - 2*padding. Get this wrong and the dot visibly SHRINKS.
        .owl-dot          measured  7x7  -> padding 10px leaves  8px painted
        flexslider dots   measured 14x14 -> padding  7px leaves 14px painted */
body button.owl-dot,
body .owl-dots button.owl-dot {
    box-sizing: border-box !important;
    min-width: 28px !important;
    min-height: 28px !important;
    padding: 10px !important;
    margin-left: 2px !important;
    margin-right: 2px !important;
    background-clip: content-box !important;
}
body .flex-control-nav a,
body .flex-control-paging a {
    box-sizing: border-box !important;
    min-width: 28px !important;
    min-height: 28px !important;
    padding: 7px !important;
    background-clip: content-box !important;
}
/* a.pagination-item is deliberately NOT handled here. MEASURED REGRESSION:
   on haute011326.sat-ws the gallery tiles are
   `a.fancybox3.gallery-item.pagination-item` at display:block, 469.5x449.5.
   Forcing `display:inline-block` collapsed them to 28px and shortened the page
   by 3,936px — it destroys the gallery grid. The flagged element was a
   380x2 collapsed inline on one site (17 rows, 1 site); that is not worth
   risking every gallery on the fleet. Route it to its own ticket with a
   container-scoped selector if it matters. */

/* 7. Header / footer phone links — NOT handled here. 6 rows / 5 sites,
      flagged at ~102x19.

      MEASURED ON PROD (181-site sweep, 2026-08-25): the rule
        a.footer-phone.seo-number, a.header-phone.seo-number
          { padding-top:5px; padding-bottom:5px }
      SHRANK the phone CTA on 30 live sites — e.g. affinityatkendrick.com,
      esprialiving.com, affinityathudson.com: a.btn.footer-phone.seo-number went
      137x38 -> 137x32, and apartmentsdavie.com 175x46.6 -> 175x40.6. On those
      templates the element is a styled button whose own padding is larger than
      5px, and `padding-top/bottom` REPLACES it rather than adding to it.

      6 flagged rows is not worth a visible shrink on 30 sites. `min-height`
      would be safe but is a no-op on the inline instances that are actually
      flagged, so it would buy nothing. Needs a per-template rule that knows
      whether the phone renders as inline text or as a button. */

/* 8. "Read More" expander — 26 rows. Measured on encorerise.com: 94.5x20,
      `display:inline`, no sibling controls in its row, so vertical padding is
      safe here and lifts it to 38px.

      REMOVED from this rule after measurement, do not re-add:
        a[href*="greystar.com/privacy"] (38 rows / 7 sites) — every instance
          measured is ALREADY compliant (mirabellahouston 95.3x44,
          capitalplaceatsouthwood 94.6x44 and 132x27, thegeorgianapts 41x28).
          Padding them gained nothing and BROKE the footer legal row: on
          elan08022023 the base CSS makes that link `display:inline-block` at
          44px alongside "Disclosures & Licenses" / "DMCA Agent"; +9px padding
          grew it to 62px and dropped its centre 9px BELOW its row-mates —
          visible zig-zag, confirmed in a screenshot.
        a[href*="onlineleasing.realpage.com"] (12 rows) — no instance measured
          under 24px, so there was no evidence it needed the rule, and it
          carries the same row-breaking risk.
      Both need a per-template, container-scoped rule if they are ever a real
      failure. A fleet-wide href selector cannot tell "already fine" from
      "too small". */
body a.more-link {
    padding-top: 9px !important;
    padding-bottom: 9px !important;
}

/* 9. In-prose content links — the last and largest remaining bucket
      (~191 rows), e.g. neighbourhood/POI links inside pasted body copy:
        a "Bert Fields Park"  109.7x18  parent p.MsoNormal  prose 425 chars

      These are arguably EXEMPT under 2.5.8's Inline exception, but
      Silktide flags them, so they are padded here to clear the check.

      4px, not more: the flagged links measure 17-22px tall, so +8px lands them
      at 25-30px — clear of 24 without enlarging the box further than needed.
      Measured on thegeorgianapts-dallas.com/Neighborhood.aspx: pad 4px gives
      minHeight 26.0; pad 7px gives 32.0 but widens the box-overlap between
      links on adjacent lines from 26px to 32px for no compliance gain.

      Vertical padding on an INLINE box grows the hit area (which is what
      Silktide measures) without pushing text lines apart. Measured on
      thegeorgianapts-dallas.com/Neighborhood.aspx, altalongwood.com and
      thearialiving.com/site-map.aspx: body scrollHeight delta 0 at
      1440px, but -20px to +27px at 375px, and scrollWidth delta 0 at
      every width. None of these links carry a background-color or border
      (measured: 0 of them), so the enlarged box is invisible. So: no horizontal overflow, small vertical movement
      on mobile — QA regression check §3a in the validation guide.

      Scope is deliberately narrow — p / td / span, classless links only.
      DO NOT broaden this to `a:not([class])`: measured on
      mirabellahouston.com that also pads already-compliant 44px nav and
      footer links up to 57px, inflates the footer logo 170px -> 184px,
      and SHRANK a 44px CTA to 30px. */
body p a:not([class]),
body td a:not([class]),
body span a:not([class]) {
    padding-top: 4px !important;
    padding-bottom: 4px !important;
}
/* ---------- end WCAG 2.5.8 Target Size (TFS 3040687) ---------- */