/* ============================================================
   wcag-s0063-au-courant.css
   WCAG 2.1 Level AA override for the S0063-Au-Courant Kentico template
   (TemplateId 1338, DefaultCssFileName: RPcssMaster_S0063-Au-Courant).

   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. No
   position:fixed in master CSS — sticky header comes from
   shared resources.
   ============================================================ */


/* ------------------------------------------------------------
   WCAG 2.4.7 Focus Visible
   ------------------------------------------------------------ */
.navbar-toggle:focus-visible,
.dropdown-toggle:focus-visible,
.btn:focus-visible,
.form-control:focus-visible,
header a:focus-visible,
nav a:focus-visible,
.contact-us-enhanced .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
   ------------------------------------------------------------ */
html {
  scroll-padding-top: 100px;
}

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


/* ------------------------------------------------------------
   WCAG 1.4.11 Non-text Contrast (form controls)
   #contactUsEnhancedContainer .form-control failure comes from
   shared webpart CSS. Specificity strategy matches Ron's Haute.
   ------------------------------------------------------------ */
body #contactUsEnhancedContainer .form-control {
  border-bottom: 1px solid #595959 !important;
}


/* ------------------------------------------------------------
   TFS 2871246 — WCAG 1.4.11 (homepage "Ready to Tour?" form)
   The homepage uses the ContactUsFloating widget (separate from
   the /Contact.aspx #contactUsEnhancedContainer form handled
   above). Markup: `<footer class="footerContact"> ... .contact-
   mobile-form .contactus-float-input-div input/select`.
   Inputs render white with no visible border on the template's
   orange/peach hero band — fails 3:1 against the surroundings.
   Full border (not just bottom) so the control is defined on
   any background.
   ------------------------------------------------------------ */
body .contact-mobile-form .contactus-float-input-div input,
body .contact-mobile-form .contactus-float-input-div select,
body .contact-mobile-form .contactus-float-input-div textarea,
body .contactus-float-input-div input,
body .contactus-float-input-div select,
body .contactus-float-input-div textarea,
body .contact-mobile-form input.body-txt1,
body .contact-mobile-form select.body-txt1 {
  border: 1px solid #595959 !important;
}

body .contact-mobile-form input::placeholder,
body .contact-mobile-form textarea::placeholder {
  color: #595959;
  opacity: 1;
}


/* ------------------------------------------------------------
   WCAG 1.4.3 Contrast Minimum (text)
   Base failures:
     #7e7e7e in 6+ rules ≈ 4.4:1 — fails 4.5:1.
     #999 (line 226) ≈ 2.85:1 — clearly fails.
     Shared footer-disclosure opacity 0.6 → 0.85.
   ------------------------------------------------------------ */
.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 {
  text-decoration: underline;
  text-underline-offset: 2px;
}

a.btn,
a.button,
.btn,
.btn-primary,
header a,
nav 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)
   Au-Courant's homepage uses `.slider` rows with
   `.cta2Content` / `.cta3Content` / `.cta4Content` content
   columns; inline prose sits in `.leftCol` / `.rightCol`
   under each. Verified against 24merrimackstreet.com (inline
   link "View our amenities." inside `.cta2Content .leftCol`).
   ------------------------------------------------------------ */
.slider .cta2Content a,
.slider .cta3Content a,
.slider .cta4Content a,
.cta2Content .leftCol a,
.cta2Content .rightCol a,
.cta3Content .leftCol a,
.cta3Content .rightCol a,
.cta4Content .leftCol a,
.cta4Content .rightCol a {
  text-decoration: underline;
  text-underline-offset: 2px;
}

.cta2Content a.btn,
.cta2Content a.button,
.cta3Content a.btn,
.cta3Content a.button,
.cta4Content a.btn,
.cta4Content a.button {
  text-decoration: none;
}


