Accessibility Scan False Positives: How to Triage Automated Findings

The thousand-issue report

Run an automated accessibility scan on any real storefront and you will get a report with hundreds of findings. The instinct is despair, then triage paralysis. But a large share of automated findings are false positives, needs-review items the scanner cannot resolve, or technically true but practically harmless issues. Teams that try to fix everything in scan order waste months on noise while real barriers stay live.

The problem is not the scanners. Automated tools are genuinely good at what they do: catching missing attributes, structural issues, and contrast failures at scale. The problem is treating the scan as a verdict instead of a starting list. A scan tells you where to look. It does not tell you what matters. That judgment is the triage step, and most teams skip it.

The false positive patterns

Color contrast flags are the noisiest category. Scanners compute contrast ratios from computed styles, but they cannot see background images, gradients, or text over photography. A white headline over a dark photo gets flagged because the scanner reads the CSS background, not the image. Before fixing any contrast issue, look at the actual rendered page. A meaningful fraction will be false alarms.

Missing-alt flags on decorative images are the second classic. Scanners flag every image without alt text, but decorative images should have empty alt attributes, which some scanners still report as issues. The triage question is simple: does this image convey information? If yes, it needs real alt text. If no, empty alt is correct and the finding is noise.

Form-label flags get noisy on custom components. Scanners miss labels that are associated programmatically through ARIA or wrapping elements, especially in custom-built inputs. Keyboard-test the form before rewriting it. If a screen reader announces the label correctly, the scanner was wrong.

Landmark and heading findings need human judgment too. A scanner can tell you a page has no h1 or that headings skip levels. It cannot tell you whether the heading structure makes sense to a listener. Two h1s on a page is technically a finding. Whether it confuses anyone depends on the page.

A triage method that works

Sort findings into three buckets. Bucket one: confirmed barriers, verified by manual check or keyboard test. These get fixed first, ordered by page traffic. Bucket two: needs-manual-review, the contrast-over-image and custom-component cases. Timebox the review: if verification takes more than a few minutes per item, sample instead of checking every instance. Bucket three: accepted noise, documented as false positives so the next scan does not re-trigger the same panic.

Track your false positive rate per scan and per rule. If a particular rule is wrong 80 percent of the time on your stack, tune it out or deprioritize it permanently. The goal of triage is not a clean scan. It is a scan where every remaining finding is a real barrier worth fixing. Teams that triage well fix fewer issues and remove more barriers, because their effort goes where the users are.