/* ============================================================
   wcag-s0065-tableau.css
   WCAG 2.1 Level AA override for the S0065-Tableau Kentico template
   (TemplateId 1344, DefaultCssFileName: RPcssMaster_S0065-Tableau).

   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.
   Layout: .desktopMenu is a position:fixed LEFT sidebar
   (width:16.666667%) — does not obscure focus vertically.
   Only #mobile-nav-header (50px top bar) needs scroll-padding
   compensation, and only on mobile.
   ============================================================ */


/* ------------------------------------------------------------
   WCAG 2.4.7 Focus Visible
   Base AGGRESSIVELY suppresses focus rings globally:
     :focus { outline:-webkit-focus-ring-color auto 0 !important }
   The !important + width 0 means our override must use
   !important to win.
   ------------------------------------------------------------ */
:focus-visible,
.navbar-toggle:focus-visible,
.dropdown-toggle:focus-visible,
.btn:focus-visible,
.form-control:focus-visible,
.desktopMenu a:focus-visible,
#mobile-nav-header a:focus-visible,
.sp-left-arrow:focus-visible,
.sp-right-arrow: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 !important;
  box-shadow: 0 0 0 2px #005fcc, 0 0 0 3px #fff !important;
}


/* ------------------------------------------------------------
   WCAG 2.4.11 Focus Not Obscured
   Base: #mobile-nav-header { position:fixed; top:0; height:50px }
   on mobile. Desktop uses a fixed LEFT sidebar (no vertical
   obscuring). 60px scroll padding (50 + 10 buffer).
   ------------------------------------------------------------ */
html {
  scroll-padding-top: 60px;
}

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


/* ------------------------------------------------------------
   WCAG 1.4.11 Non-text Contrast (UI components)
   Base failures:
     .sp-left-arrow, .sp-right-arrow { border-color:#a9a9a9 !important }
     ... { border:solid 1px #a9a9a9 } (line 2086)
   #a9a9a9 on white ≈ 2.83:1 — fails 3:1 minimum.
   ------------------------------------------------------------ */
.sp-left-arrow,
.sp-right-arrow {
  border-color: #595959 !important;
}

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


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

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

/** ------------------------------------------------------------
   WCAG 2.2 AA 2.5.8 Target Size (Pointer)
   ------------------------------------------------------------ */
   /* Pre-dates 2982346 and is a non-fix for 2.5.8: line-height sizes the line box, not the
   anchor's hit area, and this targets the wrapping <div> rather than the <a>. Left in
   place to avoid an unrelated layout change; the anchor rules below are the real fix. */
.footer-widget footer.footer-10 .tableau-footer-mobile .footerRight #copyDateLinks-mobile {
    line-height: 24px;
}

/* TFS 2982346 - WCAG 2.5.8: nav social icons.
   Silktide flags these (google-search, twitter, flickr, pinterest) in
   #p_lt_zoneNav_rpWebpartSocialMedia_pnlSocialNetworks.social_media inside
   #nav-wrapper. Measured 25.1x19, display:inline - width passes, height fails
   the 24px size clause. .social_media also covers the mobile off-canvas set
   (39.1x24.5, already passing), so one rule is safe for both. */
.social_media .social-list li a {
    display: inline-block;
    min-height: 24px;
}