/* ------------------------------------------------------------
   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 2982346 - WCAG 2.2 AA 2.5.8 Target Size (Pointer): footer links

   Live-measured on testwinaucourantsat102523.sat-ws.realpage.com/Contact.aspx at 1280x900 (headless Chrome,
   border-box heights): 20 of 28 footer targets under 24px - the worst of the GS-22 set.

     footer .social_media ul.social-list li a   19px tall, narrowest 28.2px wide
                                                (13 icons)
     footer div#footerAddress a                 19 x 16 - fails on BOTH axes
     footer .footer-8 .residentLogin a / .tour a          15px, line-height 60px
     footer .footerRightLinks .privacy a / .sitemap a
       / .additional-footer-link a                        15px, line-height 60px
     footer a#link-rp                                     15px, line-height 60px

   The 15px group sits inside a 60px line box, so raising the box to 24px is
   absorbed by existing leading - no layout shift, and no negative-margin cancel
   is wanted (these are stacked, where a cancel would overlap hit areas).

   min-width matters here and not on the other templates: #footerAddress a is
   16px WIDE, so a height-only rule would leave it failing.

   The social list is scoped under `footer` deliberately - this template renders
   a SECOND .social-list in the header (`header #mainNavHeader .socialMedia-menu`)
   which is outside this ticket's footer scope.


   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 .social_media ul.social-list li a,
footer div#footerAddress a {
    display: inline-block;
    min-width: 24px;
    min-height: 24px;
}

footer .footer-8 .residentLogin a,
footer .footer-8 .tour a,
footer .footerRightLinks .privacy a,
footer .footerRightLinks .sitemap a,
footer .footerRightLinks .additional-footer-link a,
footer a#link-rp {
    display: inline-block;
    min-height: 24px;
}

footer a#link-rp svg {
    height: 20px;
}

/* ------------------------------------------------------------
   TFS 2987209 — WCAG 2.2 AAA 2.5.5 Target Size (Enhanced), 44x44
   S0063-Au-Courant header nav / phone / header actions.
   Measured live at 375/768/1440 with CDP CSS.getMatchedStylesForNode
   on the exact nodes measured. This template does NOT load
   assets/common/header/css/header.css and does not use the shared
   Header widget — its header is template-native markup, so the fix
   belongs here rather than in a shared file. The WCAG override
   loads at document.styleSheets[7], after the master at [0], so
   plain rules win: no !important is needed and none is used.

   Technique: min-height/min-width + box-sizing:border-box, never
   padding and never a ::before overlay. min-* is uncontested on
   these selectors and, per CSS2.1 §10.7, is applied last in height
   resolution, so it beats any competing height/max-height without a
   specificity fight. Overlays are rejected fleet-wide on this
   ticket: vertical clearance between nav links measures 8.00px here,
   far below the ~25px an overlay would need, and an overlay was
   already live-measured stealing clicks on another template. A
   direct grow reflows instead — it pushes siblings in normal flow
   and cannot overlap them.
   ------------------------------------------------------------ */

/* Header drawer nav: measured 176.39x43 — it fails height by
   exactly 1px, at all three viewports. The base rule already sets
   display:inline-block, position:relative, height:100% and
   line-height:35px; box-sizing + min-height simply clamps the used
   height up to 44. Growing by 1px against an 8.00px inter-link gap
   reflows harmlessly.
   Width is deliberately untouched: the anchor is width:70% of its
   row, which means the remaining 30% of each li is not clickable —
   worth noting for a future pass, but the anchor already passes the
   44px width requirement at 176.39px, so widening it is out of
   scope for 2.5.5 and would alter the hover affordance. */
body #form .mainNav #menuElem li a {
    box-sizing: border-box;
    min-height: 44px;
}

/* Phone: ONE instance on this template. At 375 the anchor is
   10.30x0 — font-size:0 puts the glyph entirely in ::before — so it
   fails on BOTH axes and needs min-width as well. At 768/1440 it is
   111.03x19 and needs height only; min-width is a no-op there.
   ::before is occupied by the icon glyph on this element and is
   deliberately not touched. */
body #form .headerTopBar .topPhone a.seo-number {
    box-sizing: border-box;
    display: inline-block;
    min-width: 44px;
    min-height: 44px;
}

/* "Resident Access" — 199x34 at 768/1440 (fails), 188x50 at 375
   (already passes; the rule is a no-op there). Height only, and
   display is deliberately NOT changed: this element is
   display:block; width:100%, exactly the shape that collapsed
   199.7px -> 47.5px on another template when converted to
   inline-block. */
body #form .headerTopBar .residentAccess a {
    box-sizing: border-box;
    min-height: 44px;
}
/* NOT fixed here, deliberately:
   - The hero-slider nav (.heroSlider #menuElem li a) already passes
     at every viewport (125.72x165 at 1440) and is display:block;
     width:100% — the width-collapse shape. Left alone.
   - The footer drawer's 8 links (#mainNavFooter #menuElem li a) are
     UNREACHABLE: #footerMenu has jQuery click/mouseover bound but
     neither a native nor a triggered click moves #mainNavFooter off
     left:-300px. Open-state geometry is unmeasured, so no rule is
     written for markup that cannot be reached. Raised separately. */

