/* ============================================================
wcag-s0081-topaz.css
WCAG 2.1 Level AA override for the S0081-Topaz Kentico template
(TemplateId 1400, DefaultCssFileName: RPcssMaster_S0081-Topaz).
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.
Ron specifically named this template in TFS 2849882
(Republic Flats / republicflats.com) as outside the current
8-template remediation scope.
Note: The Topaz master CSS form-control borders use #253746
(~12:1 on white) which already PASS. Form-contrast failures
Silktide reports for this template come from shared webpart
CSS or per-property overrides â those fixes go at the
property level, not here.
============================================================ */
/* ------------------------------------------------------------
WCAG 2.4.7 Focus Visible
------------------------------------------------------------ */
.navbar-toggle:focus-visible,
.dropdown-toggle:focus-visible,
.btn:focus-visible,
.form-control:focus-visible,
#contactUsEnhancedContainer input:focus-visible,
.homeContactFormHolder .contact-mobile-form input:focus-visible,
.contactus-float-input-div input:focus-visible,
.contactus-float-input-div select:focus-visible,
.contactus-float-input-div 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.11 Focus Not Obscured
------------------------------------------------------------ */
html {
scroll-padding-top: 100px;
}
:focus-visible {
scroll-margin-top: 100px;
}
/* ------------------------------------------------------------
WCAG 1.4.11 Non-text Contrast (form controls + UI)
Base failures:
1. .FloorPlansV3 .fp-switch-tabs { border:1px solid #e7e7e7 }
#e7e7e7 on white â 1.18:1 â fails 3:1.
2. #contactUsEnhancedContainer .form-control failure comes
from shared webpart CSS â Ron flagged this for Republic
Flats in TFS 2849882.
Specificity strategy for the #contactUsEnhancedContainer rule:
body + ID matches the widget's own specificity (1,1,1) so
source order wins, and the !important handles the base's
`border-bottom:none` (no color to override).
------------------------------------------------------------ */
.FloorPlansV3 .fp-switch-tabs,
.FloorPlansV2 .fp-switch-tabs {
border-color: #595959;
}
body #contactUsEnhancedContainer .form-control {
border-bottom: 1px solid #595959 !important;
}
/* ------------------------------------------------------------
WCAG 1.4.3 Contrast Minimum (text)
Base failures:
#7e7e7e in 5+ rules â 4.4:1 â fails 4.5:1 by a hair.
Shared footer-disclosure opacity 0.6 â 0.85.
------------------------------------------------------------ */
.FloorPlansV3 .specification,
.FloorPlansV2 .specification {
color: #595959;
}
.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,
a[href$="Privacy-policy.aspx"] {
text-decoration: underline;
text-underline-offset: 2px;
}
a.btn,
a.button,
.btn,
.btn-primary,
header a,
nav 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)
Topaz uses the same `.web-home-template` page wrapper /
`.column-content .html-content` rich-text pattern as
Autumn-Ridge. Verified against apartmentsathiddencreek.com
(inline links "central spot", "thoughtful layouts",
"close to home" inside `.column-content .html-content`).
------------------------------------------------------------ */
.web-home-template .column-content .html-content a,
.web-home-template .copy-overlap a,
.web-home-template .copy-overlay a {
text-decoration: underline;
text-underline-offset: 2px;
}
.web-home-template .html-content a.btn,
.web-home-template .html-content a.button,
.web-home-template .ws-cta--primary a,
.web-home-template .cta-wrap a,
.web-home-template .cta-item {
text-decoration: none;
}
/** ------------------------------------------------------------
WCAG 2.2 AA 2.5.8 Target Size (Pointer)
------------------------------------------------------------ */
/* 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). The painted box stays 24×24
(position:relative already set above); this adds a transparent ::before
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).
ASYMMETRIC insets — intentional, do NOT "fix" this to be symmetric.
Live click-testing (TFS 2987209) found the "privacy policy" link sits
only ~5px below the checkbox on this template — reproduced specifically
at the narrow 375/390px viewports, where the consent text wraps and the
link sits closest. A symmetric 44×44 ring would swallow ~3px of the
link's top edge and steal its clicks there. SC 2.5.5 has no centering
requirement, so the shortfall is borrowed from the top side instead,
which has ~24px of clearance (no left/right neighbor within 45px). Net:
genuine 44×44 hit area, ~1px buffer on the bottom edge, zero measured
click-stealing at 375, 390, 768, and 1440px.
FIX (TFS 2987209, fleet rescan 2026-08): these insets were sized against
a 24x24 containing-block assumption, but the checkbox is
box-sizing:border-box, so the real containing block (padding box) is
20x20 (24px - 2*2px border). That silently ate 2px off every side of
the design above, landing this at the true SC 2.5.5 floor rather than
the intended ~1px buffer - measured as a 1-6px shortfall in the fleet
rescan. Adding 2px (one border-width) to each of the four insets below
restores the originally-intended margins on the correct 20x20 base
(48x48 total, ~5px buffer bottom) while preserving the asymmetric
top/bottom split that keeps this off the link. Do not re-symmetrize. */
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;
}
/* ------------------------------------------------------------
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 topaz012523.sat-ws.realpage.com/Contact.aspx at 1280x900
(headless Chrome, border-box heights): 4 footer target(s) under 24x24.
footer .footer-links li.footer-privacy-link a 58.2 x 21, display:inline
footer .footer-links li.footer-site-map-link a 66.2 x 21, display:inline
footer #ada-hud-links a#link-ada / a#link-hud 20 x 26.7 - fails on WIDTH only
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 and no horizontal overflow. Document height +0px at
1280px; +4px at 390px, from the mobile-only a#link-rp rule below.
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-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): supersedes the
24px (#2982346, AA) rules below in place with 44px, per plan §3.3
(44px replaces 24px on the same selector — one stanza, not two layered
ones; 44 satisfies 24 so there is no compliance reason to keep both).
Production completeness sweep (2026-08-20) measured, at the AA-fixed
24px state: ADA/HUD icons 27x32 (fails width, height already >24 but
still <44) and a#link-rp 140x38.7 (fails height only, width already
passes). Both need min-height bumped to 44 now that AAA height is the
floor; ADA/HUD also needs min-width bumped from 24 to 44. */
footer #ada-hud-links a#link-ada,
footer #ada-hud-links a#link-hud {
min-width: 44px;
min-height: 44px;
}
/* MOBILE-ONLY target originally (a#link-rp measured 140x26.7 at 1280px,
passing AA there, and 120x21 at 390px). At the 44px AAA floor this now
needs the min-height everywhere, not just mobile. Deliberately NO
`svg { height: 20px }` guard: inline-block + min-height does not
stretch the mark, and pinning the SVG cost 57px of document height on
Zen-Garden where the same guard was tried. */
footer a#link-rp {
display: inline-block;
min-height: 44px;
}
/* TFS 2987209 — WCAG 2.2 AAA 2.5.5 Target Size (Enhanced): blog search
input/submit. Production completeness sweep (2026-08-20) measured
150x30 / 40x30 on live Topaz — the exact pre-fix dimensions of the
shared BlogSearchBar widget rule already shipped fleet-wide in this
ticket (rpWebpartCss_BlogSearchBar.css: `body .blog-search-box`/
`body .blog-search-submit`, min-height/min-width:44px). That shared fix
is DB-resident (served via GetResource.ashx, not the static CDN this
file rides — see prod completeness sweep §9) and per-site DB import
can lag independently of this ticket's code; RPcssMaster_S0081-Topaz.css
also carries its own `body .blog-search-box{height:30px}` override at
equal specificity to the shared fix's `min-height`, so there is no
cascade reason for it not to apply once imported. Repeating the same
rule here at this per-template override's guaranteed-last, always-CDN
-deployed layer closes the gap regardless of DB-import timing — a
harmless no-op duplicate if the shared fix is already live, a real fix
if it isn't yet. */
body .blog-search-box {
box-sizing: border-box;
min-height: 44px;
}
body .blog-search-submit {
box-sizing: border-box;
min-width: 44px;
min-height: 44px;
}
/* ------------------------------------------------------------
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