Over the last few weeks I have written about automated scanning tools from a few different angles. We looked at why a scan is the wrong way to start, how a crawl reaches the content a sample cannot, and how the same scan results can be turned against an organization in a demand letter. Each post stood on its own, but the series never really stepped back to look at the whole picture at once. That is what this post is for.
If you have not read the earlier ones, this is a reasonable place to get the shape of it before going deeper. And if you have read them, think of this as the part where we set the pieces side by side and see how they fit.
One Tool, Several Different Jobs
The thread running through all of this is that a scanning tool is not one thing. It does several different jobs, and the trouble starts when we treat it as if it does only one.
In the first post, the job was watching the framework. We test a representative sample of the site by hand, build a baseline from that, and then point the scan at the same pages on a schedule so we can see whether things are holding steady or slipping. The scan is a steady gauge there, useful precisely because it runs against the same pages every time.
In the second post, the job changed. A crawl moves through the site on its own to reach the unique content that authors add page by page, the stuff no sample was ever going to cover. That is a sweep, not a gauge, and it makes the most sense later, once the framework is in good shape.
In the third post, the job had nothing to do with improving the site at all. It was about risk, about the fact that anyone can run a scan against a public site and use the raw list to build a case. Understanding our own results is what lets us tell a real problem from noise when someone else's list shows up at the door.
Same tool, three jobs. None of them is the job people most often expect from a scanner, which is finding every problem on the first pass. That expectation is worth examining on its own, because it is usually what gets an effort off on the wrong foot.
What Ties It All Together
If I had to name the single idea underneath the whole series, it would be judgment. A scanning tool reports. It does not decide. Every one of these jobs depends on a person who knows WCAG well enough to look at what the tool found and say what it actually means. Which items are real. Which are minor. Which are the tool misreading the page. Which ones, real or not, are worth fixing because they raise the odds of a demand letter.
That is why the order matters so much. Starting with a scan puts the report in front of the judgment. You end up with a long list and no way to read it, which is how teams lose weeks sorting findings that a baseline would have sorted for them, and how they end up fixing things that were never worth the time. Starting with the manual work puts the judgment first. After that, the scan has something to be measured against, and everything it reports lands in context.
It Takes Time, and That Is Normal
One more thread worth pulling out, because it runs quietly through all three posts. None of this is fast. Building a baseline takes time. Fixing the real issues takes time. Crawling for one-off content comes later still. And the knowledge to read scan results well is not something a team picks up in an afternoon.
That slower pace is not a sign anything is wrong. It is what real accessibility work looks like. A scanning tool can look like a way to skip past all of that and get an answer right away, and it is easy to see why someone under pressure would hope for that. Many of the companies that make these tools are upfront that a scan is only part of the picture, and the good ones say so plainly. The gap is usually not in what the tools claim, but in the assumption a busy team brings to them. What a scan hands over is a list, and the work of turning that list into something meaningful is the same work it always was.
Some teams have the time and the interest to build that knowledge on their own, and that is a fine way to go. Others would rather get a running start, or hand off the scanning itself so it stays consistent without pulling people away from their other work. There is no single right answer. It comes down to what fits the people you have and the time they can give.
Where to Go From Here
If you are just finding this series, the most useful path is to read the posts in order. The first covers where automated scanning fits and why a scan is not the right first step. The second covers crawling the site for the content a sample misses. The third covers how scan results can become a legal risk. Read together, they lay out a way of using these tools that has worked well for most of the organizations we help.
I want to be clear that none of this is an argument against using a scanner. A good scanning tool is worth having, and used in the right order it earns its place. The point is to get the full benefit out of it and skip the wasted time that comes from expecting it to be a shortcut. And the approach I have described is not the only one that can work. It is the one that has reaped the largest reward for most of our clients, but every site and every team is different, so treat it as a starting point rather than a rule.
And if you would like to talk through how any of this applies to your own site, feel free to reach out to our team. We are always glad to help.
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 “Bringing the Automated Scanning Series Together (Part 4)”