/* ============================================================
   wcag-s0076-jackson-square.css
   WCAG 2.1 Level AA override for the S0076-Jackson-Square Kentico template
   (TemplateId 1389, DefaultCssFileName: RPcssMaster_S0076-Jackson-Square).

   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 top-bar sticky header 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,
#hamburgerNavMenuContainer 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 (UI components)
   Base failures:
     border-bottom:2px solid #efefef on menu hover/dividers
       (lines 1766, 1770, 1774) â 1.18:1 â fails 3:1.
     border-bottom:solid 2px #ddd (line 2871) â 1.59:1 â fails.
   ------------------------------------------------------------ */
#menuDesktop #menuElem li a:hover,
#menuMobile 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 text-color rules â 4.4:1 â fails 4.5:1.
     Shared footer-disclosure opacity 0.6 â 0.85.
   ------------------------------------------------------------ */
/* SCOPE NOTE: removed `.FloorPlansV3 .specification` /
   `.FloorPlansV2 .specification` color override. Verified across
   53 prod + 7 SAT Jackson-Square domains (any PMC): the
   `.FloorPlansV2 .specification strong` color varies per property
   with 28+ distinct brand values, including #964c44 (Gorman default,
   14 properties), #babd34 (Greystar's themckenzieapts), #40c1f1
   (cyan), #03700e (green), #c2072e (red), and many others. Forcing
   `#595959` would replace per-property brand accents with generic
   gray on every site. Brand-color contrast failures belong at the
   property-CSS level. See per-property-base-css memory. */

