/* ============================================================ wcag-s0086-dakota.css WCAG 2.1 Level AA override for the S0086-Dakota Kentico template. Selectors verified against the live base CSS pulled from https://elevatedaniabeach.com on 2026-05-07. Audit findings: - Base CSS (~47KB / 509 rules). No outline-suppression in template CSS itself; Bootstrap still removes outlines. - Form controls: body .form-control { border-bottom: 1px solid #fff } — white border, suggests forms sit on a dark background. Verify the form's actual background on the live page; if it's on white, this fails 3:1 and we'd need to override. - Footer text uses #fff (likely on dark bg, passes). - footer-2 social link color #064b65 on white passes (~9:1). 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.11 Focus Not Obscured Default 80px scroll-padding. Measure on the live site. ------------------------------------------------------------ */ html { scroll-padding-top: 80px; } body #form :focus-visible { scroll-margin-top: 80px; } /* ------------------------------------------------------------ WCAG 1.4.11 Non-text Contrast (form controls) Base: body .form-control { border-bottom: 1px solid #fff } Designed for dark form backgrounds. If Silktide flags forms on a white/light background, uncomment the override below or target the specific form container with a darker color. ------------------------------------------------------------ */ /* Uncomment if forms render on light bg and #fff border fails 3:1 body #form .form-control { border-bottom-color: #595959; } */ body #form input::placeholder, body #form textarea::placeholder { color: #595959; opacity: 1; } /* ------------------------------------------------------------ WCAG 1.4.3 Contrast Minimum (footer disclosure) Shared footer.min.css opacity:.6 → 0.85. ------------------------------------------------------------ */ body #form .footer-widget footer .footer-disclosure { opacity: 0.85; } /* ------------------------------------------------------------ WCAG 1.4.1 Use of Color (inline links) Defensive underline rule on common Kentico content patterns. ------------------------------------------------------------ */ body #form .main-content-text a, body #form .inner-page-main-content a, body #form .mainContent a, body #form main p a, body #form article p a, body #form .content p a, body #form #contactusPrivacy 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; } /* ------------------------------------------------------------ WCAG 2.2 AA 2.5.8 Target Size (Pointer) DEAD SELECTOR — flagged, not deleted outright, 2026-08-20 (TFS 2987209 prod completeness sweep): `body .header-widget header .header-button .header-phone` matches zero elements on live production Dakota. Left commented out rather than silently removed so the paper trail (and the #2955118/#2982346 AA target-size intent) isn't lost — those ticket owners should re-derive the correct live selector, not this AAA ticket. ------------------------------------------------------------ */ /* body .header-widget header .header-button.header-phone { width: 26px; line-height: 24px; margin-left: 24px; } */ /* ------------------------------------------------------------ TFS 2870264 — WCAG 1.4.1 (homepage inline links) Dakota's homepage uses `
` and `
`. Inside each, content is split across `.staggered`, `.imgSide`, `.staggeredTwo`, `.staggeredSix` zones, each with a `.copy` text container (and sometimes `.expandable`). CTAs use `` — opted out below. ------------------------------------------------------------ */ body #form .welcomeSection .copy a, body #form .welcomeSection .expandable a, body #form .locationSection .copy a, body #form .locationSection .expandable a { text-decoration: underline; text-underline-offset: 2px; } body #form .welcomeSection a.button, body #form .welcomeSection .copy a.button, body #form .locationSection a.button, body #form .locationSection .copy 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; } /* ------------------------------------------------------------ TFS 2982346 - WCAG 2.2 AA 2.5.8 Target Size (Pointer): footer links Live-measured on dakota01242023.sat-ws.realpage.com/Contact.aspx at 1280x900 (headless Chrome, border-box heights): 2 footer target(s) under 24x24. footer .footer-links li.footer-privacy-link a 67.5 x 20, display:inline footer .footer-links li.footer-site-map-link a 68.9 x 20, 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. DEAD SELECTOR — flagged, not deleted outright, 2026-08-20 (TFS 2987209 prod completeness sweep): `footer .footer-links li.footer-privacy-link a` / `li.footer-site-map-link a` match zero elements on live production Dakota — likely written against a stale SAT measurement. Left commented out rather than silently removed so the #2955118/#2982346 AA target-size intent isn't lost; those ticket owners should re-derive the correct live selector for this template, not this AAA ticket. ------------------------------------------------------------ */ /* footer .footer-links li.footer-privacy-link a, footer .footer-links li.footer-site-map-link a { display: inline-block; min-height: 24px; } */ /* ------------------------------------------------------------ TFS 2987209 — WCAG 2.2 AAA 2.5.5 Target Size (Enhanced): consent checkbox pointer hit-area, 44×44. S0086-Dakota 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"], input#respondmedium, input#respondmediumemail { 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, input#respondmedium::before { content: ""; position: absolute; top: -33px; left: -18px; right: -18px; bottom: -7px; } /* TFS 2987209 fleet rescan (2026-08-20, prod completeness sweep): the two #respondmedium/#respondmediumemail radio inputs share the exact same raw-UA-default 13x13 shortfall as the checkbox above (same contact form, same styling, same lack of an appearance:none box to build on) but the original fix above was scoped to input[type=checkbox] only and never reached them. #respondmedium (Phone) reuses the checkbox's insets cleanly — verified live, zero intrusion. CORRECTED 2026-08-20 (production re-verification): #respondmediumemail cannot reuse those insets. The two radios sit only 5.3px apart with the "Phone" label between them, not alone on their row like the checkbox — the checkbox's symmetric left:-18px reached 12.8px into the Phone label, letting the last few px of the rendered word "Phone" silently select Email instead (elementFromPoint-confirmed on production at 1440/768/360, both live domains). Fixed by narrowing the side facing the Phone label (left) and borrowing the difference from the side that lands only in this radio's own label (right), which was never at risk of a steal. */ input#respondmediumemail::before { content: ""; position: absolute; top: -33px; left: -5px; right: -26px; bottom: -7px; } /* ------------------------------------------------------------ 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