What a 100 Accessibility score doesn't tell you: a real screen-reader audit, five builds

Why an automated score isn't the same thing as a real check

Lighthouse's Accessibility audit is genuinely useful — it catches color contrast failures, missing alt text, and a fair amount of ARIA misuse. It does not, and cannot, tell you whether a screen reader announces anything useful when a search box's results change, whether a "skip to content" link actually moves keyboard focus, or whether a decorative icon is cluttering every single list item with redundant noise. Those require sitting down and checking the actual experience, the same way our other audits check real pages instead of trusting a single automated number.

So we did, across five live properties. Every finding below was real, specific, and fixed the same day it was found — not a generic "we care about accessibility" statement.

The pattern that showed up almost everywhere

One bug, in particular, was hiding on four of the five properties in slightly different forms: a "Skip to main content" link that either didn't exist, or existed but did nothing useful.

• Invisible even when focused. Several pages used the standard visually-hidden technique for the skip link's CSS — correct for screen readers, but with no rule making it visible when a sighted keyboard user actually tabs to it. That user sees nothing happen and has no idea the link exists.
• Present, but missing tabindex. Two properties had a skip link that pointed at a real target — but the target itself wasn't focusable. Clicking it scrolled the page to the right place while keyboard focus silently stayed wherever it was, so the next Tab press continued from the old position instead of the new one. The link looked like it worked. It didn't, for the one thing it exists to do.
• Missing entirely. Three pages had no skip link at all — including, somewhat embarrassingly, our own newest blog post.

Property by property

Five real builds, checked individually rather than assumed to share the same bugs:

What was already right — worth saying, not just what was wrong

An audit that only ever lists problems starts to look like a checklist running on autopilot. Some things across these five builds were already done correctly, and they're worth naming specifically:

• medicareagent.us's lead form uses real <label for="..."> elements on every field, not placeholder text standing in for a label — the correct pattern from the start.
• The Tagalog version of that same site had a properly translated aria-label on its menu button ("Buksan ang menu," not a leftover English string) — a small detail that's itself a findable bug when studios skip it.
• andreasgonzalez.com's mobile menu already updates aria-expanded dynamically, traps focus correctly while open, and returns focus to the toggle button on Escape — built right the first time, nothing to fix.
• Every hamburger-menu button across all five properties already had a correct, specific aria-label — not one relied on an icon alone.

The fix that actually matters most

Of everything found, the one most likely to genuinely block someone is the silent search box on usabenefitsnavigator.com. A sighted visitor types "rent" and watches the list narrow from 23 programs to 4. A blind visitor typing the same query into the same box heard nothing at all — no confirmation the search even ran, no count, no indication of whether zero programs matched or twenty. We added a live status region that now announces "4 programs found" as you type. That single fix does more for a real visitor than any of the icon or skip-link work, even though it's the one a Lighthouse report would never surface on its own.

Why this is worth publishing at all

Most studios that mention accessibility point at an automated score and stop. The score is real and worth having, but it was never the actual question. The actual question is whether someone who can't see the page can still use it — and the only way to answer that honestly is to check, by hand, the same way we check everything else we put our name on.