Audit tools are good at counting. They're bad at understanding what they're counting.

That causes two kinds of mistakes. False alarms send you fixing problems that don't exist, and sometimes you report them to a client and have to take them back. False all-clears are worse, because a clean report stops you from looking.

Here are four we ran into on real client sites, and how to check for each one.

1. "102 images missing alt text" (actual number: 0)

Our crawler flagged 102 images with no alt text on one page of an apartment company's site. We reported it as a finding.

Every one of the 102 was a false alarm. The page had a map of the company's communities, and the map plugin stored a copy of each community card inside a block of JSON data for its pop-up windows. Inside JSON, quote marks are escaped, so the image tags looked like this:

<img src=\"...\" alt=\"Maple Court\">

Our check looked for alt=" and didn't recognize alt=\". So it counted every map card as an image with no alt text. The real page HTML had zero missing.

Where this happens: maps, sliders, page builders and filtering plugins often ship markup inside JSON or JavaScript strings. A tool that scans the whole page source counts every copy.

How to check: before you report an alt text issue, open one flagged image in the page source and look at what surrounds it. If it sits inside a <script> block or has backslashes before its quotes, it isn't a real image on the page.

2. "2,205 checks, zero contrast problems" (it only looked at the top of each page)

We built an automated check that tested text contrast across a whole site: every page, several screen sizes. It reported 2,205 page renders and zero findings.

That turned out to mean "zero findings in about 9% of each page."

The check worked by asking the browser what color sits behind each piece of text. Browsers only answer that for things currently on screen, so the check skipped anything outside the visible window. Since it never scrolled, it only ever tested the first screenful of each page. Further down, two large headline numbers were rendering white on a white background (a contrast ratio of 1.00:1, meaning invisible).

Three related traps, from the same project:

  • Mid-animation readings. Headers that change color as you scroll get caught halfway through fading and reported as failures. Turn off transitions before measuring.
  • Gradient backgrounds get skipped. Many tools treat a gradient as "an image" and skip the text on it. Check the text against each color in the gradient instead.
  • Frosted glass can't be calculated. Text on a blurred, see-through bar sits on whatever is scrolling behind it. You can only measure it from screenshots.

How to check: make sure any contrast tool scrolls the whole page. Then look at the bottom half of a few pages yourself. If the tool never found anything below the fold, ask whether it ever looked there.

3. "No layout problems while scrolling" (the page never scrolled)

Many modern sites use smooth scrolling libraries. A common one is called Lenis. These libraries take over scrolling from the browser, and they ignore the standard command scripts use to scroll a page.

The result: an automated check tells the page to scroll down, the page stays where it is, and the check measures the top of the page over and over. Nothing errors.

On one site this produced three wrong conclusions in a row. A check reported "no overlap while scrolling" when one element covered another by 428 pixels. Screenshots of lower sections came out blank. A full-page capture was missing content that only loads when you scroll to it.

How to check: confirm that the scroll actually happened before trusting any reading. In a script, scroll, then read the position back:

window.scrollTo({ top: 2000, behavior: 'instant' });
await new Promise(r => setTimeout(r, 50));
console.log(window.scrollY); // should be close to 2000

The behavior: 'instant' option worked where a plain scrollTo(0, 2000) was ignored. If the number that comes back isn't where you asked to go, every reading after it is suspect.

4. The tool and the rules disagree

This one is a different problem. The tool isn't broken. It just measures something other than what the standard says.

Accessibility guidelines say decorative images, like a logo repeated in a scrolling strip, should have empty alt text (alt="") so screen readers skip them. We did exactly that on one site. The client re-ran their AEO scoring tool and saw "no issues corrected." The tool counts every empty alt as a failure, even when it's correct.

We saw the same thing in a keyword tool's site audit: 3 of its 5 "SEO issues" were pages we had deliberately set to noindex.

What to do: you can be right by the standard and still have a client who sees a red mark. For alt text the practical fix costs nothing. Give every image a short, truthful description, and keep decorative duplicates hidden from screen readers the usual way. That passes both the guideline and the tool.

More generally, when you tell a client something is fixed, check it the way their tool measures it, not only the way the rules describe it.

A five-minute sanity check for any audit

Before an audit result goes to a client, or into your own to-do list:

  1. Spot-check one flagged item by hand. If it isn't real, assume the whole category might not be.
  2. Ask what the tool couldn't see. Content below the fold, inside scripts, behind logins, or loaded on scroll.
  3. Be suspicious of round numbers. "Zero issues" across thousands of checks deserves one manual look.
  4. Check against the client's tool too. Being technically right doesn't help if their dashboard still shows red.

Audit tools save hours. Just treat their reports as leads to check, not conclusions.