.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 bleed bug)
   — they would underline footer nav, header nav, sidebar lists,
   and disclosure paragraphs unintentionally.

   TFS 2985969 — added `.topContent`, `.page_neighborhood` and
   `#contactusPrivacy`:
     * Neighborhood prose links (B2 Bar and Grill, Mezza Luna
       Pizzeria, Costco, Trader Joe's, Valley River Center) sit in
       `.topContent` / `.page_neighborhood`, not `.mainContent` —
       confirmed live on themckenzieapts.com/Neighborhood.aspx.
       The base even styles them explicitly
       (RPcssMaster_S0076-Jackson-Square.css:336
        `.topContent a, .topContent a:hover, .topContent a:focus
         { color: RPcolor4 }`) — brand color and nothing else, i.e.
       colour-only distinction.
     * `#privacyDiv a` — the Contact-page privacy link. NOTE: the
       id on this template is `#privacyDiv`, NOT `#contactusPrivacy`
       (that id belongs to Elan/Balcony/Teracy and does not exist on
       Jackson-Square — measured 0 occurrences on
       themckenzieapts.com/Contact.aspx). The live chain is
         main#main-content > .page-placeholder-container
           > .page_contactus > … > .mainContent
             > .contact-us-enhanced > #contactUsEnhancedContainer
               > .row > .col-md-6 > #privacyDiv > label > a
       This file has no `.mainContent a` selector (that is
       Zen-Garden's), and the pre-existing homepage rule is scoped
       to `#homeContactCallout #privacyDiv a`, which this Contact-page
       instance is NOT under — so it was uncovered. `#privacyDiv a`
       is therefore deliberately left UNSCOPED.
       `#contactusPrivacy a` is kept as harmless defence-in-depth in
       case a template variant emits it.
       The wrapper's `timeout-error-contact` class is NOT a hider —
       it is hardcoded on the always-rendered container
       (ContactUsEnhanced.ascx.cs:317) and only namespaces an
       optional child `.timeout-message`, so this link is
       user-facing.

   Bleed check: `.page_neighborhood` is the page-content wrapper
   authored in S0076-Jackson-Square-Neighborhood.ascx:5 and
   `.topContent` is the standard content-zone wrapper. Both render
   inside `<main id="main-content">` per
   S0076-Jackson-Square-Master.ascx:11-13, while `<header>`,
   `zoneNavBar`, `zoneHamburgerMenu` and `<footer>` are all
   siblings OUTSIDE `<main>` — so no site nav/header/footer anchor
   can ever match these two selectors.
   ------------------------------------------------------------ */
.main-content-text a,
.inner-page-main a,
.main-content-wrapper a,
.topContent a,
.page_neighborhood a,
#contactusPrivacy a,
#privacyDiv a {
  text-decoration: underline;
  text-underline-offset: 2px;
}

a.btn,
a.button,
.btn,
.btn-primary,
header a,
nav a,
#hamburgerNavMenuContainer a,
.cta-header-btn,
.header-CTA-button,
.footer-CTA-Button,
a.more-link,
a.less-link,
.footer-widget footer a {
  text-decoration: none;
}

/* TFS 2985969 — re-assert the shape-based opt-outs at container
   scope. `.topContent a` / `.page_neighborhood a` are (0,1,1),
   which out-specifies the bare class opt-outs above that are only
   (0,1,0) (`.btn-primary`, `.cta-header-btn`, `.header-CTA-button`,
   `.footer-CTA-Button`) and the bare element opt-outs at (0,0,2)
   (`header a`, `nav a`). The (0,1,1) opt-outs (`a.btn`, `a.button`,
   `a.more-link`, `a.less-link`) already win on source order, and
   `.footer-widget footer a` (0,1,2) and
   `#hamburgerNavMenuContainer a` (1,0,1) already out-specify — but
   the weaker ones must be lifted so a button-shaped or in-page nav
   anchor inside a content zone is not underlined. */
.topContent header a,
.topContent nav a,
.topContent a.btn-primary,
.topContent a.cta-header-btn,
.topContent a.header-CTA-button,
.topContent a.footer-CTA-Button,
.page_neighborhood header a,
.page_neighborhood nav a,
.page_neighborhood a.btn-primary,
.page_neighborhood a.cta-header-btn,
.page_neighborhood a.header-CTA-button,
.page_neighborhood a.footer-CTA-Button,
/* Measured live under `.page_neighborhood` / `.topContent` on
   themckenzieapts.com — utility/control anchors, not prose:
   `a#directionsLink` is the 15th anchor under `.page_neighborhood`
   (it sits outside `.topContent`); `a.seo-number` is the tel: link;
   `a.sectionLink` is a section jump link. */
.page_neighborhood a#directionsLink,
.topContent a#directionsLink,
a#directionsLink,
.page_neighborhood a.seo-number,
.topContent a.seo-number,
a.seo-number,
.page_neighborhood a.sectionLink,
.topContent a.sectionLink,
a.sectionLink,
.page_neighborhood a.galleryButton,
.page_neighborhood a.leaseTodayButton,
.topContent a.galleryButton,
.topContent a.leaseTodayButton {
  text-decoration: none;
}

/* ------------------------------------------------------------
   TFS 2985969 — WCAG 1.4.1, interaction states
   The base strips the underline on every interaction state with
   an !important rule:
     RPcssMaster_S0076-Jackson-Square.css:329-333
       body a:hover, body a:focus, body a:active
         { text-decoration: none !important; ... }
   Specificity (0,1,2) + !important, so it beats the plain
   rest-state underline above and the link becomes colour-only
   again the moment it is hovered or keyboard-focused — the
   defect reproduced live on themckenzieapts.com.

   Counter it with a content-scoped !important. Each selector here
   (e.g. `.topContent a:hover` = (0,2,1)) out-specifies
   `body a:hover` (0,1,2) in the class column, so among competing
   !important declarations ours wins. Deliberately NOT a bare
   `body a:hover` counter — nav/header/footer anchors must keep
   the base `none` on interaction.
   ------------------------------------------------------------ */
.main-content-text a:hover, .main-content-text a:focus, .main-content-text a:active,
.inner-page-main a:hover, .inner-page-main a:focus, .inner-page-main a:active,
.main-content-wrapper a:hover, .main-content-wrapper a:focus, .main-content-wrapper a:active,
.topContent a:hover, .topContent a:focus, .topContent a:active,
.page_neighborhood a:hover, .page_neighborhood a:focus, .page_neighborhood a:active,
#contactusPrivacy a:hover, #contactusPrivacy a:focus, #contactusPrivacy a:active,
#privacyDiv a:hover, #privacyDiv a:focus, #privacyDiv a:active,
.expandable.home a:hover, .expandable.home a:focus, .expandable.home a:active,
#homeContactCallout #privacyDiv a:hover, #homeContactCallout #privacyDiv a:focus, #homeContactCallout #privacyDiv a:active {
  text-decoration: underline !important;
  text-underline-offset: 2px;
}

