Files
claudetools/projects/acg-website-showcase/multipage/design/review-grok-bold.md
Mike Swanson 57322c66f5 sync: auto-sync from GURU-5070 at 2026-06-15 06:07:00
Author: Mike Swanson
Machine: GURU-5070
Timestamp: 2026-06-15 06:07:00
2026-06-15 06:07:20 -07:00

8.0 KiB

VERDICT: [INFO] Dial-back largely lands as credible-bold for a B2B MSP selling trust. It reads as inked poster authority rather than loud gig-poster or bland corporate. Orange is disciplined (buttons + .amp + .tier__flag + section accents). Hard 2px borders, 0-radius, and Anton numerals give weight without noise. However, forced uppercase + Anton on functional labels (.svc__name, .faq__q, .brand__name, .tier__name) plus global img filter push it toward "designed artifact" and away from quiet competence. Not overcorrected to bland; still slightly loud on the typography axis for pure trust sale.

Assessed only html[data-skin="bold"] and descendants across the four files. Base styles apply unless overridden. JS is skin-agnostic except for the cycle and verdigris image swap.

(1) Did the dial-back land?

  • Intent visible and mostly successful: near-black #0C0A09 / bone #F4EDE1 canvas, orange restricted per spec, thick ink borders on .site-header / .trust / .pricing / .faq / .home-services / .cta-band / .rate-card / .calc__shell, sharp corners, Anton numerals on .tier__price (clamp 4.25rem) and .trust__num (2.6rem), grayscale(1) contrast(1.08) photos.
  • Specifics that still feel loud: uppercase Anton at 1.35rem on .brand__name (header, both pages), 1.5rem .svc__name (index.html:105-110), 1.7rem .tier__name (pricing.html:56+), 1.25rem .faq__q (if present). These are UI labels, not headlines.
  • The "one headline word" (.amp) + single "Most chosen" flag work cleanly.
  • Photos + bone/near-black + 2px rules create a consistent documentary-ink story that fits "concierge since 2001" better than full radical poster would.
  • Overcorrection risk: none apparent; it is still visually assertive. On pricing.html the stacked rate-cards + orange flag read strong but professional.

(2) WCAG AA contrast (using the exact values supplied)