/* TFS 2982346 - WCAG 2.5.8: visible footer text links.
   Flagged: Sitemap (48.5x14px, tableau011326) and Residents (tableau01312023) -
   height fails the 24px size clause; width already clears it.

   Scoped to .tableau-footer / .tableau-footer-mobile rather than to a footer
   variant: Tableau renders footer-9 on some sites and footer-10 on others
   (Footer.ascx:776 / :1018) and BOTH wrap this same markup, so a variant-scoped
   rule would only fix half the fleet. Those two classes appear in no other footer
   block, so this stays correctly bounded.

   NOT `li a` - verified live on tableau011326 (footer-9) and tableau01312023
   (footer-10): the anchors' parents are <span class="residents">,
   <div id="copyDateLinks" class="sitemap"> and <div class="additional-footer-link">.
   There is no <li> in this footer, so an `li a` selector matches nothing. This is
   why the Ascension rule (.footer-links li a) could not simply be ported across.

   Both .tableau-footer and .tableau-footer-mobile carry a duplicate set - the mobile
   copies are why the site shows ~6 undersized links rather than 3.

   .privacy and .additional-footer-link are config-gated (Footer.ascx:802, :813) and
   did not render on either site measured; included so sites that do configure them
   are covered without a third pass.

   The icon links #link-hud / #link-ada / #link-rp are each an <a> wrapping an inline
   SVG (measured 31x14, display:inline) and ARE flagged - confirmed present on both
   tableau01312023 and tableau011326. An earlier revision of this rule excluded them
   on the basis that Silktide did not flag them; that was wrong. They carry ids rather
   than a shared class, so they need their own selectors. Note the ids are duplicated
   across the desktop and mobile footer blocks (a separate 4.1.1 concern, see #2985964)
   - CSS matches every occurrence regardless, so both copies are covered.

   The PMC logo is also a link where configured: Footer.ascx.cs:629 emits
   <div class="footer-logo footer-pmclogo"><a href="{link}"><img><span class="sr-only">
   inside div.pmc-logo. Measured 26.7x14. The anchor is emitted UNCONDITIONALLY -
   PMCLogo (Footer.ascx.cs:609-631) has no guard around it - so .pmc-logo a ships
   fleet-wide. An earlier revision of this comment said it "renders anchor-less on some
   sites"; that was an artefact of measuring against stale SAT builds, not the current
   code. NOTE: href is emitted from a value that can be empty, producing href="" -
   a separate defect, not addressed by this rule.

   padding 5px 0 rather than min-height alone: min-height:24px lands Residents, Sitemap
   and HUD at EXACTLY 24.0px, and the scanner rejects sitting on the line even though
   2.5.8's spacing clause only applies to targets UNDER 24x24. Same behaviour confirmed on
   Ascension the same day - .CMSSiteMapLink at 32px passes, footer links at 24.0 do not.
   Vertical-only keeps widths untouched (all six already measure 26.7-140px), so there is
   no wrap risk in the footer columns.
   Desktop and mobile are split below - only the desktop block is a single row. */

/* Desktop footer - single horizontal row, so the negative-margin cancel is safe:
   the 34px hit box on a 24px footprint has nothing above or below to overlap.
   margin-top/-bottom longhands, not the `margin: -5px 0` shorthand - the shorthand
   also zeroes horizontal margins and overrode base #link-rp { margin: .2rem 0 },
   contradicting "vertical-only keeps widths untouched". */
.footer-widget footer .tableau-footer .residents a,
.footer-widget footer .tableau-footer #copyDateLinks a,
.footer-widget footer .tableau-footer .footerRightLinks .privacy a,
.footer-widget footer .tableau-footer .additional-footer-link a,
.footer-widget footer .tableau-footer .pmc-logo a,
.footer-widget footer .tableau-footer #link-hud,
.footer-widget footer .tableau-footer #link-ada,
.footer-widget footer .tableau-footer #link-rp {
    display: inline-block;
    min-height: 24px;
    padding: 5px 0;
    margin-top: -5px;
    margin-bottom: -5px;
}

/* Mobile footer - NOT a single row. Measured at 375px with .tableau-footer
   display:none: .tableau-footer-mobile is visible 361x141 with 4 links on 4 separate
   rows (Residents 624.3, Sitemap 676.3, link-rp 709.3, PMC 729.3). With the cancel,
   34px hit boxes on 24px footprints produced 3 overlapping pairs - Sitemap/link-rp 5px,
   link-ada/link-rp 24px, link-rp/PMC 10px - and link-rp paints later so it wins the tap.
   Omitting the cancel drops that to 1 and grows the block 141 -> 187px.
   min-width also needed: #link-hud and #link-ada measure 20px WIDE (20x24), so
   min-height alone leaves them failing on the other dimension. */
