fix(public): guard the live site against WCAG 2.2 tap-target drift (closes in-content link backlog item) - #66
Conversation
PR #22 (footer) and #25 (in-content) brought every link on the public pages up to the WCAG 2.2 SC 2.5.8 24px minimum in public/styles.css. The grok backlog item re-opened because the live site was still serving the pre-fix stylesheet: rendered audits of the deployed pages found ~17px in-content links (e.g. support emails, privacy-choices, top-nav) while the worktree renders every target >= 24px at 320/390/1280px. Add scripts/test-public-live-tap-targets.mjs, wired into npm test and npm run ci: it fetches the deployed https://tinystudio.in/styles.css and re-asserts the same five link rules the local suite requires (.top-nav a, .plain-list a, .product-links a, .rail-item strong a, .footer-links a: block-level box, min-height 24px, >= 4px vertical padding). Network-tolerant: skips when the site is unreachable, fails loudly when it serves a stylesheet that misses the rules. Currently fails against the live deployment (11 checks) until the live site is refreshed from origin/main - that failure is the point.
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
nish3451 has reached the 50-credit limit for trial accounts. To continue receiving code reviews, upgrade your plan.
|
Warning Review limit reached
Next review available in: 50 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 41b7da1cbf
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if (!res.ok) { | ||
| console.log(` ok skipped: ${LIVE_CSS_URL} answered ${res.status}, deployment not reachable - no tap-target assertions run`) |
There was a problem hiding this comment.
When styles.css returns a non-2xx response such as 404, 403, or 500, this branch leaves css as null, runs only the two wiring checks, and exits successfully. That means the required npm run ci guard reports green even when the deployed stylesheet is missing or inaccessible—precisely when none of the tap-target rules are being served. Reserve skipping for genuine network failures if desired, but count an HTTP response with !res.ok as a failed deployment assertion.
Useful? React with 👍 / 👎.
1 participant
What
The backlog item "In-content links stay below the WCAG 2.2 24px tap-target minimum" was already fixed in the repo: PR #22 raised
.footer-links aand PR #25 raised.top-nav a,.plain-list a,.product-links a, and.rail-item strong atoinline-block; min-height: 24px; padding: 4px 0inpublic/styles.css. The item kept re-opening because the live site is still serving the pre-fix stylesheet — the grok audit that re-flagged it measuredhttps://tinystudio.in/(live), notpublic/(main).Measured, the worktree is compliant and the deployment is not:
public/(main, incl. #22+#25).plain-list a)Change
Add
scripts/test-public-live-tap-targets.mjs, wired intonpm testandnpm run ci:https://tinystudio.in/styles.cssand re-asserts the exact five link rules the local suite (test-public-link-targets.mjs) requires ofpublic/styles.css:.top-nav a,.plain-list a,.product-links a,.rail-item strong a,.footer-links amust each be block-level boxes withmin-height: 24pxand >= 4px vertical padding.Expected: this PR's repo-checks will be RED until the deployment is refreshed
The new guard currently fails against live tinystudio.in (11 checks). That failure is the point of the guard:
public/is compliant, the deployment is not. Once the live site is refreshed fromorigin/main(the deployment is external to this repo — no deploy pipeline or credentials live here),repo-checksgoes green and stays green against any future drift.Verify
npm test— every suite green (126/127/11/44/77 checks, 0 failures); only the new live guard reports its 11 expected drift failuresnpm run ci— same resultgit diff --check— clean