/* ============================================================
wcag-s0084-ascension.css
WCAG 2.1 Level AA override for the S0084-Ascension Kentico template
(TemplateId 1398).
Selectors verified against the live base CSS pulled from
https://livesommery.com on 2026-05-12
(CMSPages/GetResource.ashx?stylesheetname=RPcssMaster_S0084-Ascension).
This template does NOT use a .template-* wrapper. Overrides
target the same selectors the base uses (often with `body`
prefixes in the base, which we drop here â source order wins
at equal specificity).
============================================================ */
/* ------------------------------------------------------------
WCAG 2.4.7 Focus Visible
The Ascension master CSS has no outline:none rules, but
Bootstrap suppresses outlines on .navbar-toggle / .dropdown-
toggle / .btn / .form-control. Restore visible focus rings.
------------------------------------------------------------ */
.navbar-toggle:focus-visible,
.dropdown-toggle:focus-visible,
.btn:focus-visible,
.form-control:focus-visible,
.header-widget header a:focus-visible,
.header-widget .header-button.menu-toggle:focus-visible,
.menu-drawer .menu-nav ul li a:focus-visible,
.contactus-float-input-div input:focus-visible,
.contactus-float-input-div select:focus-visible,
.contactus-float-input-div textarea:focus-visible,
#homeContactSection input:focus-visible,
#homeContactSection select:focus-visible,
#homeContactSection textarea: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: #specialsContainer { position:fixed; top:0; width:100% }
â promo banner overlaying the top of the page when specials
are active. The Bootstrap-driven header can also occupy the
top area. 100px scroll padding covers typical specials
banner + header height.
------------------------------------------------------------ */
html {
scroll-padding-top: 100px;
}
:focus-visible {
scroll-margin-top: 100px;
}
/* ------------------------------------------------------------
WCAG 1.4.11 Non-text Contrast (form controls)
Two distinct contact form patterns on this template:
1. /Contact.aspx dedicated form:
#contactUsEnhancedContainer .form-control failure comes
from shared webpart CSS (per the Haute pattern).
Specificity: body + ID matches widget's (1,1,1); !important
handles the base's `border-bottom:none` (no color to override).
2. Home page / floating mini contact form (#homeContactSection):
Base rule:
body .contactus-float-input-div select,
body .contact-mobile-form .contactus-float-input-div input
{ border-bottom: 1.5px solid #a3a3a3 }
#a3a3a3 on white page bg ≈ 2.5:1 — fails 3:1. Same pattern
as GS-Elan's mobile contact form. Specificity matches base;
source order wins from location 2 (ExternalResources_Header).
------------------------------------------------------------ */
body #contactUsEnhancedContainer .form-control {
border-bottom: 1px solid #595959 !important;
}
body .contact-mobile-form .contactus-float-input-div input,
body .contact-mobile-form .contactus-float-input-div select,
body .contact-mobile-form .contactus-float-input-div textarea,
body .contactus-float-input-div input,
body .contactus-float-input-div select,
body .contactus-float-input-div textarea {
border-bottom-color: #595959;
}
/* ------------------------------------------------------------
WCAG 1.4.3 Contrast Minimum (text)
Real failures in the base:
#7e7e7e on white â 4.4:1 â fails 4.5:1. Used across nav,
menu drawer, header button, floorplan specs, and form
placeholders. Override those specific selectors to #595959.
.footer-widget footer .footer-disclosure { opacity:.6 }
from shared footer.min.css â bump to 0.85.
------------------------------------------------------------ */
/* SCOPE NOTE: the previous selector list also covered .header-widget,
.menu-drawer, .contactus-float-input-div select, and .FloorPlansV2/V3
.specification. Those have `color: #be9142` (gold) on livesommery.com
but use entirely different brand palettes on other Greystar Ascension
properties. Forcing `#595959` would make text practically invisible
on dark-branded properties (e.g., livelexctrcity.com white-on-dark
header). Brand-color contrast failures must be fixed at the property
level, not in shared template injection. See per-property-base-css
memory. Only #homeContactSection placeholders kept here — the input
background (`#ededed`) is non-brand neutral across properties. */
body #homeContactSection input::placeholder,
body #homeContactSection textarea::placeholder,
body #homeContactSection select::placeholder {
color: #595959;
}
body .footer-widget footer .footer-disclosure {
opacity: 0.85;
}
/* ------------------------------------------------------------
WCAG 1.4.1 Use of Color (inline links)
Underline inline content links so they are distinguishable
without color. Header / nav / footer / CTA / button-styled
links opt out â distinguishable by container or shape.
Brand link color preserved.
------------------------------------------------------------ */
/* 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,
#contact-main-wrapper a,
a[href$="Privacy-policy.aspx"] {
text-decoration: underline;
text-underline-offset: 2px;
}
a.btn,
a.button,
.btn,
.btn-primary,
.header-widget header a,
.header-widget nav a,
.menu-drawer a,
.cta-header-btn,
.header-CTA-button,
.footer-CTA-Button,
a.more-link,
a.less-link,
.header-button.menu-toggle,
.footer-widget footer a {
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 #link-rp {
margin-bottom: 15px;
}
/* TFS 2955118 — Site-map .CMSSiteMapLink renders inline (~20px, ~3px apart);
inline-block + min-height + padding makes each a >=24x24 target. */
.CMSSiteMapLink {
display: inline-block;
min-height: 24px;
padding: 4px 6px;
}
/* TFS 2955118 - WCAG 2.5.8 Target Size: footer Privacy/Sitemap links.
Ascension renders footer-1 (NOT footer-10 - the footer chain differs per template, so
each must be verified separately).
Measured on ascension052125.sat-ws.realpage.com/Site-map.aspx: Privacy 45.6x13.5px,
Sitemap 46.4x13.5px, li computed display:inline with margin 0 0 0 5px.
footer.css:2902-2904 sets .footer-widget footer ul li { display: inline } at top level
with no media query, and footer-1 never overrides display, so the row is horizontal at
every viewport - centre-to-centre is ~54px, which already satisfies the spacing
exemption. The failure is the SIZE clause: 13.5px height against the 24px minimum.
The line-height:24px above does not help - on an inline box line-height sizes the line
box, not the anchor's own hit area.
No horizontal padding on purpose: the row sits in .footer-links { width: 200px } and
padding would push it to ~123px (~197px with the config-gated third link, risking a
wrap) and inset the text from the right edge of that text-align:right column.
VERTICAL padding added after QA: min-height:24px alone lands the anchors at exactly
24.0px (measured Privacy 73x24.0, Sitemap 74.3x24.0) and the scanner still flags them
"too close to another interactive part". Strictly they should pass - 2.5.8's spacing
clause only applies to targets UNDER 24x24 - but the scanner will not accept sitting
exactly on the line. The .CMSSiteMapLink rule above is the control: same template,
same check, padding 4px 6px -> 32px -> passes, so vertical padding is required here
too, keeping horizontal at zero so the 200px-column constraint above still holds.
Also covers the footer nav: nav.footer-nav > ul#footerNav1 (a CMSListMenu) holds 9
inline anchors at 18px with the identical defect. The line-height:24px rule near the
top of this section already targets .footer-nav>ul>li a, but line-height sizes the
line box, not the anchor's hit area, so it never fixed those; this rule is the real
one. Do not delete either as redundant - they do different things.
padding 5px 0 grows the hit area, which is what 2.5.8 measures. Horizontal padding
stays at zero for the 200px-column reason above.
The two selectors are deliberately NOT merged - they differ on margin, see below. */
.footer-widget footer.footer-1 .footer-links li a {
display: inline-block;
min-height: 24px;
/* Negative margin cancels the padding's layout effect so the row does not shift.
Safe here: Privacy and Sitemap sit side by side in ONE row, so the 34px hit box
on a 24px footprint has nothing above or below to collide with. */
padding: 5px 0;
margin: -5px 0;
}
/* TFS 2955118 - footer nav. Same defect and same padding as .footer-links above, but
NO negative margin, deliberately.
ul#footerNav1 holds 9 anchors (Home..Specials) which WRAP ONTO TWO ROWS. With
margin:-5px 0 each anchor's 34px hit box sits on a 24px footprint, so it extends 5px
beyond its own box in both directions - adjacent rows are ~24px apart, giving hit
boxes [0,34] and [24,58] that overlap by ~10px. In an overlap the later-painted
anchor wins, so a click in the bottom ~5px of a row-1 link can fire the link below
it, and overlapping targets are themselves a 2.5.8 concern. Omitting the cancel
grows the footer ~32px across the two rows (292 -> ~324px), which is the right trade
against shipping overlapping targets. */
.footer-widget footer.footer-1 .footer-nav ul li a {
display: inline-block;
min-height: 24px;
padding: 5px 0;
}
/* TFS 2955118 - PMC logo link. Where configured, Footer.ascx.cs:629 wraps the logo
image in an anchor; the image is ~139px but the anchor computes to an 18px inline
box, so the clickable area is far smaller than the logo it appears to be. inline-block
alone aligns the two - no min-height or padding needed, since the image already
exceeds 24px once the anchor takes its real height.
Ascension nests this as div.footer-logo.footer-pmclogo (no div.pmc-logo wrapper -
that is the Tableau shape), and it renders anchor-less on some sites (including
ascension052125, measured here), so this matches only where the anchor exists.
VISUAL CHECK: the anchor takes its real image height in flow - confirm the footer
logo row does not shift. */
.footer-widget footer.footer-1 .footer-pmclogo a {
display: inline-block;
}
/* ------------------------------------------------------------
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 Ascension. 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, since superseded by a THIRD correction below): a
prior pass here claimed the flat -14px inset overlapped the
privacy-policy link's top ~4.5-6.5px across ~37-40px of its width,
and copied Bliss's asymmetric-inset fix to resolve it. That claim
does not survive rigorous re-checking.
CORRECTED A THIRD TIME 2026-08-20 (real elementFromPoint hit-testing
plus ~3,000 real mouse.click() calls across every line box of the
consent anchor and the link, at every inset value including the one
actually deployed today, at 20 desktop widths + 6 mobile widths):
ZERO clicks were ever stolen, at ANY inset tested. The prior "4.5px
/ 6.5px" figures were real vertical-gap measurements, but the link
sits ~75-100px away HORIZONTALLY at every width checked -- the boxes
never intersect, so a same-axis vertical-proximity check read as an
overlap when the actual 2-D geometry never overlapped at all. There
was never a live defect on this template to fix. (Aurora hit a
genuine version of this same claim pattern -- confirmed real via the
same real-click methodology, off by exactly 1px, corrected separately
in wcag-s0071-aurora.css -- so this is not a blanket dismissal of the
technique, just of THIS template's instance of it.)
The asymmetric inset below is kept rather than reverted to a flat
value: it is harmless (confirmed 48x48 on both axes, zero click
theft on any side, at every width tested, matching the deployed
flat -12px's safety with more cushion), and reverting it would only
trade one CSS value for another with no functional difference. What
needed fixing was the false justification above, not the rule. */
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; left: -14px; right: -14px; bottom: -8px;
}
/* ------------------------------------------------------------
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