/* Companion opt-out: keep button/CTA/heading-shaped links inside
   content zones un-underlined on interaction too. Needs the same
   !important to compete with the rule directly above. This list
   mirrors the rest-state opt-out shapes exactly — the two must
   stay in sync, otherwise an anchor stays clean at rest but picks
   up an underline the moment it is hovered or focused. */
.topContent header a:hover, .topContent header a:focus, .topContent header a:active,
.topContent nav a:hover, .topContent nav a:focus, .topContent nav a:active,
.topContent a.cta-header-btn:hover, .topContent a.cta-header-btn:focus, .topContent a.cta-header-btn:active,
.topContent a.header-CTA-button:hover, .topContent a.header-CTA-button:focus, .topContent a.header-CTA-button:active,
.topContent a.footer-CTA-Button:hover, .topContent a.footer-CTA-Button:focus, .topContent a.footer-CTA-Button:active,
.page_neighborhood header a:hover, .page_neighborhood header a:focus, .page_neighborhood header a:active,
.page_neighborhood nav a:hover, .page_neighborhood nav a:focus, .page_neighborhood nav a:active,
.page_neighborhood a.cta-header-btn:hover, .page_neighborhood a.cta-header-btn:focus, .page_neighborhood a.cta-header-btn:active,
.page_neighborhood a.header-CTA-button:hover, .page_neighborhood a.header-CTA-button:focus, .page_neighborhood a.header-CTA-button:active,
.page_neighborhood a.footer-CTA-Button:hover, .page_neighborhood a.footer-CTA-Button:focus, .page_neighborhood a.footer-CTA-Button:active,
.main-content-text a.btn:hover, .main-content-text a.btn:focus, .main-content-text a.btn:active,
.main-content-text a.button:hover, .main-content-text a.button:focus, .main-content-text a.button:active,
.main-content-text a.more-link:hover, .main-content-text a.more-link:focus, .main-content-text a.more-link:active,
.main-content-text a.less-link:hover, .main-content-text a.less-link:focus, .main-content-text a.less-link:active,
.topContent a.btn:hover, .topContent a.btn:focus, .topContent a.btn:active,
.topContent a.button:hover, .topContent a.button:focus, .topContent a.button:active,
.topContent a.btn-primary:hover, .topContent a.btn-primary:focus, .topContent a.btn-primary:active,
.topContent a.more-link:hover, .topContent a.more-link:focus, .topContent a.more-link:active,
.topContent a.less-link:hover, .topContent a.less-link:focus, .topContent a.less-link:active,
.page_neighborhood a.btn:hover, .page_neighborhood a.btn:focus, .page_neighborhood a.btn:active,
.page_neighborhood a.button:hover, .page_neighborhood a.button:focus, .page_neighborhood a.button:active,
.page_neighborhood a.btn-primary:hover, .page_neighborhood a.btn-primary:focus, .page_neighborhood a.btn-primary:active,
.page_neighborhood a.more-link:hover, .page_neighborhood a.more-link:focus, .page_neighborhood a.more-link:active,
.page_neighborhood a.less-link:hover, .page_neighborhood a.less-link:focus, .page_neighborhood a.less-link:active,
.amenitiesCalloutHeader a:hover, .amenitiesCalloutHeader a:focus, .amenitiesCalloutHeader a:active,
.homeFloorPlanNeighborhoodCalloutHover a:hover, .homeFloorPlanNeighborhoodCalloutHover a:focus, .homeFloorPlanNeighborhoodCalloutHover a:active,
.contactCalloutHeader a:hover, .contactCalloutHeader a:focus, .contactCalloutHeader a:active,
.expandable.home a.btn:hover, .expandable.home a.btn:focus, .expandable.home a.btn:active,
.expandable.home a.button:hover, .expandable.home a.button:focus, .expandable.home a.button:active,
.expandable.home a.galleryButton:hover, .expandable.home a.galleryButton:focus, .expandable.home a.galleryButton:active,
.expandable.home a.leaseTodayButton:hover, .expandable.home a.leaseTodayButton:focus, .expandable.home a.leaseTodayButton:active,
.expandable.home a#leaseToday:hover, .expandable.home a#leaseToday:focus, .expandable.home a#leaseToday:active,
.expandable.home a#letsMeet:hover, .expandable.home a#letsMeet:focus, .expandable.home a#letsMeet:active,
header #directionsLink:hover, header #directionsLink:focus, header #directionsLink:active,
.header-phone:hover, .header-phone:focus, .header-phone:active,
.mobiHeader .seo-number:hover, .mobiHeader .seo-number:focus, .mobiHeader .seo-number:active,
.sidebarFlex .seo-number:hover, .sidebarFlex .seo-number:focus, .sidebarFlex .seo-number:active,
#navBarRightContent a.leaseTodayButton:hover, #navBarRightContent a.leaseTodayButton:focus, #navBarRightContent a.leaseTodayButton:active {
  text-decoration: none !important;
}

