/* ============================================================ wcag-s0079-autumn-ridge.css WCAG 2.1 Level AA override for the S0079-Autumn-Ridge Kentico template (TemplateId 1393, DefaultCssFileName: RPcssMaster_S0079-Autumn-Ridge). 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. Ron specifically named this template in TFS 2849882 (Westborough Crossing / westboroughcrossingliving.com) as outside the current 8-template remediation scope. This file brings it in. No position:fixed in master CSS — sticky header comes from shared resources. 100px scroll padding (conservative). ============================================================ */ /* ------------------------------------------------------------ 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) Base failures: 1. Multiple `border: solid 1px #7e7e7e` rules on input-like wrappers ≈ 4.4:1 — borderline against 3:1. 2. ... { border:1px solid #f7f8f9 } (line 676) ≈ 1.04:1 — effectively invisible. 3. The #contactUsEnhancedContainer .form-control failure Ron flagged for Westborough Crossing lives in shared webpart CSS — addressed via Ron's specificity strategy below. Specificity strategy: body #contactUsEnhancedContainer .form-control matches the widget's own specificity (1,1,1) and the !important is needed because the base typically sets `border-bottom:none` (no color to override). ------------------------------------------------------------ */ body #contactUsEnhancedContainer .form-control { border-bottom: 1px solid #595959 !important; } /* ------------------------------------------------------------ WCAG 1.4.3 Contrast Minimum (text) Base failures: #7e7e7e in 10+ text-color rules ≈ 4.4:1 — fails 4.5:1. #8d8d8d (line 2275) ≈ 3.5: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) Autumn-Ridge's homepage uses `.web-home-template` as the page wrapper; rich-text editor blocks render as `.column-content .html-content` containers (with auto- generated `.html-NNNN` IDs per block). Inline prose links sit inside those. `.copy-overlap` / `.copy-overlay` hold overlay/copy variants. Verified against 13westmainstreet.com (inline links "studio and 1 bedroom", "Amenities page" inside `.html-content`). `.ws-cta--primary > .cta-wrap > .cta-item` is a CTA tile — already covered by the `a.btn`/`a.button` opt-out above. ------------------------------------------------------------ */ .web-home-template .column-content .html-content a, .web-home-template .copy-overlap a, .web-home-template .copy-overlay a { text-decoration: underline; text-underline-offset: 2px; } .web-home-template .html-content a.btn, .web-home-template .html-content a.button, .web-home-template .ws-cta--primary a, .web-home-template .cta-wrap a, .web-home-template .cta-item { text-decoration: none; } /** ------------------------------------------------------------ WCAG 2.2 AA 2.5.8 Target Size (Pointer) ------------------------------------------------------------ */ .header-widget header .header-button em { margin-left: .8rem; } /* ------------------------------------------------------------ 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). The painted box stays 24×24 (position:relative already set above); this adds a transparent ::before 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). ASYMMETRIC insets — intentional, do NOT "fix" this to be symmetric. Live click-testing (TFS 2987209) found the "privacy policy" link sits only ~5px below the checkbox on this template at every standard viewport. A symmetric 44×44 ring would swallow ~3px of the link's top edge and steal its clicks. SC 2.5.5 has no centering requirement, so the shortfall is borrowed from the top side instead, which has ~19.6px of clearance (the tightest headroom of any template in this fix — no left/right neighbor within 45px). Net: genuine 44×44 hit area, ~1px buffer on the bottom edge, zero measured click-stealing at 375, 390, 768, and 1440px. FIX (TFS 2987209, fleet rescan 2026-08): these insets were sized against a 24x24 containing-block assumption, but the checkbox is box-sizing:border-box, so the real containing block (padding box) is 20x20 (24px - 2*2px border). That silently ate 2px off every side of the design above, landing this at the true SC 2.5.5 floor rather than the intended ~1px buffer - measured as a 1-6px shortfall in the fleet rescan. Adding 2px (one border-width) to each of the four insets below restores the originally-intended margins on the correct 20x20 base (48x48 total). The top extension (20px) is measured from the padding box, i.e. ~2px inside the visible border edge, so the effective reach above the visible box is 18px - still inside the ~19.6px headroom measured against the visible edge. Do not re-symmetrize. */ 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: -20px; right: -14px; bottom: -8px; left: -14px; } /* ------------------------------------------------------------ TFS 2982346 - WCAG 2.2 AA 2.5.8 Target Size (Pointer): footer links Live-measured on a-ridge040323.sat-ws.realpage.com/Contact.aspx at 1280x900 (headless Chrome, border-box heights): 4 footer target(s) under 24x24. footer .footer-links li.footer-privacy-link a 51 x 20, display:inline footer .footer-links li.footer-site-map-link a 59.5 x 20, display:inline footer #ada-hud-links a#link-ada / a#link-hud 20 x 35 - fails on WIDTH only These are display:inline, where `line-height` cannot help - it does not change an inline element's border-box height. inline-block is what makes min-height apply. No padding and no negative-margin cancel is used: each target sits in a line box already at or above 24px, so the box grows into existing leading. Verified by injecting these rules into the live SAT page: 0 targets remaining, document height +0px, no horizontal overflow. SCOPE PREFIX: scoped on the `footer` element. On THIS template `.footer-widget footer` also matches, so either prefix would work - the bare `footer` is used for consistency across the 18 template files in this ticket, three of which genuinely need it (Zen-Garden and Au-Courant nest `footer > .footer-widget`, reversed; Jackson-Square has no `.footer-widget` element at all). `footer` is a superset of both nestings. Verified against the live SAT DOM per template - not assumed. ------------------------------------------------------------ */ footer .footer-links li.footer-privacy-link a, footer .footer-links li.footer-site-map-link a { display: inline-block; min-height: 24px; } /* ADA/HUD icons already clear 24px on HEIGHT (35px here) and fail only on WIDTH: the anchor is inline-block wrapping a 20px SVG. min-width is the whole fix - do NOT add min-height, which would stretch the row for nothing. */ footer #ada-hud-links a#link-ada, footer #ada-hud-links a#link-hud { min-width: 24px; } /* ------------------------------------------------------------ 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. 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