One of the things I have noticed over the years is that many organizations begin their digital accessibility effort by buying a scanning tool. It makes sense on the surface. A tool is something we can purchase, install, and point at a website, and within minutes it gives back a report full of issues to work on. It feels like progress. The trouble is that starting here often slows things down instead of moving them forward, and I want to walk through why that happens and what tends to work better.
I should say up front that I am not against automated scanning tools. They have a real place in an accessibility program, and I use them in my own work. This is not a post about avoiding them. It is about when they help and when they get in the way, based on what I have seen across a lot of different organizations. Every organization is a little different, so take this as experience rather than a rule that fits every situation.
This is the first post in a short series. In this one, I want to cover the starting point, why a scan is the wrong first move and what makes a better one. Later posts will get into the other jobs a scanning tool can do once the foundation is in place.
Why Starting With a Scan Causes Problems
Part of the issue is the marketing. Some tool makers suggest that their scanner will find an organization's accessibility problems and put it on the path to WCAG conformance. A few imply it will get an organization most of the way there on its own. That message is appealing, especially to a team that is under pressure to show they are doing something. But a scanner only checks the things a scanner can check, and that is a smaller slice of WCAG than most people expect.
When a team runs a scan as their very first step, a couple of things usually happen. The tool returns a large number of items, often hundreds or thousands, and the team has no easy way to tell which ones matter. Some are real problems. Some are technically a failure but have little effect on a real person. And some are not problems at all, just the tool misreading the page. Without a frame of reference, all of those items look the same. The team ends up spending its energy sorting the list instead of fixing the site, and the early excitement turns into confusion.
There is also a quieter problem. A scan can come back looking fairly clean while serious barriers are still sitting on the site. Things like a page that cannot be operated with a keyboard, or a custom menu that a screen reader cannot make sense of, often do not show up in an automated scan at all. A team that trusts the scan can walk away believing the site is in good shape when it is not.
A Sequence That Tends to Work
What I have seen work better is to start with manual testing and bring the scanning tool in afterward. Manual testing means a person actually using the site, checking it against WCAG, and operating it the way someone with a disability would, including with a keyboard and with a screen reader. We do not have to test every page. We pick a sample that represents the site, the different page layouts, the kinds of content and controls those layouts hold, and the tasks a user needs to complete from start to finish, such as signing up for an account or making a purchase.
That manual pass gives us something the scan cannot give on its own. It tells us what the real problems are, how serious they are, and what it actually feels like to use the site. It catches the keyboard and screen reader issues that a scanner misses. And it gives us a baseline, a clear picture of where things stand.
Once we have that baseline, the scanning tool becomes much more useful. We point it at the same sample of pages and let it run on a regular schedule. Now the scan is not a mystery. We already know the real issues, so when the tool reports something, we have the context to judge it. Many of its findings will match what we found by hand. Some will be the minor or false items I mentioned earlier, and because we understand the site, we can set those aside quickly instead of chasing them.
Watching the Site Over Time
The bigger payoff comes over time. Running the same scan against the same pages on a schedule lets us watch the site as fixes are made. We can see whether things are improving. Once the work settles, the scan helps us hold that ground, and it gives an early warning if a change down the road introduces new problems. If a future update or a new widget causes a jump in issues, the regular scan helps point to when it happened, which makes it easier to track down what caused it. That is the role automated scanning is genuinely good at, and it is a different job than finding everything for the first time.
Where This Leaves Us, and What Comes Next
So far, everything I have described works on a known set of pages, the sample we chose to represent the site. That is the right place to start, and for a lot of teams it is plenty of work for a while. But it leaves an obvious gap. Most sites have far more content than any sample can cover, and a good deal of it is created by content authors long after the templates were built. A test sample will never represent all of that. This is where a different use of scanning comes in, letting the tool crawl through the whole site to find the unique content the sample misses. That is what I want to dig into in the next post.
If you would like to catch that one when it goes up, sign up for our mailing list so the next part lands in your inbox. And if you want to talk through your own situation in the meantime, 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 “Where Automated Scanning Fits in Your Accessibility Effort (Part 1: Getting Started)”