/* TFS 2985969 — PR review follow-up (Melissa Gibson): the three selectors
   above were previously bare (`a#directionsLink`, `a.seo-number`,
   `a.leaseTodayButton`, all page-global, no container scope). `a.seo-number`
   in particular is the class the standalone PhoneNumber.ascx widget renders
   with NO companion class (Header.ascx's own header-phone links add a
   `header-phone` class alongside `seo-number` specifically for this
   reason) — so a bare, !important, unscoped rule would strip the underline
   from a tel: link authored inline in body prose too (routine on Contact/
   Neighborhood copy), turning this 1.4.1 fix into a 1.4.1 failure on
   authored content. Rescoped to `.header-phone` (the header-only
   discriminator) instead of the reusable `seo-number` class. `#directionsLink`
   is confirmed (Header.ascx:313,371) to only ever render inside `<header>`,
   so `header #directionsLink` is safe. `a.leaseTodayButton` is scoped to
   `#navBarRightContent`, its confirmed nav-bar container in the base CSS —
   it also already has `.expandable.home`/`.topContent` scoped copies above
   for its homepage-CTA placements, so this catches only the remaining
   nav-bar instance.

   `a.galleryButton` and `a.sectionLink` were intentionally left OUT of this
   rescoping, for different reasons:
   - `a.galleryButton` has base-CSS `background-color`/`padding`/`border`
     (RPcssMaster_S0076-Jackson-Square.css:1326) — a button shape, not
     inline prose text, so it's outside 1.4.1's link-in-text-block scope
     regardless of where it renders. Left bare/global, matching this file's
     convention for other button-shape opt-outs (`.btn`, `.button`).
   - `a.sectionLink` could NOT be located in any `.ascx`/`.ascx.cs` markup
     across CMS/RPWebParts or the Jackson-Square Shared templates (repo
     search, case-insensitive) despite existing in the base CSS
     (RPcssMaster_S0076-Jackson-Square.css:1348, no `!important` there).
     Left bare rather than guess an unverified container — flagged to
     Melissa as an open question in the PR thread.

   Round 2 (Melissa Gibson): `.header-phone` alone missed other genuine
   Header.ascx chrome instances of `a.seo-number` that render WITHOUT the
   `header-phone` companion class — the mobile top-bar phone number
   (`.mobiHeader > a.seo-number`, Header.ascx:287/325) and the off-canvas
   sidebar phone number (`.sidebarFlex.sidebar-footer > a.seo-number`,
   Header.ascx:310/368, inside `pnlHeader9`/`pnlHeader10`). Both wrapper
   classes (`mobiHeader`, `sidebarFlex`) are confirmed Header.ascx-only
   (repo search) so `.mobiHeader .seo-number` / `.sidebarFlex .seo-number`
   add coverage for these two chrome contexts without reopening the
   authored-prose risk `.header-phone` was scoped to avoid in the first
   place. */

