DEV Community

Cover image for Why auditing accessibility through crawling isn't efficient anymore
Cezary Tomczyk
Cezary Tomczyk

Posted on

Why auditing accessibility through crawling isn't efficient anymore

Almost all site developers and administrators struggle with maintaining adequate accessibility quality and being compliant with at least the WCAG 2.1 Level AA standard.

Note that I will focus here on automatic audits. Manual accessibility testing is an integral part of the entire audit, but here I will focus on accessibility automated solution.

The problem

When we think about automated testing, a typical approach is to enter your URL, and the app will crawl your site, following all links on the site. The fundamental problem with such testing is that accessibility testing is done without any user participation. Everything happens on a laboratory basis, on the server and under the conditions specified by the provider of the automated test solution.

However, let's examine the following limitations when crawling on the server side:

  • It adds extra work to process the reports from pages that users may not even visit or whose total visits aren't that significant.
  • Requires setting up the crawling rules (which pages, how deep, and many more).
  • Since the majority of vendors make use of the same audit tools, the audit findings will be quite similar or even the same. Additionally, they have no direct impact on how the audit tool is developed.
  • Scanning behind authentication requires complex solutions to handle different authentication flows.
  • In most cases, there is no way to customise crawl settings like viewport size, device user agent, browser type and version, etc. You have to stick to the fixed environment settings.
  • It's difficult to plan the remediation process as the results from scanning are "flat" and there is no information about how users are using those pages. Basically, you have a large list of pages with issues.
  • Monitoring requires a set of various options like scheduling cadence, frequency, limit pages, and scan level depth.
  • From a technological standpoint, every scan on the server requires a browser instance. Which roughly takes up to 1GB of RAM.
  • You can't crawl effectively with the Hybrid-Page Application type and Single-Page Application type. Hybrid Page Application is a mix of Multi-Page Application with dynamic changes on the page, e.g., the results in the table can be refreshed without reloading the page.

The solution

To resolve challenges created by crawling and auditing on the server side, the other and more efficient way is to audit sites on the client side.

Benefits:

  • Being embedded in the application, we can control dynamic changes and audit the website live. So, Hybrid-Page Application and Single-Page Application type will be fully supported.
  • The website audit can be sorted by the number of reports sent from the users, which will allow us to better plan the remediation process because we know which pages are visited most often.
  • You don't need to setup any specific crawling settings because all audits follow the user automatically.
  • Auditing behind authentication isn't an issue anymore because audits are embedded on your site.
  • You're working with a real user environment, which gives you a much better understanding of what's happening there.

Final words

Auditing on the client side has also presented challenges. One of them is performance. However, I believe that during the evolution of client-side auditing, challenges can be resolved over time.

Thoughts on that are very welcome.

Top comments (0)