.footer-widget footer .tableau-footer-mobile .residents a,
.footer-widget footer .tableau-footer-mobile #copyDateLinks-mobile a,
.footer-widget footer .tableau-footer-mobile .footerRightLinks .privacy a,
.footer-widget footer .tableau-footer-mobile .additional-footer-link a,
.footer-widget footer .tableau-footer-mobile .pmc-logo a,
.footer-widget footer .tableau-footer-mobile #link-hud-mobile,
.footer-widget footer .tableau-footer-mobile #link-ada-mobile,
.footer-widget footer .tableau-footer-mobile #link-rp-mobile {
    display: inline-block;
    min-width: 24px;
    min-height: 24px;
    padding: 5px 0;
}

/* KNOWN REMAINING FAILURE, not fixed here - see the follow-up on TFS 2982346.
   On mobile, #link-ada still overlaps #link-rp by 24px because footer.css:1549 (footer-9)
   and :2202 (footer-10) put transform: translate(25px, -9px) on
   .tableau-footer-mobile #ADA-HUD-Links, dragging the icons into the logo's row
   regardless of margins. Undoing that is a layout change to deliberate base CSS, not a
   target-size tweak. Note this mobile block was never compliant - 4 links at 14px
   before any of this work. */

/* TFS 2982346 - keep the footer icons at their original size.
   These SVGs have no intrinsic height, so they stretch to fill the enlarged anchor -
   measured after the rule above, the ADA chair grew 20px -> 28.5px (+42%) and HUD
   20px -> 23.9px. Pinning them back to 20px leaves the anchor measuring >=24px (the
   padding supplies the rest), so the target still passes while the icons look
   unchanged. */
.footer-widget footer .tableau-footer #link-hud svg,
.footer-widget footer .tableau-footer #link-ada svg,
.footer-widget footer .tableau-footer #link-rp svg,
.footer-widget footer .tableau-footer-mobile #link-hud-mobile svg,
.footer-widget footer .tableau-footer-mobile #link-ada-mobile svg,
.footer-widget footer .tableau-footer-mobile #link-rp-mobile svg {
    height: 20px;
}

/* TFS 2982346 - social icons inside the expandable footer panel.
   Footer.ascx:1109 renders .footer-follow > ul.footer-social inside
   <div class="footer-content" style="display:none"> (Footer.ascx:1102), revealed only by
   $('.footer-content').toggle(). A static scan never reaches these, so this rule is NOT
   what clears the flagged items - it is genuine 2.5.8 work for users once the footer is
   expanded. footer.css:2356-2362 sets font-size:24px on the anchor and FA's .fa carries
   line-height:1, so height already clears 24px; width is the only deficiency.
   margin-bottom:0 neutralises footer.css:3059-3061 (.footer-social li a
   { margin-bottom: 1rem }), inert while the anchor is inline but would otherwise add
   ~16px under the social row once it becomes inline-block. */
.footer-widget footer.footer-10 .footer-container .footer-top .footer-top-column .footer-follow .footer-social li a {
    display: inline-block;
    min-width: 24px;
    text-align: center;
    margin-bottom: 0;
}

/* WCAG 2.4.7 — Silktide only counts outline width, not box-shadow.
   Pin an explicit outline on the in-house buttons it flagged. */
body button.open-footer-button:focus-visible,
body button[data-toggle="offCanvasMenu"]:focus-visible,
body button.fpsm-button:focus-visible,
body button[onclick*="f_hideAmenitiesModal"]:focus-visible,
body button.nested-gst:focus-visible,
body select.top-dropdown:focus-visible {
  outline: 2px solid #005fcc !important;
  outline-offset: 2px !important;
}
/* ------------------------------------------------------------
   TFS 2905632 - WCAG 1.4.1 Use of Color (selected state)
   The Floor Plans bed/bath filter and view-switch tabs mark the
   selected item with a brand-color background + #fff text only
   (base rule sets border-color:transparent, no weight/underline).
   Add an underline so the selection is perceivable in greyscale
   and for color-blind users. `body #form` prefix keeps specificity
   above the rpWebpartCss_Floorplan* base bundles. No color changed.
   ------------------------------------------------------------ */
