/* ============================================================ wcag-s0071-aurora.css WCAG 2.1 Level AA override for the S0071-Aurora Kentico template (TemplateId 1372, DefaultCssFileName: RPcssMaster_S0071-Aurora). 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-contents { position:fixed; top:0 } .top-spacer { height:185px } ← actual reserved space ============================================================ */ /* ------------------------------------------------------------ WCAG 2.4.7 Focus Visible No outline:none in Aurora's master CSS, but Bootstrap suppresses outlines on .navbar-toggle / .dropdown-toggle / .btn. ------------------------------------------------------------ */ .navbar-toggle:focus-visible, .dropdown-toggle:focus-visible, .btn:focus-visible, .cta-button:focus-visible, a.home-cta-button:focus-visible, .form-control:focus-visible, .header-contents a:focus-visible, .header-main a:focus-visible, .main-menu-container 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.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. */ .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 Base: .header-contents { position:fixed; top:0 } with .top-spacer { height:185px }. 200px scroll padding covers the reserved space plus a small buffer. ------------------------------------------------------------ */ html { scroll-padding-top: 200px; } :focus-visible { scroll-margin-top: 200px; } /* ------------------------------------------------------------ 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: 1. body a, body a:hover { color:#7e7e7e } ≈ 4.4:1 — fails 4.5:1 by a hair. NB: this is a GLOBAL link color rule. Scoping the override to content zones avoids clobbering any per-property branded link color in nav/CTA/footer. 2. .cta-button, a.home-cta-button, .header-main a em/i, and floorplan specs use the same #7e7e7e on white. Bump only the content-area inheritors here; CTA/header retain whatever brand color the property sets. 3. Shared footer-disclosure opacity 0.6 → 0.85. ------------------------------------------------------------ */ /* SCOPE NOTE: dropped `p a`, `li a`, `dd a` from both the 1.4.3 color rule and the 1.4.1 underline rule because bare element selectors bleed into nav/footer/sidebar — Manila's intent was to scope to content zones (per the comment above) but the bare selectors defeat that. Verified against Aurora base CSS: header #menuElem li a → #29292e (would be downgraded) .tabs-panel ul li a → #29292e #leftPanelTabs .tabList li a:hover/active → #fff (on dark bg) → INVISIBLE if forced to #595959 .social_media .footer-social li a → #008080 (brand teal) Also dropped `.FloorPlansV3 .specification` / `.FloorPlansV2 .specification` — same per-property brand color pattern as Grids' .FloorPlansV3 a (4 different colors across 4 properties). See per-property-base-css memory. Brand-color contrast failures must be fixed at the property-CSS level. */ .main-content-text a, .inner-page-main a, .main-content-wrapper a { color: #595959; } .footer-widget footer .footer-disclosure { opacity: 0.85; } /* ------------------------------------------------------------ WCAG 1.4.1 Use of Color (inline links) Scope matches the 1.4.3 rule above — content containers only, no bare `p a` / `li a` / `dd a`. ------------------------------------------------------------ */ .main-content-text a, .inner-page-main a, .main-content-wrapper a { text-decoration: underline; text-underline-offset: 2px; } a.btn, a.button, a.cta-button, a.home-cta-button, .btn, .btn-primary, .header-contents a, .header-main a, .main-menu-container 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 — Aurora's homepage stacks six numbered section wrappers (`.home-section1` through `.home-section6`) plus `.home-banner-text` and `.home-section-overlay`. 1600boulder.com showed no inline prose anchors in those today (CTAs use `.home-cta-button` / `.cta-button` — already opted out above), but the wrappers exist and would need underline coverage if a property's content editor adds an inline link inside the section copy. ------------------------------------------------------------ */ .home-section1 a, .home-section2 a, .home-section3 a, .home-section4 a, .home-section5 a, .home-section6 a, .home-banner-text a, .home-section-overlay a { text-decoration: underline; text-underline-offset: 2px; } .home-section1 a.btn, .home-section1 a.button, .home-section2 a.btn, .home-section2 a.button, .home-section3 a.btn, .home-section3 a.button, .home-section4 a.btn, .home-section4 a.button, .home-section5 a.btn, .home-section5 a.button, .home-section6 a.btn, .home-section6 a.button, .home-cta-button, .home-cta-group a, .home-cta-text a, a.home-cta2 { text-decoration: none; } /* ------------------------------------------------------------ WCAG 2.2 AA 2.5.8 Target Size (Pointer) ------------------------------------------------------------ */ .footer-info-menu li a { line-height: 24px; } /* ------------------------------------------------------------ WCAG 2.4.3 Focus Order (TFS 2870231) Aurora's mobile nav `.main-menu-container` is hidden via `left: -100%` + `opacity: 0` when closed, and slides to `left: 0; opacity: 1` when JS adds `.in`. Offset/opacity hiding leaves the contained nav links in the keyboard tab order and the a11y tree. Add visibility toggling alongside the existing slide animation: - closed: visibility:hidden, flip delayed 0.5s so the drawer slides out fully visible before being removed. - open: visibility:visible at t=0 so the drawer is rendered during the slide-in. ------------------------------------------------------------ */ .main-menu-container { visibility: hidden; transition: all .5s ease, visibility 0s linear .5s; } .main-menu-container.in { visibility: visible; transition: all .5s ease, visibility 0s linear 0s; } /* ------------------------------------------------------------ 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. FIX (TFS 2987209, fleet rescan 2026-08): the checkbox rule above renders box-sizing:border-box (confirmed live via computed style on all 8 templates carrying this exact block), so the CSS containing block for this ::before (the padding box) is only 24px - 2*2px border = 20x20, not 24x24. The original -12px inset was sized against the 24x24 assumption, so it actually produced a 20+2*12=44x44 overlay - exactly at the SC 2.5.5 floor with zero cushion. Bumping each inset by 2px restores a 48x48 cushion (20 + 2*14) regardless of box-sizing. CORRECTED 2026-08-20 (production completeness sweep, see docs/reports/2987209-prod-completeness-sweep-2026-08-20.md §2): this commit was originally written up as fixing a "confirmed" live misclick onto the adjacent privacy-policy link on Ascension/Aurora/Bliss. Independent production re-verification (exhaustive elementFromPoint pixel-grid sweeps, not just spot probes) found that does NOT reproduce on any of the three live — the deployed 24x24 overlay measures a clean, exact 44.0x44.0 with zero neighbor encroachment on Aurora. What's real is a ZERO-CUSHION pattern, not a misclick: any future 1px layout shift would drop the hit area below the 44px floor. This -14px bump ships as hardening against that risk, not as a regression fix. (The "elementFromPoint hit-test, 2026-08-19" / "misclick" wording above is the original, since-corrected characterization — kept in place rather than rewritten, per this repo's convention of not amending pushed commits; this comment is the correction of record.) CORRECTED AGAIN 2026-08-20 (independent live re-verification of this commit itself): the "zero neighbor encroachment" claim is also wrong at desktop width (1440) -- a real, smaller overlap exists there (the privacy-policy link wraps beneath the checkbox), and a flat -14px widens it further. At 390px there's no overlap at all (the link sits clear). Applying the same asymmetric fix used for Bliss/Ascension (top:-20/right:-14/bottom:-8/left:-14) rather than a flat bump on every side -- this checkbox has ample clearance above it and only a few px below, so all the extra reach for 48x48 comes from the top, same as everywhere else this exact geometry occurs in this ticket. CORRECTED A THIRD TIME 2026-08-20 (independent live re-verification of THIS overlap, unlike Ascension's -- confirmed genuine via 19,440 real mouse.click() calls with an overlay-off control and 2-D intersection checking, not a same-axis artifact): top:-20/bottom:-8 reduced the real overlap by ~80-90% depth but left it off by exactly 1px -- the measured clearance from the padding box's bottom edge to the link's top edge is exactly 7.00px on all three domains, and bottom:-8px overshoots that by 1px. top:-21/bottom:-7 measured ZERO stolen clicks at the identical 48x48 size, on all three domains, at every width tested (360-1440). */ 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: -21px; left: -14px; right: -14px; bottom: -7px; } /* ------------------------------------------------------------ TFS 2982346 - WCAG 2.2 AA 2.5.8 Target Size (Pointer): footer links Live-measured on aurora102623.sat-ws.realpage.com/Contact.aspx at 1280x900 (headless Chrome, border-box heights): 5 of 12 footer targets under 24px. All five are display:INLINE and 17px tall. footer ul#footer-info-menu-list li.site-map a / li.privacy a / li a.residents (the `.footer-info-menu` list the rule above already targets by line-height) footer ul#menuElem li a footer div#footerLogo1 a footer a#link-rp Aurora nests its footer BOTH ways: `.footer-widget > footer` wraps `#footer-info-menu-list`, while `ul#menuElem` sits under a plain `footer`. A single `footer` prefix covers both; `.footer-widget footer` would have covered only the first. Both id-based lists are matched explicitly because the flagged links live in `#footer-info-menu-list`, not `#menuElem`. The existing `.footer-info-menu li a { line-height: 24px }` rule above does NOT fix these - line-height has no effect on an inline element's border-box height, which is why the measurement still reads 17px with that rule live. No padding and no negative-margin cancel is needed: the #menuElem line box is already 24px (line-height: 24px from the base), so growing the box to 24px consumes existing leading and shifts nothing. Verified: 0px height change. 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 ul#menuElem li a, footer ul#footer-info-menu-list li a, footer .footer-info-menu li a, footer div#footerLogo1 a, footer a#link-rp { display: inline-block; min-height: 24px; } /* Inline SVG has no intrinsic height and would stretch to the taller box. */ footer a#link-rp svg, footer div#footerLogo1 a svg { height: 20px; } /* ------------------------------------------------------------ TFS 2987209 — WCAG 2.2 AAA 2.5.5 Target Size (Enhanced), 44x44 S0071-Aurora. Measured on LIVE PRODUCTION (481mathilda.com), not SAT: Aurora's SAT host is pinned to CDN build 2501476, which 301-redirect-loops on its assets. document.styleSheets still LISTS the override there as if loaded, so SAT geometry for this template is a phantom and was discarded. *** SCOPE — nav links are deliberately NOT touched *** #menuElem li a ALREADY PASSES at every viewport (52px tall, narrowest label 60px wide). No rule is written for it. Identical