/* ------------------------------------------------------------
   TFS 2870264 — WCAG 1.4.1 (homepage inline links)
   Jackson-Square's homepage stacks numbered section wrappers
   (`.headerContainer > .topContent`) and surfaces welcome prose
   inside `.expandable.home` (the rich-text editor block under
   the "Welcome Home" h1). Verified against
   jacksonsquare.ws.realpage.com.
   The amenities/floor-plans/neighborhood section anchors wrap
   `<h2>` headings (`.amenitiesCalloutHeader a`,
   `.homeFloorPlanNeighborhoodCalloutHover a`,
   `.contactCalloutHeader a`) — those are heading links, not
   prose links, so opted out.
   The contact form's privacy-policy link sits under
   `#privacyDiv > label > a` (inside `#homeContactCallout`) —
   underlined explicitly so the inline form-instruction link
   has a non-color indicator.
   ------------------------------------------------------------ */
.expandable.home a,
#homeContactCallout #privacyDiv label a,
#homeContactCallout #privacyDiv a {
  text-decoration: underline;
  text-underline-offset: 2px;
}

.amenitiesCalloutHeader a,
.homeFloorPlanNeighborhoodCalloutHover a,
.contactCalloutHeader a,
.expandable.home a.btn,
.expandable.home a.button,
.expandable.home a#leaseToday,
.expandable.home a#letsMeet,
.expandable.home a.galleryButton,
.expandable.home a.leaseTodayButton {
  text-decoration: none;
}

/* ------------------------------------------------------------
   TFS 2985969 — Google Maps bleed opt-out (measured live)
   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. 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.

   FIX (TFS 2987209, fleet rescan 2026-08): the checkbox rule above renders
   box-sizing:border-box (confirmed live via computed style on all 8
   templates carrying this exact block), so the CSS containing block for
   this ::before (the padding box) is only 24px - 2*2px border = 20x20, not
   24x24. The original -12px inset was sized against the 24x24 assumption,
   so it actually produced a 20+2*12=44x44 overlay - exactly at the SC
   2.5.5 floor with zero cushion, which is why it measured as a genuine
   misclick onto the adjacent privacy-policy link on Ascension/Aurora/Bliss
   (live elementFromPoint hit-test, 2026-08-19) and as a 1-6px shortfall
   elsewhere once combined with per-template line-height jitter. Bumping
   each inset by 2px (one border-width) restores the intended 48x48
   cushion (20 + 2*14) regardless of box-sizing - re-verified live:
   elementFromPoint at every point in the overlay, including the corner
   nearest the link, now resolves to the checkbox with no measured
   encroachment onto the link/label. */
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: -14px; left: -14px; right: -14px; bottom: -14px;
}

/* ------------------------------------------------------------
   TFS 2982346 - WCAG 2.2 AA 2.5.8 Target Size (Pointer): footer links

   Live-measured on testwinjacksonsquare083123.sat-ws.realpage.com/Contact.aspx at 1280x900 (headless Chrome,
   border-box heights): 19 of 22 footer targets under 24px. Every one is display:inline inside a 30px line box, and all but one are 22px tall - 2px short.

     footer div#footerLogo1 a / div#footerLogo2 a        22px
     footer #footerLinks ul#menuElem li.site-map a
       / li.privacy a                                    22px
     footer .social_media ul.social-list li a            22px (13 icons)
     footer .rplogo a                                    22px (RealPage mark)
     footer .ccpa-widget-text a                          18 x 34.2 (CCPA opt-out)

   Because the line box is already 30px, raising the box to 24px is absorbed by
   existing leading: no layout shift, no padding, no negative-margin cancel.

   ul#menuElem is scoped under `footer` deliberately - this template renders the
   same id again in the hamburger drawer (`#hamburgerNavMenu > ul#menuElem`),
   which is outside this ticket's footer scope.

   The RealPage logo wrapper carries an ASP.NET-generated id
   (`rplogo_p_lt_zoneFooter_WebPartZone3_...`) that changes with zone nesting, so
   it is matched on its stable `.rplogo` class instead.


   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 has NO `.footer-widget` element at all (0 in the live DOM), so the Tableau/Ascension
   prefix selects NOTHING here. Verified against the live SAT DOM.
   ------------------------------------------------------------ */
footer div#footerLogo1 a,
footer div#footerLogo2 a,
footer ul#menuElem li a,
footer .social_media ul.social-list li a,
footer .rplogo a,
footer .ccpa-widget-text a {
    display: inline-block;
    min-height: 24px;
}

/* Social glyphs are icon-font/SVG and narrower than 24px on some brands. */
footer .social_media ul.social-list li a {
    min-width: 24px;
}

