/* ============================================================
   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. */