Webinar Video | Automated Scanning vs. Manual Auditing

Today, we’re gonna be talking about the differences between automated scanning and manual auditing when it comes to looking for WCAG failures. This is a brief five to 10 minute presentation, and as Gianna said, afterwards, we’re going to have time for questions, and also just open ended questions, whether or not related to this presentation. So some things to keep in mind before we get started, both automated scanning and manual auditing are valuable in their own ways. Automated scans are oftentimes a good starting place and are a good way to monitor changes to content over time, and manual auditing helps improve the site’s overall accessibility by a much larger margin. Automated scanning can only catch 20 to 25% of WCAG failures at this point in time per page, and the remaining 75 to 80% can only be identified through manual auditing. And the third thing to keep in mind is remediation work takes time. There are ways to make the process more efficient, but there aren’t any tools that can automatically identify all issues and or make the fixes entirely on their own. Maybe they’re one day in the future, but it doesn’t exist currently. All right.

So what is automated scanning? An automated scanner consists of rules, which are essentially statements centered around accessibility that can be automatically measured as yes or no. These rules are then tested against the code of an app or website.

How can it help? Scanner results are a solid first step towards being accessible. Fixing the issues identified will improve your product’s accessibility while also reducing the chances of being flagged for being inaccessible. Unfortunately, many instances where lawsuits around accessibility occur start from someone just running scans on a website in hopes of finding issues, even if they themselves are not affected directly by themselves.

And then lastly, automated scanning is a great method for identifying changes in content that occur. If new issues are identified in scanning, you can make those fixes, but it’s also a good way to flag to come back to those components that had issues or manual work in the future.

Alrighty. Next up is what is manual auditing? So manual auditing consists of a real person reviewing the code and interacting with the content itself to ensure that the information that is being presented is available in an accessible manner. Here at accessible web, we do over 100 tests on each component covering all content on each screen of a given product when doing our manual audit. How can that help? People can manually find all the issues that automated scanning cannot currently detect, so that remaining 80% roughly, and then an analysis based on what the content is presenting is given alongside information for how it should be communicated, in the form of remediation test. So instead of just getting some automated thing about like, “Hey, this is broken”. It’s like, “hey, this component specifically needs these changes to be accessible.”

All right, so some benefits and some caveats to both. So the benefits of automated scanning include that it’s fast and it’s easy to set up, and it can be used to monitor your site for the long term, versus manual auditing, which is typically a one and done. You have to revisit it in the future. The benefits of manual auditing include that the context of the content and what is supposed to be communicated is understood by the auditor, which currently isn’t understood by scanning, and issues will be caught that go undetected by scanning. So some caveats automated scanning include that scanning this is a majority of accessibility failures as we covered, the recommendations provided are generic and not fine tuned to the content associated with the issues. And then some caveats to manual auditing is that it’s a much longer process than scanning. Scanning takes matter of minutes and auditing takes hours per page. And manual auditing often does cost quite a bit more than scanning. Ben Turner 5:10 Last note here is going over some common misconceptions. First one is, I fixed all of the issues identified by scanning, so now my content is accessible, as previously noted, automated scanning can only catch about a quarter of the issues related to the WCAG, the Web Content Accessibility Guidelines for those who don’t know, sort of the industry and law related standard. Manual auditing is required to ensure your content is accessible. So you can start with scanning, but to ensure that to be able to make the claim that you have accessible content, you’re going to need manual auditing happen. The next one is, I can’t get a manual audit, so accessibility should be a low priority of mine, even if you can’t get a manual audit. Now, whether it be for financial or staffing related reasons, you should still take steps towards being more accessible. Automatic scanning, automated scanning, researching and learning are all great places to start. But even if you can’t get that manual audit, taking some baby steps in the right direction is huge. Then the third misconception I have noted here is I don’t need another audit. I already had one, and I made the fixes. In most cases, manual audits should be performed every one to two years. This is due to changes in government and or client base requirements updates to the WCAG. So there’s different versions that come out over time to make content more and more accessible and make sure that things are not missed as often. And then the last thing is most likely, you’re going to be pushing new content over time. So when that new content comes out, it’s really hard to guarantee that it’s perfectly accessible without becoming a manual audit.

All right, so how accessible web can help here. We have accessibility software which includes ramp, our extension for manual auditing, contrast checker, and so on. So we have a full suite of tools that can help out and right now presenting a code on the screen. It’s awebinar1, and that’ll get you one month of RAMP for free. Second note is accessibility audits, as we were talking about manual audits. We do offer those here at accessible web. So feel free to follow up to me or anyone else on the call if you are interested in having one. Another thing we offer here is consulting and training. So we do have Academy courses, plus one on one sessions with members from our team. And lastly, post getting an audit, we can create a Voluntary Product Accessibility Template, VPAT for short. This is typically the things that we see our clients need to be able to work with some of their clients, because a lot of the places are now finally joining the push for making things accessible, and VPAT is a good indicator as to what level of performance.

That’s it for the presentation, I’m going to open up the floor to some.