footer .rplogo a svg {
    height: 20px;
}

/* ------------------------------------------------------------
   TFS 2987209 — WCAG 2.2 AAA 2.5.5 Target Size (Enhanced), 44x44
   S0076-Jackson-Square footer nav links. Measured live at
   375/768/1440 with CDP CSS.getMatchedStylesForNode, then injected
   and re-measured with elementFromPoint hit-tests.

   THE HEADER IS DELIBERATELY NOT TOUCHED ON THIS TEMPLATE. Every
   header target already passes on its own: the 7 hamburger-drawer
   nav links measure 71-74px tall at every viewport, both
   a.seo-number instances (top bar + drawer) 54px, a.leaseTodayButton
   ("LEASE NOW") 54px, and button#hamburgerMenuButton 50px. Applying
   this file's usual display:inline-block treatment to the drawer
   links would actively SHRINK them 74px -> 69px, trading an inline
   box's font-metric height for a smaller line-height-derived one.
   Still passing, but a pointless regression — so no header rule is
   emitted here. Do not "complete" this stanza by adding one.

   SCOPE — this template renders id=menuElem TWICE (once in the
   hamburger drawer, once in the footer), so a bare `#menuElem li a`
   would silently reach back into the header links described above.
   The #footerLinks ancestor is load-bearing, not decoration. Same
   hazard the 2.5.8 block above solves with its `footer` prefix.

   display:inline-block IS REQUIRED — min-height alone is a NO-OP.
   These anchors compute to display:inline, and per CSS 2.1 s10.7
   min-height does not apply to non-replaced inline boxes; injecting
   min-height:44px by itself measured 22px BEFORE and 22px AFTER.
   It is emitted explicitly rather than inherited from the 2.5.8
   rule above, so that rescoping or removing that rule cannot
   quietly turn this fix into dead CSS.

   line-height:44px is for optical centring: without it the label
   sits ~14px off centre, which reads badly now that the two links
   abut (see below).

   REVIEWER NOTE — the vertical gap between "Site Map" and "Privacy
   Policy" closes from 8px to 0px once they grow to 44px; they end
   up touching. elementFromPoint at 5 probe points per link (centre
   + 4 edges) confirms each still resolves to its own anchor with no
   click-stealing, and no horizontal overflow is introduced.

   No !important: at 2 IDs this outranks the 2.5.8 rule above
   (`footer ul#menuElem li a`, 1 ID) and nothing else in any loaded
   stylesheet declares height/min-height/display on these anchors.
   Widths already pass (75.17px / 118.45px), so no min-width.
   ------------------------------------------------------------ */
#footerLinks #menuElem li a {
    display: inline-block;
    min-height: 44px;
    line-height: 44px;
}

/* ------------------------------------------------------------
   TFS 2987209 — WCAG 2.2 AAA 2.5.5 Target Size (Enhanced), 44x44
   S0076-Jackson-Square page-content phone link (Contact.aspx).

   FOUND LATE, outside the original "header already passes" survey.
   This template has THREE a.seo-number instances. Two are header
   chrome (top bar + hamburger drawer) and already measure 54px —
   they are untouched, and the ID scope below is what keeps them
   that way. The third lives in the Contact page's own content
   under #propContactInfo and measures 137.17 x 20, failing BOTH
   2.5.8 (24px) and 2.5.5 (44px). Height is the only failure; the
   width already passes by a wide margin, so no min-width.

   Same technique and same reason as the footer stanza above:
   display:inline-block is mandatory because the anchor computes to
   display:inline and min-height does not apply to non-replaced
   inline boxes (CSS 2.1 s10.7), and line-height:44px centres the
   label optically inside the taller box.

   The ID scope also keeps this clear of the WCAG 1.4.1 rules
   earlier in this file that match bare `a.seo-number` /
   `.topContent a.seo-number` — those set text-decoration only and
   are unaffected. No !important: nothing in any loaded stylesheet
   declares height/min-height/display on this anchor.
   ------------------------------------------------------------ */
#propContactInfo a.seo-number {
    display: inline-block;
    min-height: 44px;
    line-height: 44px;
}

/* ------------------------------------------------------------
   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) ---------- */