body #form .fp2-bed-bath ul li.active > a,
body #form .FloorPlansV2 .fp-switch-tabs .btn-default.active,
body #form .FloorPlansV3 .fp-switch-tabs .btn-default.active {
  text-decoration: underline;
  text-underline-offset: 3px;
}

/* ------------------------------------------------------------
   TFS 2905631 - WCAG 1.4.11 Non-text Contrast (form controls)
   The full-width Neighborhood search input has no perceivable
   resting border: base CSS (rpWebpartCss_NeighborhoodFullWidth.css)
   sets `border:none; background:none; color:#fff` on a dark
   rgba(0,0,0,.83) search overlay. Add a light 1px boundary at
   #cfcfcf (~9.6:1 on that dark surface; matches the widget's
   existing placeholder color). All 21 priority templates use this
   dark default - none override it to a light surface.
   ------------------------------------------------------------ */
body #form .neighborhood-widget .neighborhood-widget__search .form-group .form-control {
  border: 1px solid #cfcfcf;
}

/* WCAG 2.2 AA 2.5.8 Target Size (Pointer) — real fix (native checkbox can't be padded;
   appearance:none + explicit 24px sizing; :checked::after re-draws the check so consent UX is preserved) */
body .contact-mobile-form input[type="checkbox"],
#contactusPrivacy input[type="checkbox"],
#privacyDiv input[type="checkbox"],
#contactUsV1Privacy input[type="checkbox"] {
    -webkit-appearance: none;
    appearance: none;
    width: 24px; height: 24px;
    min-width: 24px; min-height: 24px;
    margin: 4px; padding: 0;
    border: 2px solid currentColor; border-radius: 3px;
    background: #fff; cursor: pointer; position: relative;
    vertical-align: middle; flex: 0 0 auto;
}
body .contact-mobile-form input[type="checkbox"]:checked::after,
#contactusPrivacy input[type="checkbox"]:checked::after,
#privacyDiv input[type="checkbox"]:checked::after,
#contactUsV1Privacy input[type="checkbox"]:checked::after {
    content: ""; position: absolute; left: 7px; top: 3px;
    width: 6px; height: 11px;
    border: solid #1a1a1a; border-width: 0 2px 2px 0;
    transform: rotate(45deg);
}
body .contact-mobile-form input[type="checkbox"]:focus-visible,
#contactusPrivacy input[type="checkbox"]:focus-visible,
#privacyDiv input[type="checkbox"]:focus-visible,
#contactUsV1Privacy input[type="checkbox"]:focus-visible {
    outline: 2px solid; outline-offset: 2px;
}

/* TFS 2987209 — WCAG 2.2 AAA 2.5.5 Target Size (Enhanced): expand the consent
   checkbox's pointer hit-area to 44×44 without changing anything visually
   (Option B, plan §4.4/§0.5 J — live-prototyped pixel-identical to today).
   The painted box stays 24×24 (position:relative already set above); this
   adds a transparent ::before centred over the box that only widens the
   clickable/tappable region. Do not touch :checked::after or :focus-visible
   above, and do not remove min-width/min-height:24px on the box rule above —
   on ContactUsFloating templates that min-width is the only reason the box
   is 24px wide at all (rpWebpartCss_ContactUsFloating.css sets width:auto
   !important, §0.4 D). Uses symmetric inset offsets, not
   left/top:50%+transform: live click-testing found percentage-based
   centering lands ~1-2px off-centre (asymmetric vs. the border-box),
   which stole clicks from an adjacent control (Submit button /
   privacy-policy link) on 3 of 16 templates — insets centre reliably
   regardless of border width. */
body .contact-mobile-form input[type="checkbox"]::before,
#contactusPrivacy input[type="checkbox"]::before,
#privacyDiv input[type="checkbox"]::before,
#contactUsV1Privacy input[type="checkbox"]::before {
    content: "";
    position: absolute;
    top: -12px; left: -12px; right: -12px; bottom: -12px;
}