- Plaintiff firms use free scan tools as a triage layer to find targets, so a high scan-error count is what gets your site discovered.
- Fix scan-detectable issues first, then fix real user paths, and keep dated records of everything.
- The record is the defense: preserve a dated before-state, then remediate fast.
Automated scan errors make your website a lawsuit target because plaintiff firms run free scanners across thousands of sites to find easy candidates, and a high error count flags you as one. The scan is not the case. It’s the tripwire. This is general information, not legal advice.
Why scan errors get you found
Large companies have mostly remediated. Small and medium businesses are now the primary targets, and the vulnerability is the awareness gap: owners who don’t know their site is throwing dozens of machine-detectable errors.
Plaintiff-side operations don’t hand-inspect every site. They automate the first pass with free tools, then sort by error volume. The sites at the top of that list get a closer look.
The tools used at this triage stage fall into a few categories:
- Browser-based checkers that flag missing alt text, empty links, and contrast issues on a single page.
- Crawlers that scan an entire site and rank pages by error count.
- Free audit extensions built into developer tooling that produce a quick accessibility score.
None of these prove a real access problem. They surface signals. But those signals are exactly how your site moves from anonymous to noticed.
Scan layer versus claim layer
There are two separate things happening. Scan-detectable errors are how you get discovered. Real problems a person hits with a screen reader are what an actual claim gets built on.
That distinction sets your priority order. Clean up the scan-detectable issues first so you stop showing up in the triage list, then fix the harder problems in real user paths. We break down that ordering further in our guidance on how to sequence fixes by risk and effort.
| Aspect | Scan layer | Claim layer |
|---|---|---|
| What it catches | Machine-detectable errors on individual pages | Broken flows a real user cannot complete |
| Role in litigation | How you get discovered | What a case is built on |
| Fix priority | First | Second |
| Detected by | Free automated tools | Manual testing with assistive tech |
If a demand letter arrives
Don’t act rashly. The instinct to quietly fix the site overnight can work against you if you skip the first step.
Here is the order that protects your position:
- Preserve the evidence, not the website: capture a dated record of the site’s current state through screenshots, crawls, archived copies, and scan results. This is your litigation-hold obligation.
- Remediate quickly after the before-state is documented. Fixing the live site is not destroying evidence once you have proof of what it looked like.
- Tie each fix to a specific issue with dates, so your remediation records line up with the preserved before-state.
The sequence matters. Remediating without a preserved before-state can look like scrubbing evidence and leaves you unable to show what the issues actually were.
Fast remediation before a suit is filed supports a mootness argument: the claim can be argued moot when the relief sought has already been provided. That argument only holds with dated evidence tying specific fixes to specific dates.
Settlement terms and the window after
The non-monetary terms are the hidden cost. Forced audits, quarterly user testing, and ongoing monitoring obligations can exceed the settlement figure itself.
Plaintiffs re-check after settlement. The 12 to 24 month compliance window carries breach risk, so meeting the terms becomes a deadline-and-evidence problem: track progress against the agreed scope and hold proof before the window closes. Keeping a running record of these documents over time makes that far easier.
Good faith is a documentation posture
Accessibility is never one-and-done. Developers and content managers reintroduce problems, so maintenance and monitoring matter as much as the first cleanup.
An organized, ongoing program record separates a defensible company from one that looks like it did nothing. That record includes:
- Audit reports with dates and scope.
- A monitoring cadence showing regular re-checks.
- Training records for developers and content teams.
- A log of fixes over time, each tied to the issue it addressed.
An accessibility statement and a contact method help in negotiation and as good-faith evidence, but they are not a defense, and a phone line alone does not cure an inaccessible site.
The record is the defense. Mootness, follow-through, and good faith are all only as strong as the dated documentation behind them. If you want help documenting your posture, send us a message and we’ll respond quickly, usually within a few hours.
