The first two posts in this series of articles were about using scanning tools to make a site better, watching the framework over time, and crawling the site to find unique content the test sample misses. This post is about something different. It is about how scan results can be used against an organization, and why that is worth understanding even when the findings are not real problems for users.
If the first two posts were about the work of accessibility, this one is about risk. The two are related, but they are not the same thing, and the difference trips up a lot of organizations.
The Same Tools, Pointed the Other Way
The scanning tools we have been talking about are not hard to get. Many of them are available to anyone, and running one against a public website takes very little effort. That cuts both ways. The same kind of scan an organization runs to improve its own site can be run by someone outside the organization to build a case against it.
This happens more than people expect. A law firm, a prospective plaintiff, or the law firm's accessibility expert will run an automated scan of a public site, collect the list of reported failures, and present that list in a demand letter or a complaint as proof that the site does not conform with WCAG. The list looks damning. It often has a large number of items on it, and to someone unfamiliar with how these tools work, a long list of scanner-reported failures sounds like a serious problem.
Here is the part that matters. As we covered in the earlier posts, a scan reports plenty of things that are not real barriers. Some are technically a failure but have no effect on a person using the site. Some are not failures at all, just the tool misreading the page. The people sending these letters almost never check which is which. They take what the scan returns and build the claim around it, because the raw count serves their purpose.
Why a Clean Understanding of Your Own Site Helps
This is one more reason the approach in the first two posts is worth the effort. An organization that has done its manual testing, fixed the real barriers, and understands its own scan results is in a very different position than one that has only ever seen its site through someone else's single scan.
When a demand letter shows up with a list of failures, that organization can read the list for what it is. It can separate the genuine issues from the minor ones and the false alarms, because it has already done that work. It can respond from knowledge instead of alarm. The organization that has no baseline of its own has no way to push back. It only has the other side's list, and the other side's framing.
I am not offering legal advice here, and how to handle a demand letter is a conversation for an attorney. The point is narrower. Knowing the real state of your own site is what lets you and your attorney tell a strong claim from a weak one.
When It Makes Sense to Fix Things That Are Not Really Problems
There is a wrinkle worth being honest about. Knowing that a finding is harmless is not always the end of the decision. A finding we have correctly judged to be minor, or not a real issue at all, still shows up on an outside scan. The contrast flag on text that sits over a dark background image is a good example. We know it is fine. An outside scan does not, and it will report it every time.
Because the people running these scans rarely check whether a flag is valid, every extra item on the report is one more line they can point to. A site that returns more flags invites more attention, even when those flags are meaningless. So there are cases where it makes sense to fix something not because it helps any user, but simply to keep it from showing up as a failure in someone else's scan. That is a risk decision, not an accessibility decision, and it is fair to treat it as one.
I want to be careful with this idea. It is not a suggestion to chase every false positive, which would undo the time savings the earlier posts were about. It is narrower than that. When we review scan results, it is worth noticing which findings, real or not, are the ones most likely to surface in an outside scan and add to the apparent failure count. Those are the ones worth weighing for a fix on risk grounds alone. It is a judgment call, and it belongs in the same kind of risk-based thinking an organization already applies to other parts of its work.
The Tool Reports, a Person Decides
Across these posts, the theme has been the same. Automated scanning tools are useful, and they are useful in more than one way, but only when we understand what they are actually telling us. They watch the framework over time. They crawl the site to find unique content. They can expose us to risk in the wrong hands, and a clear view of our own site is the best protection against that. What ties all of it together is judgment. The tool reports. A person who understands WCAG decides what the report means.
None of this happens quickly, and it is not meant to. It takes time to build a baseline, fix the real issues, and grow the knowledge to read scan results well. That is normal, and it is worth it. The next post brings the whole series together in one place.
If you have questions about how any of this applies to your own site, or you would like help thinking it through, feel free to reach out to our team. We are always glad to talk it through.
Want to See More Content Like This?
Want the latest blog posts, videos, white papers, and announcements? Sign up for our mailing list and stay in the loop!
We're Here to Help When You're Ready
Take a deep breath. Then feel free to reach out to our team when you're ready to discuss your accessibility needs.
0 comments on “When Scan Results Become a Legal Risk (Part 3)”