/* ============================================================ wcag-s0092-emerald.css WCAG 2.1 Level AA override for the S0092-Emerald Kentico template. Owner of TFS 2849882 (1.4.11 form control contrast). Selectors verified against the live base CSS pulled from https://affinityatkendrick.com on 2026-05-07. Audit findings: - Base CSS (~25KB / 313 rules). No outline-suppression in template CSS; Bootstrap still removes them. - Form: #contactUsEnhancedContainer .form-control { border-color:#000; border-width:0 0 1px 0 } Black border passes 3:1 trivially. The TFS 2849882 form- contrast failure must be on a DIFFERENT form element on the live page (Silktide flagged something specific). Refine this file at deploy time after identifying the actual failing form control. - Footer link colors look correct (#fff, #efefef on dark). Specificity strategy: Every selector is prefixed with `body #form` to lift above widget CSS load order. ============================================================ */ /* ------------------------------------------------------------ WCAG 2.4.7 Focus Visible Bootstrap suppressors plus general fallback. ------------------------------------------------------------ */ body #form .navbar-toggle:focus-visible, body #form .dropdown-toggle:focus-visible, body #form .btn:focus-visible, body #form .form-control:focus-visible, body #form a:focus-visible, body #form button:focus-visible, body #form input:focus-visible, body #form select:focus-visible, body #form textarea:focus-visible, body #form [tabindex]:focus-visible, body #form [role="button"]:focus-visible, body #form .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.13 AAA (Focus Appearance) — PME-507688 rework (Will Sharp, manual scan 2026-08-24): the shared blue+white ring above doesn't reliably clear 3:1 against every property's footer background (footers commonly run darker/branded compared to the form fields and buttons this shared rule also covers). Override just the footer link ring with a white+black double ring — one leg always clears 3:1 against any single backdrop, the same treatment already used for the Floor Plans V4 focus rings. Scoped narrowly to `.footer-widget footer a` so the inputs/selects/tabindex/role=button elements above, which were not flagged, keep their existing ring. */ body #form .footer-widget footer a:focus-visible { box-shadow: 0 0 0 2px #fff, 0 0 0 4px #000 !important; } /* ------------------------------------------------------------ WCAG 2.4.11 Focus Not Obscured Default 80px scroll-padding; verify and adjust on live site. ------------------------------------------------------------ */ html { scroll-padding-top: 80px; } body #form :focus-visible { scroll-margin-top: 80px; } /* ------------------------------------------------------------ WCAG 1.4.11 Non-text Contrast (TFS 2849882 form control) #contactUsEnhancedContainer .form-control already has border-color:#000 (passes). The flagged element is likely ELSEWHERE — possibly the contactus-floating widget, search bar inputs, or a different form. PLACEHOLDER override below covers the generic input case; refine after identifying the exact failing element via Silktide on the deployed page. ------------------------------------------------------------ */ body #form input.form-control, body #form select.form-control, body #form textarea.form-control, body #form .contactus-float-input-div input, body #form .contactus-float-input-div textarea, body #form input[type="text"], body #form input[type="email"], body #form input[type="tel"], body #form input[type="search"], body #form select, body #form textarea { border-color: #595959; } body #form input::placeholder, body #form textarea::placeholder { color: #595959; opacity: 1; } /* ------------------------------------------------------------ WCAG 1.4.3 Contrast Minimum (footer disclosure) ------------------------------------------------------------ */ body #form .footer-widget footer .footer-disclosure { opacity: 0.85; } /* ------------------------------------------------------------ WCAG 1.4.1 Use of Color (inline links) ------------------------------------------------------------ */ body #form .main-content-text a, body #form .inner-page-main-content a, body #form .inner-page-main a, body #form .mainContent a, body #form main p a, body #form article p a, body #form .content p a, body #form a[href$="Privacy-policy.aspx"] { text-decoration: underline; text-underline-offset: 2px; } body #form .btn, body #form .button, body #form header a, body #form nav a, body #form .navbar a, body #form footer a, body #form .footer-widget footer a, body #form .footer-CTA-Button, body #form .header-CTA-button, body #form a.more-link, body #form a.less-link { text-decoration: none; } /* ------------------------------------------------------------ TFS 2870264 — WCAG 1.4.1 (homepage inline links) Emerald's homepage welcome zone is `
` containing `.contentTable > .contentCell.welcomeCell.welcomeText` for the inline-text content (sibling `.welcomeImages` holds images). The `#connect` row beneath is utility info (office address, phone) — those links are wrapped CTAs, not inline prose, so opted out. ------------------------------------------------------------ */ body #form #welcome .welcomeText a, body #form .welcomeCell.welcomeText a, body #form .contentCell.welcomeText a { text-decoration: underline; text-underline-offset: 2px; } body #form #connect a, body #form .connectInfoWrapper a, body #form .connectOffice a, body #form a.seo-number { text-decoration: none; } /** ------------------------------------------------------------ WCAG 2.2 AA 2.5.8 Target Size (Pointer) ------------------------------------------------------------ */ .footer-widget footer .footer-nav>ul>li a, .footer-widget footer.footer-1 a { line-height: 24px; } .footer-widget footer .footer-content #link-rp { margin-bottom: 15px; } /* ------------------------------------------------------------ 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; } /* ------------------------------------------------------------ TFS 2982346 - WCAG 2.2 AA 2.5.8 Target Size (Pointer): footer links Live-measured on emerald10262023.sat-ws.realpage.com/Contact.aspx at 1280x900 (headless Chrome, border-box heights): 2 footer target(s) under 24x24. footer .footer-property-logo a 226.7 x 13, display:inline, wraps an footer .footer-phone-content a.footer-phone 119.4 x 16, display:inline 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. ------------------------------------------------------------ */ /* TFS 2987209 — WCAG 2.2 AAA 2.5.5 Target Size (Enhanced): supersedes the two 24px (#2982346, AA) rules immediately below in place with 44px, per plan §3.3 (44 replaces 24 on the same selector — one stanza, not two layered ones). */ footer .footer-property-logo a { display: inline-block; min-height: 44px; } footer .footer-phone-content a.footer-phone { display: inline-block; min-height: 44px; } /* ------------------------------------------------------------ TFS 2987209 — WCAG 2.2 AAA 2.5.5 Target Size (Enhanced): consent checkbox pointer hit-area, 44×44. S0092-Emerald was missing this fix entirely (fleet rescan, 2026-08) — only the #2955118/#2982346-era footer-link fix existed in this file; the consent checkbox itself was never touched here, so it ships as the raw UA-default checkbox: live-measured 13px (some widths taller, see below), box-sizing:border-box, 0 author border, position:static. Because there's no custom 24×24 box on this template (no appearance:none rule to build on), this grows the hit-area directly off the native 13×13 box instead of reusing the ::before-on-a-24×24-box pattern used elsewhere in this file family. position:relative is added here (native checkboxes are position:static) so the ::before anchors to the checkbox itself and not to some ancestor. Insets are asymmetric and were derived from a live measurement of the actual clearance to the "privacy policy" label/link on this template - not assumed - then verified with elementFromPoint across the resulting hit-area (incl. the corner nearest the link): zero intrusion, checkbox wins everywhere in the box. ------------------------------------------------------------ */ #contactusPrivacy input[type="checkbox"], #privacyDiv input[type="checkbox"], #contactUsV1Privacy input[type="checkbox"], body .contact-mobile-form input[type="checkbox"] { position: relative; } #contactusPrivacy input[type="checkbox"]::before, #privacyDiv input[type="checkbox"]::before, #contactUsV1Privacy input[type="checkbox"]::before, body .contact-mobile-form input[type="checkbox"]::before { content: ""; position: absolute; top: -31px; left: -18px; right: -18px; bottom: -9px; } /* ------------------------------------------------------------ TFS 2987209 — WCAG 2.2 AAA 2.5.5 Target Size (Enhanced): S0080-Copper-Creek/S0092-Emerald header — authored from scratch, 2026-08-20. Neither template ever received a header/footer/CTA/social stanza on this ticket (prod completeness sweep: 30 sub-44 targets on Copper-Creek, 11+ on Emerald with the worst social icons in the whole sweep). Both use the shared Header.ascx widget (Emerald: header-6 — confirmed via RPcssMaster_S0092-Emerald.css's own `header.header-6` rules), which loads NO sizing at all for `.header-nav`/`.header-phone`/ `.header-social` on this variant (header.css only ever sizes header-6's `.menu-toggle` and `.header-cta` — audited, confirmed absent) — so this is genuinely unauthored code, not a deploy gap. `.header-phone` also carries Bootstrap's `.btn` class (inline-block by default); `display:inline-block` is still stated explicitly rather than relied on implicitly, consistent with this file family's convention elsewhere. `.header-nav` links (CMSListMenu output) carry no author sizing at all, so it needs an explicit display change before min-* applies. CORRECTED 2026-08-20 (independent live re-verification of this block): `header.header-6` was inferred from stylesheet contents, not the rendered DOM — production actually renders `header.header-4` on every live Emerald site; `header-6` matches ZERO elements, so the nav and phone rules above were entirely dead code. Corrected to `header-4`. `.header-social` was also wrong on two counts: it is not a descendant of `
` at all (it lives in a sibling `.menu-drawer`), and the sweep's worst-offender numbers (11.4x27 to 17.1x41) actually come from a THIRD, separate location — the homepage's visible SocialMedia widget (`div.connectSocial ul.social-list li a`), which no selector here reached. Both are added below as their own rules, live-verified: zero overlap between adjacent icons at either location (each anchor sits in its own `
  • `, so growth pushes siblings apart rather than stacking), no new horizontal scroll at 375 or 1440. CORRECTED AGAIN 2026-08-20 (independent re-verification of the header-4 correction): both header-4 rules were confirmed correct in principle (header-4 really is what's live, both social-icon locations really do need the fix and land clean) but two regressions shipped alongside them, fixed here: (1) The phone rule's explicit `display:inline-block` outweighs header.css's `@media (max-width:425px){ .header-phone{display:none} }` (this rule has no media query, so it wins the cascade at any width) -- the desktop phone pill un-hid on phones and overlapped the logo by up to 96px. The element already carries Bootstrap's `.btn` class, which is `inline-block` on its own at >=426px where the phone is meant to show -- `min-height` alone is sufficient there and inert (harmless) while the media query keeps it `display:none` below that. Dropped the `display` declaration. (2) `.header-nav ul li a` also matched the "More" dropdown's 7 nested items, which already passed at 167x44 `display:block` -- the `display:inline-block` collapsed them to text width (as low as 65.9x44) and, because "More" itself is matched by the same rule and grows to 44px tall, shifted the dropdown panel's fixed vertical position into an overlap with "More" itself (toggle's own clickable height dropped 44->26px). Restricted to `.header-nav > ul > li > a` (direct children only) so the rule reaches the three top-bar items (Home, Floor Plans, More) without touching anything nested inside `.dropdown-menu`. STILL OPEN, not fixed here: even scoped to direct children, "More" itself still needs to grow to 44px tall for 2.5.5, and the dropdown panel's vertical offset appears hard-coded against the toggle's previous (shorter) height -- once "More" is genuinely 44px tall this same panel/toggle overlap will likely recur unless the panel's `top` is also adjusted. Not fixing blind without seeing the exact `.dropdown-menu` positioning rule live; needs its own verification pass before "More" can be called fully compliant. Also open: nav items narrower than 44px wide ("Home" measured 40.6px) -- this rule only sets min-height, not min-width, and no exemption obviously applies to a horizontal nav bar. */ body #form header.header-4 .header-nav > ul > li > a { box-sizing: border-box; display: inline-block; min-height: 44px; } body #form header.header-4 .header-phone { box-sizing: border-box; min-height: 44px; } body #form ul.header-social li a, body #form div.connectSocial ul.social-list li a { box-sizing: border-box; display: inline-flex; align-items: center; justify-content: center; min-width: 44px; min-height: 44px; } /* NOT independently live-verified this session (no browser/verification tool available) — grounded in static analysis of Header.ascx/ Header.ascx.cs/header.css only, unlike the rest of this file family which was live-measured. Flagged explicitly for a live-verification pass (elementFromPoint + getBoundingClientRect at 375/768/1440) before this specific block ships, per this ticket's own evidence standard. Also NOT covered here, for the same reason (sweep named them but gave no selector this session could confirm against live markup without a browser): Copper-Creek's footer "Directions" link, fair-housing icons, the 16x6 Submit button, and the 1x1 skip-link. Raised separately rather than guessed at. */ /* ------------------------------------------------------------ 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