/* ============================================================ wcag-c0072-gs-avana.css WCAG 2.1 Level AA override for the C0072-GS-Avana Kentico template (TemplateId 1397, DefaultCssFileName: RPcssMaster_C0072-GS-Avana). 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. Header is confirmed sticky: header.header { position:fixed; top:0; z-index:90 } ============================================================ */ /* ------------------------------------------------------------ WCAG 2.4.7 Focus Visible ------------------------------------------------------------ */ .navbar-toggle:focus-visible, .dropdown-toggle:focus-visible, .btn:focus-visible, .form-control:focus-visible, header.header a:focus-visible, #masterHeader 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; } /* ------------------------------------------------------------ WCAG 1.4.3 Contrast Minimum (text) Base failures: #7e7e7e in 8+ rules ≈ 4.4:1 — fails 4.5:1. One rule uses color:#7e7e7e !important (line 383) — override uses !important to win for that selector class. Shared footer-disclosure opacity 0.6 → 0.85. ------------------------------------------------------------ */ .FloorPlansV3 .specification, .FloorPlansV2 .specification { color: #595959 !important; } .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.header a, #masterHeader 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) Defensive — Avana's homepage uses `.homepage__about-container > .homepage__about-content` for the welcome blurb. The DOM exposes `.homepage__about-content--link` as a link helper class. Audited home page (districtparkwest.com) had no inline prose anchors in the about block today, but the wrapper structure means a content-editor-added link would inherit only color. Underline the wrapper to cover that case. The about-buttons row (`.homepage__about-buttons` / `.homepage__about-button`) is the CTA strip — opted out. ------------------------------------------------------------ */ .homepage__about-container a, .homepage__about-content a, .homepage__about-content--link { text-decoration: underline; text-underline-offset: 2px; } .homepage__about-button, .homepage__about-buttons a, .homepage__about-content a.btn, .homepage__about-content 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 2987209 — WCAG 2.2 AAA 2.5.5 Target Size (Enhanced) Mobile-nav hamburger. Live-measured: `#menuButton` is 46×32 at every viewport from 375 to 1200 (no breakpoint) — width already passes, height fails by 12px. The button has 3 absolutely- positioned `div.hamburger-bar` children (top:0 / top:50%+ translateY(-50%) / bottom:0, full button width) — growing the button's own box would visibly spread the bars apart (confirmed as the real risk on this construction; see Elan below for the same pattern). Uses the same transparent ::before hit-area overlay technique as the consent-checkbox fix elsewhere in this file family (button is already `position:relative`, so the overlay anchors correctly). Live-verified: button's own painted box + all 3 bars are pixel-identical before/after at 375px and 768px, and the resulting 46×48 hit area clears 44×44 with no neighboring-control encroachment (only object within reach is an already-unclickable cloaked decoy anchor, opacity:0.01/z-index:-999, not user-facing). Width unchanged (already passes) — only the vertical dimension needs growth, so left/right are 0. ------------------------------------------------------------ */ body button#menuButton[data-toggle="collapse"][data-target="#navMenu"]::before { content: ""; position: absolute; top: -8px; left: 0; right: 0; bottom: -8px; } /* ------------------------------------------------------------ TFS 2982346 - WCAG 2.2 AA 2.5.8 Target Size (Pointer): footer links Live-measured on avana0728.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 16, display:inline, wraps an footer .footer-phone-content a.footer-phone 126.3 x 19, 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. ------------------------------------------------------------ */ footer .footer-property-logo a { display: inline-block; min-height: 24px; } footer .footer-phone-content a.footer-phone { display: inline-block; min-height: 24px; }