/* TFS 2987209 — WCAG 2.2 AAA 2.5.5 Target Size (Enhanced): FlexSlider dot
   pager, second slider specifically (/Amenities.aspx `#amenityTopPanel`).
   Production completeness sweep (2026-08-20) pinpointed this instance at
   8x8 — the fleet-wide shared fix in
   App_Themes/Global/RPWebParts/flexslider.css (`.flex-control-paging li a`,
   TFS 2987209) does NOT reach it: rpWebpartCss_AmenitiesExtended.css
   carries its own `#amenityTopPanel .flex-control-paging li a` rule
   (ID-scoped, higher specificity) that re-sets literal `width:8px;
   height:8px` — a small colored square swatch, not the circular dot the
   shared fix repaints. The first/main slider on this template already
   passes (not this rule's selector) — this is scoped to the Amenities
   top-panel instance only, per the sweep's own pinpointing.

   CORRECTED 2026-08-20 (independent live re-verification of this rule): a
   transparent ::before overlay at -18px landed at 40x40 (border-box math
   error — the ID-scoped rule's 8px width/height is ALREADY the full
   border-box size here, so -18px on each side gives 4+2*18=40, not 44)
   AND, independent of that, made things WORSE than shipping nothing: at
   this template's 12px dot pitch (8px dot + 4px li margin), any ~40-44px
   overlay necessarily overlaps 3+ neighboring dots, and since overlays
   paint in DOM order, every dot but the last had its click stolen by the
   next one — confirmed live, off-by-one slide selection on all 3 domains.
   An overlapping hit-area cannot work at this pitch; the shared fleet-wide
   fix in flexslider.css solves the identical problem by turning the
   anchor itself into the 44x44 box (with the small dot painted via
   ::after instead of literal width/height) rather than overlaying a
   hit-zone on top of an unchanged tiny swatch. Same technique applied
   here, ID-scoped to this instance only — preserves the square swatch
   shape and RPcolor-driven active/inactive coloring instead of adopting
   the shared fix's circular dot, since this instance's visual design
   differs from the fleet default and Gate 1 never signed off on
   changing it.

   CORRECTED AGAIN 2026-08-20 (independent re-verification of the first
   correction): confirmed the wrong-slide regression is genuinely gone
   (0/64 wrong-slide selections across every dot, all 3 domains, two
   passes) -- but the first correction introduced four new defects, all
   fixed below:
   (1) The `li` margin bump to 18px was unnecessary and wrong -- the
   44px anchor already establishes pitch on its own; 44+4=48px pitch
   fits 6 dots in the 300px-wide nav container (288px) with room to
   spare, so the ORIGINAL margin (0 0 0 4px, from
   rpWebpartCss_AmenitiesExtended.css, left un-overridden here) is kept.
   The 18px bump pushed the row to 372px, wrapping it into 2 rows on the
   5- and 6-dot domains, landing wrapped dots in the middle of the
   amenity photos. Removed the li-margin rule entirely.
   (2) `background:none` on the anchor never reached the ACTIVE dot: the
   source file's `...li a.flex-active` selector is more specific
   ((1,2,2) vs this file's (1,1,2)) and its `background: RPcolor3`
   still won, painting the whole 44x44 anchor as a solid filled square
   instead of a transparent box with a small ::after swatch. Added an
   explicit override on the anchor's own `.flex-active` state.
   (3) Every inactive dot was silently repainted solid dark grey by this
   site's own contrast-remediation script within ~30s of load -- it saw
   forced-white anchor text sitting on a now-transparent box (an
   accessibility-contrast trigger) and injected an inline
   `background-color` fix, since the anchor still carries real (if
   visually tiny) text content. Added `text-indent: -9999px`, the same
   declaration the fleet-wide flexslider.css fix already uses on its own
   44x44 anchor for the identical reason -- it moves the text off-screen
   instead of leaving it invisible-but-present, so the contrast script
   has nothing to flag.
   (4) The ::after swatch rendered as a circle, not the square this
   comment has claimed twice now -- `border-radius` was never reset and
   inherited the fleet fix's `border-radius: 20px` from the general
   `.flex-control-paging li a::after` rule. Added `border-radius: 0`. */
#amenityTopPanel .flex-control-paging li a {
    box-sizing: border-box;
    width: 44px;
    height: 44px;
    display: block;
    position: relative;
    background: none;
    border: none;
    box-shadow: 0 0 0 0;
    text-indent: -9999px;
}
#amenityTopPanel .flex-control-paging li a.flex-active {
    background: none;
    border: none;
}
#amenityTopPanel .flex-control-paging li a::after {
    content: "";
    position: absolute;
    top: 18px;
    left: 18px;
    box-sizing: border-box;
    width: 8px;
    height: 8px;
    border-radius: 0;
    background: #{% ProcessCustomMacro("RPcolor1", "") %};
    border: 2px solid #c5c3c5;
}
#amenityTopPanel .flex-control-paging li a.flex-active::after {
    background: #{% ProcessCustomMacro("RPcolor3", "") %};
    border: 2px solid #{% ProcessCustomMacro("RPcolor3", "") %};
}

/* ------------------------------------------------------------
   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) ---------- */