Skip to main content
Performance & Accessibility · 6 min read

One flagged color was hiding three more: re-scanning usabenefitsnavigator.com

A PageSpeed run flagged one low-contrast hero subtitle. Searching for the same hex code — instead of just fixing the one element — turned up three more failures nobody had tested. Here's the full, honest account: two rounds of contrast bugs, 255 KiB of ad script deferred instead of deleted, a deprecation warning we chose not to chase, and why the final number is 95, not 100.

usabenefitsnavigator.com hadn't been re-audited under the current checklist at all — it was flagged as outstanding back in an earlier session and kept slipping behind client work. A screenshot from a routine PageSpeed check finally forced the issue: Accessibility 95, with one specific failing element named outright.

The flagged element passed our own math — which was the first sign something was off

The hero subtitle — "Browse 23 federal assistance programs for food, housing, healthcare, income, education, and utilities — all free." — was set in #B0BEC5 on the header's navy gradient. Run the actual WCAG contrast formula against the gradient's darkest stop and it clears 8.9:1. Against the lightest stop, still 6.5:1. Comfortably over the 4.5:1 floor, by our own calculation.

Lighthouse flagged it anyway. Rather than treat our own math as the final word, we searched the file for the exact hex code instead of just patching the one element Lighthouse pointed at.

What turned up: the same #B0BEC5 was also sitting on the founder-section subhead, a blog post timestamp, and a closing CTA paragraph — all on the same navy gradient, all with the same theoretical margin, all one rendering quirk away from failing the exact same way. Lightened all four at once to #D7DEE6 (≈9–12:1) instead of fixing the one Lighthouse happened to sample.

Round two: a completely different color, a completely different failure

A second pass surfaced a bug with nothing to do with the first one. The lavender "Need Immediate Help?" emergency box — 211.org, benefits.gov, the kind of content you really don't want to be illegible — was failing for real this time. Its title color, #5C6BC0, measured roughly 4.06:1 against the box's lavender background. Clearly under the line, no ambiguity.

The body text directly underneath it, #546E7A, measured 4.51:1 — technically a pass, by one one-hundredth of a point. That's not a number worth trusting on the next render, the next browser, or the next font hinting pass.

Same lesson, applied again: grepped both hex codes across the entire file before touching anything. #5C6BC0 was also the blog section's kicker label and the "Follow Us" label — both passing on lighter backgrounds, but at the same razor-thin ≈4.57:1 margin. #546E7A was reused on inactive tab buttons and panel labels, comfortably fine everywhere else. Darkened both site-wide: #5C6BC0→#3949AB, #546E7A→#3D5566, landing every single occurrence at 6.5–7.4:1 instead of leaving four near-misses standing because only one of them had been measured.

255 KiB of advertising nobody could see

A separate diagnostic — "Reduce unused JavaScript, est. savings of 255 KiB" — pointed at adsbygoogle.js. Checking the page for actual ad placements turned up zero <ins> tags anywhere. This is Google Auto Ads, not manual ad units — the entire library was downloading and parsing on every visit whether or not an ad ever rendered, and it lined up exactly with a second diagnostic flagging four long main-thread tasks.

The honest options were remove it or defer it. Removing it outright would cut off monetization if Auto Ads is active and approved on the account — not our call to make unprompted. Deferred it instead: it now loads on the visitor's first scroll, touch, or keypress, or after a four-second idle fallback if they never interact. Real visitors still see ads almost immediately in practice. The library just isn't competing with the page's own content for parse time during the load that actually gets measured.

A warning we looked at, understood, and chose not to fix

A later run showed Best Practices at 81, flagged for "Uses deprecated APIs — 1 warning found." The page's own JavaScript — tabs, search, the accordion — is plain, modern, vanilla code with nothing deprecated in it anywhere. The only two third-party scripts on the page are Google Analytics and the now-deferred AdSense library, and deprecation warnings sourced from inside Google's own minified code are a well-documented, unfixable-from-our-side category of finding — the deprecated call lives in their code, not ours.

Cutting Analytics or Auto Ads to chase one point in a category that doesn't touch SEO or real user experience isn't a trade worth making. We left it alone, on purpose, and said so. Best Practices recovered to 100 on a later run anyway — consistent with the warning coming from a conditional path inside the third-party script rather than anything on our own page.

Why the final number is 95, not 100

"This is good enough for me."

Final confirmed run, mobile:

97Performance
95Accessibility
100Best Practices
100SEO

Accessibility held at 95, not 100, after two separate rounds of real contrast fixes. We could have kept digging for whatever's left. Ari looked at the number and called it done — and that's a legitimate outcome, not a failure to record quietly. The number that gets published is the number that was actually measured, the same standard we hold for every page that invites someone to go check it themselves.

Two rounds, four colors fixed, one ad script deferred instead of deleted, one warning correctly left alone, one number accepted instead of chased. That's the actual shape of "meticulous" — not a single clean pass, but checking the thing that was flagged, then checking everywhere else the same mistake could be hiding, twice, before calling it finished.

We hold every property we touch to the same standing checklist — published, dated, and not retouched after the fact.

See how we audit other sites →