Light (#F4EDE1 bg):

  • #16120F ink on bone: ~14+:1 PASS (normal + large).
  • #C23A0A accent-ink on bone: ~5.6:1 PASS (CSS comment at styles.css:154 roughly accurate for text).
  • #E24A12 button fill + #FBF7F0 text: ~4.1:1 FAIL (below 4.5:1 for normal text). Affects .btn--primary, .tier__flag, .brand__mark (accent bg), current nav treatment in some states, .section-tag::before accent bar.
  • Secondary: --ink-3 #6B6359 on paper and some surfaces hovers ~4.0-4.3:1 — marginal for 0.72-0.78rem text (.hero__note, .section-tag span, .tier__price .per, footer, form labels).

Dark (#0C0A09 bg):

  • #F4EDE1 on #0C0A09: excellent PASS.
  • #FF8A4D accent-ink on dark: high PASS.
  • #FF5A1F button + #0C0A09 text: ~7+:1 PASS.
  • --ink-3 #9A9082 on dark: ~5.5:1 PASS for small text.

Flags: light-mode primary button/flag text contrast fails; several muted elements in light are borderline. No dark fails under the stated palette. (Refutes the blanket "AA" implication in bold comments.)

(3) Anton at body/UI sizes + forced uppercase on .faq__q / .svc__name / .brand__name

  • Readability problems present. Anton is a high-contrast, condensed, geometric display face. At 1.25rem-1.7rem all-caps with only 0.005em letter-spacing it loses ascender/descender cues, reduces word-shape recognition, and can appear dense or "shouting."
  • Affected elements: .brand__name (1.35rem, header on index.html:32 and pricing.html:21), .svc__name (1.5rem, index.html:105-110 and services teasers), .tier__name (1.7rem), .faq__q (1.25rem), plus h1/h2.
  • Long phrases suffer most: "Microsoft 365 & Email", "Business Phones", full questions in FAQ, "Arizona Computer Guru". On mobile (<680px, <820px queries) wrapping + caps increases visual noise.
  • .tier__price and .trust__num at larger sizes (2.6-4.25rem) are acceptable poster numerals.
  • Hero h1 cap 5.5rem is within the "capped ~5.5rem" spec but remains loud in caps.
  • No evidence of tracking/kerning fixes for Anton.

(4) Grayscale img filter

  • html[data-skin="bold"] img { filter: grayscale(1) contrast(1.08); } (styles.css:204) hits every when skin is bold.
  • In the supplied pages it only affects the intended documentary photos (hero, about, story, etc. in index.html:68,94 and pricing.html equivalents via page-head/figures).
  • No non-photo images exist in these files, so no current collateral damage.
  • However, universal selector is over-broad: any future inline icon, logo asset, diagram, or UI screenshot rendered as will be desaturated. No exceptions (e.g., [data-no-filter] or .photo). The JS image swap path for verdigris is separate and does not guard bold.
  • Photos themselves lose any warm tonal cues that might support "Tucson / golden hour" story; contrast bump helps legibility but is global.

(5) Leak / breakage by other skins (scoping)

  • Core palette, fonts, borders, radius:0, img filter, and uppercase rules are correctly prefixed html[data-skin="bold"] and do not leak outward.
  • However, active nav treatment is broken under bold due to cascade order: bold rule at styles.css:205-206 only sets background-image (no size/position/color), while the later general multipage rule at styles.css:595-599 sets color + full background properties using --accent-ink. Last rule wins; bold skin gets the ledger-style accent-ink underline instead of its intended accent treatment.
  • .nav__link[aria-current="page"] on index.html (Home) and pricing.html (Pricing) will not reflect bold's accent choice when skin=bold.
  • No other cross-skin breakage observed. Verdigris/midnight/ledger rules are similarly prefixed and do not pollute bold. JS skin cycle (app.js:53,71-90) correctly includes "bold" and only does verdigris-specific src swaps.
  • .site-header bold border (2px) and background overrides are scoped and not overridden by later rules in conflicting ways.

(6) Responsive + real bugs

  • Responsive: most shared media queries (820px, 880px, 720px, 680px, 560px, 440px) apply. rate-card stacks, svc grid adjusts, nav collapses, hero switches to single column. Large bold h1 (clamp) and 2.6rem Anton .trust__num in 2-col trust grid (<720px) become cramped but do not overflow.
  • Issues:
    • Universal img filter + no photo-only class.
    • Incomplete bold active-nav override (see 5).
    • .btn, .brand__mark, and form controls inherit --f-display (Anton) at ~1.05rem; condensed caps on small interactive targets reduce legibility.
    • .tier--pop inset accent shadow + flag remain visible and orange-restricted as intended.
    • No layout breakage on the two pages; calc/faq/contact not in these files but would inherit same skin rules.
    • Page-head.ledger class on pricing.html is harmless (bold disables the repeating-linear ledger bg).
    • Inline script + localStorage skin persistence works for bold.
    • No JS console-level skin bugs visible.

Ranked, severity-tagged observations (terse, no edit suggestions):

[HIGH] Light bold primary button/flag contrast fail (#E24A12 fill + #FBF7F0): ~4.1:1 < 4.5 (styles.css:153,278; affects .btn--primary, .tier__flag, .brand__mark).
[HIGH] Active nav styling does not receive bold accent treatment due to later general rule override (styles.css:205 vs 595; index.html:38, pricing.html:27).
[HIGH] Universal img grayscale filter (styles.css:204) has no exceptions.
[MED] Forced uppercase + Anton at 1.25-1.7rem on .svc__name, .faq__q, .brand__name, .tier__name harms readability/scannability (styles.css:177-181,299,408,427,545; index.html:32,105-110; pricing.html:21,56+).
[MED] Several light-mode small text elements near or below 4.5:1 (--ink-3 #6B6359 etc. on bone/paper).
[MED] Anton at button/control sizes (1.05rem) and tight mobile hero/trust numerals.
[LOW] Hero h1 at max 5.5rem + caps is assertive on wide viewports (styles.css:182).
[LOW] No bold-specific handling or exceptions in app.js beyond the shared SKINS array.
[LOW] .ul underline and section-tag accent bars correctly use restricted orange.

Confidence in palette extraction, selector scoping, and markup coverage: high. Exact contrast ratios are approximate without runtime computation; real-browser or tooling verification would be required for borderline cases. All analysis derived strictly from the four read files.