/* ============================================================
wcag-s0078-bliss.css
WCAG 2.1 Level AA override for the S0078-Bliss Kentico template
(TemplateId 1408, DefaultCssFileName: RPcssMaster_S0078-Bliss).
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:
body .header-widget header.header-sticky { position:fixed }
============================================================ */
/* ------------------------------------------------------------
WCAG 2.4.7 Focus Visible
------------------------------------------------------------ */
.navbar-toggle:focus-visible,
.dropdown-toggle:focus-visible,
.btn:focus-visible,
.form-control:focus-visible,
.header-widget header a:focus-visible,
.menu-drawer 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)
Base failures:
1. .homeContactFormHolder .contact-mobile-form
.contactus-float-input-div input/select/textarea
{ border-bottom:1px solid #cfcecb } â 1.62:1 â fails 3:1.
2. #contactUsEnhancedContainer .form-control comes from
shared webpart CSS; per Ron's Haute pattern, override
with body #contactUsEnhancedContainer prefix to lift
above widget CSS load order.
The .l-title / .hero__text rules using #d5d5d5 borders are
decorative title frames â 1.4.11 excludes purely decorative
borders. Left alone.
Specificity strategy:
The base rules carry `body ...` prefixes, so we match with
`body ...` here. The #contactUsEnhancedContainer fix keeps
!important because typical widget CSS sets
`border-bottom:none` (no color value to override).
------------------------------------------------------------ */
body .homeContactFormHolder .contact-mobile-form .contactus-float-input-div input,
body .homeContactFormHolder .contact-mobile-form .contactus-float-input-div select,
body .homeContactFormHolder .contact-mobile-form .contactus-float-input-div textarea {
border-bottom-color: #595959;
}
body #contactUsEnhancedContainer .form-control {
border-bottom: 1px solid #595959 !important;
}
/* ------------------------------------------------------------
WCAG 1.4.3 Contrast Minimum (text)
Base failures:
body a, body a:hover { color:#bea67e } â 3.31:1 â fails 4.5:1.
NB: this is a GLOBAL link color. Scoped to content zones
to avoid clobbering per-property branded link colors in
nav/CTA/footer.
#7e7e7e in 5+ rules â 4.4:1 â borderline.
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 (bare element selectors
bleed into nav/header/footer). Manila's comment above states
the intent was to scope to content zones; the bare selectors
defeat that. Verified against Bliss base CSS (cpwaterfront.com
prod vs blissandro SAT) — multiple per-property brand colors
on nav li>a:
#headerNav2 li a:hover prod=#e3983b SAT=#b3a67e
header nav.header-nav li a prod=#538fab SAT=#6d6d6d
header-sticky nav li a:hover prod=#e3983b SAT=#b3a67e
header-4 nav li a #fff (would be downgraded to
gray-on-dark = invisible)
Also dropped `.FloorPlansV3 .specification` / `.FloorPlansV2
.specification` — same per-property brand pattern as Grids
(4 different colors across 4 properties) and Aurora.
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,
.btn,
.btn-primary,
.header-widget header a,
.menu-drawer 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)
The homepage welcome blurb is wrapped in
`` — already covered by the
`.main-content-text a` rule above.
The Silktide failure Russ flagged is the privacy-policy link
on the homepage contact form: `#privacyDiv > label > a`
("By submitting this form, you agree to the privacy policy.")
That link sits inside a `` for the privacy-agreement
checkbox, NOT inside `.main-content-text`, so the existing
1.4.1 rule misses it. Verified against
bliss.ws.realpage.com.
The footer `Privacy ` is
a discrete nav item, not inline-within-text, and stays
covered by the `.footer-widget footer a { text-decoration:
none }` opt-out above (footer nav items don't need an
underline indicator for 1.4.1 — they're not inline links in
running text).
------------------------------------------------------------ */
#privacyDiv label a,
#privacyDiv a[href*="Privacy"],
#privacyDiv a[href*="privacy"] {
text-decoration: underline;
text-underline-offset: 2px;
}
/** ------------------------------------------------------------
WCAG 2.2 AA 2.5.8 Target Size (Pointer)
------------------------------------------------------------ */
.footer-widget footer .footer-nav>ul>li a,
#privacyDiv label {
line-height: 30px;
}
/* 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. 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.)
BLISS-SPECIFIC ASYMMETRIC ADJUSTMENT: unlike Ascension/Aurora, Bliss
does carry a real, separate, pre-existing ~1px benign overlap onto the
privacy-policy link below the checkbox (confirmed live) — a flat -14px
on all four sides would widen that to ~3px. Rather than shrink the
hit-area back down (which would reopen the zero-cushion problem this
fix exists to close), the shortfall is borrowed from the top side
instead, which has ample clearance — the same asymmetric technique
already used for Balcony/Autumn-Ridge/Topaz's checkbox overlay
(top:-20/right:-14/bottom:-8/left:-14, identical widget/selector set).
Net: still a genuine 48x48-equivalent hit area (20 + 20 top-to-bottom
via the reduced bottom + increased top), no widening of the
pre-existing bottom-edge overlap. */
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; right: -14px; bottom: -8px; left: -14px;
}
.footer-widget footer #link-rp {
margin-bottom: 15px;
}
#main-content {
margin-top: 0;
padding: 0;
}
/* ------------------------------------------------------------
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 bliss01242023.sat-ws.realpage.com/Contact.aspx at 1280x900 (headless Chrome,
border-box heights): 11 of 14 footer targets under 24px.
footer ul#footerNav1 li a.CMSListMenuLink 20px, line-height 30px
footer ul#footerNav1 li a.CMSListMenuLinkHighlighted 20px (active item)
footer .footer-links li.footer-privacy-link a 15px, line-height 15.7px
footer .footer-links li.footer-site-map-link a 15px, line-height 15.7px
The existing `.footer-nav>ul>li a { line-height: 30px }` rule above does not
fix these: all are display:inline, and line-height does not change an inline
element's border-box height.
#footerNav1 needs no padding - its 30px line box already has room for a 24px
box, so nothing moves. The .footer-links pair is a single horizontal row
(Privacy | Sitemap side by side), the one arrangement where the negative-margin
cancel is safe: cancelling vertically cannot bring two horizontally-adjacent
hit areas into overlap. Verified: 0px height change, 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 ul#footerNav1 li a.CMSListMenuLink,
footer ul#footerNav1 li a.CMSListMenuLinkHighlighted {
display: inline-block;
min-height: 24px;
}
footer .footer-links li.footer-privacy-link a,
footer .footer-links li.footer-site-map-link a {
display: inline-block;
min-height: 24px;
padding: 5px 0;
margin-top: -5px;
margin-bottom: -5px;
}
/* ------------------------------------------------------------
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 is inline-block by default, so
min-width/min-height apply and can only ever RAISE a dimension. An
earlier `padding: 10px` shorthand REPLACED the button's own padding and
grew emerald10262023's header button from 90.5x44 to 110.5x47 — 20px
wider for no benefit, since it was already compliant. Verified with
min-*: elan08022023 menu-toggle stays 40x35 @375 and 55x45 @1440. */
body button.menu-toggle {
min-width: 28px !important;
min-height: 28px !important;
}
/* 6. Carousel dots and gallery pagination.
padding + background-clip:content-box grows the HIT AREA while the
painted dot keeps its original size, so the carousel looks the same.
The padding is per-widget because the dots differ in size, and with
box-sizing:border-box the content box (= the painted area) is
28px - 2*padding. Get this wrong and the dot visibly SHRINKS.
.owl-dot measured 7x7 -> padding 10px leaves 8px painted
flexslider dots measured 14x14 -> padding 7px leaves 14px painted */
body button.owl-dot,
body .owl-dots button.owl-dot {
box-sizing: border-box !important;
min-width: 28px !important;
min-height: 28px !important;
padding: 10px !important;
margin-left: 2px !important;
margin-right: 2px !important;
background-clip: content-box !important;
}
body .flex-control-nav a,
body .flex-control-paging a {
box-sizing: border-box !important;
min-width: 28px !important;
min-height: 28px !important;
padding: 7px !important;
background-clip: content-box !important;
}
/* a.pagination-item is deliberately NOT handled here. MEASURED REGRESSION:
on haute011326.sat-ws the gallery tiles are
`a.fancybox3.gallery-item.pagination-item` at display:block, 469.5x449.5.
Forcing `display:inline-block` collapsed them to 28px and shortened the page
by 3,936px — it destroys the gallery grid. The flagged element was a
380x2 collapsed inline on one site (17 rows, 1 site); that is not worth
risking every gallery on the fleet. Route it to its own ticket with a
container-scoped selector if it matters. */
/* 7. Header / footer phone links — NOT handled here. 6 rows / 5 sites,
flagged at ~102x19.
MEASURED ON PROD (181-site sweep, 2026-08-25): the rule
a.footer-phone.seo-number, a.header-phone.seo-number
{ padding-top:5px; padding-bottom:5px }
SHRANK the phone CTA on 30 live sites — e.g. affinityatkendrick.com,
esprialiving.com, affinityathudson.com: a.btn.footer-phone.seo-number went
137x38 -> 137x32, and apartmentsdavie.com 175x46.6 -> 175x40.6. On those
templates the element is a styled button whose own padding is larger than
5px, and `padding-top/bottom` REPLACES it rather than adding to it.
6 flagged rows is not worth a visible shrink on 30 sites. `min-height`
would be safe but is a no-op on the inline instances that are actually
flagged, so it would buy nothing. Needs a per-template rule that knows
whether the phone renders as inline text or as a button. */
/* 8. "Read More" expander — 26 rows. Measured on encorerise.com: 94.5x20,
`display:inline`, no sibling controls in its row, so vertical padding is
safe here and lifts it to 38px.
REMOVED from this rule after measurement, do not re-add:
a[href*="greystar.com/privacy"] (38 rows / 7 sites) — every instance
measured is ALREADY compliant (mirabellahouston 95.3x44,
capitalplaceatsouthwood 94.6x44 and 132x27, thegeorgianapts 41x28).
Padding them gained nothing and BROKE the footer legal row: on
elan08022023 the base CSS makes that link `display:inline-block` at
44px alongside "Disclosures & Licenses" / "DMCA Agent"; +9px padding
grew it to 62px and dropped its centre 9px BELOW its row-mates —
visible zig-zag, confirmed in a screenshot.
a[href*="onlineleasing.realpage.com"] (12 rows) — no instance measured
under 24px, so there was no evidence it needed the rule, and it
carries the same row-breaking risk.
Both need a per-template, container-scoped rule if they are ever a real
failure. A fleet-wide href selector cannot tell "already fine" from
"too small". */
body a.more-link {
padding-top: 9px !important;
padding-bottom: 9px !important;
}
/* 9. In-prose content links — the last and largest remaining bucket
(~191 rows), e.g. neighbourhood/POI links inside pasted body copy:
a "Bert Fields Park" 109.7x18 parent p.MsoNormal prose 425 chars
These are arguably EXEMPT under 2.5.8's Inline exception, but
Silktide flags them, so they are padded here to clear the check.
4px, not more: the flagged links measure 17-22px tall, so +8px lands them
at 25-30px — clear of 24 without enlarging the box further than needed.
Measured on thegeorgianapts-dallas.com/Neighborhood.aspx: pad 4px gives
minHeight 26.0; pad 7px gives 32.0 but widens the box-overlap between
links on adjacent lines from 26px to 32px for no compliance gain.
Vertical padding on an INLINE box grows the hit area (which is what
Silktide measures) without pushing text lines apart. Measured on
thegeorgianapts-dallas.com/Neighborhood.aspx, altalongwood.com and
thearialiving.com/site-map.aspx: body scrollHeight delta 0 at
1440px, but -20px to +27px at 375px, and scrollWidth delta 0 at
every width. None of these links carry a background-color or border
(measured: 0 of them), so the enlarged box is invisible. So: no horizontal overflow, small vertical movement
on mobile — QA regression check §3a in the validation guide.
Scope is deliberately narrow — p / td / span, classless links only.
DO NOT broaden this to `a:not([class])`: measured on
mirabellahouston.com that also pads already-compliant 44px nav and
footer links up to 57px, inflates the footer logo 170px -> 184px,
and SHRANK a 44px CTA to 30px. */
body p a:not([class]),
body td a:not([class]),
body span a:not([class]) {
padding-top: 4px !important;
padding-bottom: 4px !important;
}
/* ---------- end WCAG 2.5.8 Target Size (TFS 3040687) ---------- */