/* ============================================================
   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;
}

/* ------------------------------------------------------------
   TFS 2987209 — WCAG 2.2 AAA 2.5.5 Target Size (Enhanced), 44x44
   S0065-Tableau 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[11], 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 6.59px (desktop) / 11.36px (drawer) 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.
   ------------------------------------------------------------ */

/* Tableau has NO author CSS on its nav anchors at all — the only
   matched rules are Foundation's {*} and {a}. All geometry is
   inherited line-height, so these rules ADD sizing rather than
   override anything.

   Two mutually exclusive nav instances:
   - off-canvas drawer (375/768 only), links 24px tall
   - desktop vertical nav (1440 only), links 19px tall
   Narrowest desktop label "HOME" measures 47.59px — only 3.59px
   over the limit — so min-width is included as a guard; it is a
   no-op on every other label.

   *** QA / DESIGN NOTE — read before signing this off ***
   The desktop nav is a VERTICAL list of 11 links at 19px each with
   only 6.59px of separation. Bringing each to 44px necessarily
   grows that column by roughly 275px. This is the single largest
   visual change in this ticket and it is inherent to SC 2.5.5 on a
   vertical nav, not an artefact of the technique chosen — there is
   no way to give 11 stacked links a 44px target without the stack
   getting taller. Flagged explicitly rather than buried. */
body #form #offCanvasMenu #menuElem li a,
body #form .desktopMenu #menuElem li a {
    box-sizing: border-box;
    display: inline-block;
    min-width: 44px;
    min-height: 44px;
}

/* Phone — four instances. Two need both axes: the
   #mobile-nav-header one is 23.58x0 (font-size:0, glyph lives in
   ::before), and the others measure 98.55-123.17 x 15-19 and need
   height only, for which min-width is a no-op. The footer instance
   is 0x0 on load because an ancestor .footer-content is
   display:none until "Open" is clicked — it is NOT dead, and it
   measures 123.17x19 once expanded. ::before is left untouched
   where it holds the icon glyph. */
body #form a.seo-number {
    box-sizing: border-box;
    display: inline-block;
    min-width: 44px;
    min-height: 44px;
}

/* "Apply Online" — 134.06x23 at 1440, height only (0x0 at 375/768
   inside the hidden #nav-wrapper, where the rule is a no-op). */
body #form .applyNowLink a {
    box-sizing: border-box;
    min-height: 44px;
}