Continuous Accessibility: What, Why, How

Senior engineer and accessibility advocate Melanie Sumner is arguably the leading proponent of a concept called Continuous Accessibility. She’s given talks at EmberConf and GitHub Universe on the concept and built ContinuousAccessibility.com, a website that describes her vision for a future where accessibility teams—in her words—have greater confidence in the quality of their code, more easily deliver accessible experiences at scale, and reduce risk of legal liability for their companies.

In Melanie’s conference talks, she makes the case for applying the following principles of continuous software engineering to the problem of web accessibility:

• Build quality in
• Work in small batches
• Let computers perform repetitive tasks so people can solve hard problems
• Relentlessly pursue improvement
• Everyone is responsible

Assistiv Labs was founded by engineers. As such, we are 100% on board with Melanie’s vision of providing continuous insight into the accessibility health of web-based software.

Continuous Accessibility is defined as the approach to ensuring that code intended to be displayed in browsers can be continuously checked and monitored for digital accessibility requirements through a novel application of existing software engineering concepts and Web Content Accessibility Guidelines (WCAG).

ContinuousAccessibility.com

The role of linters in Continuous Accessibility

Melanie does a great job in her talks of outlining how code analysis tools (e.g., linters) can give insight into the accessibility health of web products.

As an example, linters excel at finding problems such as images with missing “alt” (short for alternative text) attributes. It’s trivial for software to tell the difference between the following:

• <img src="my-cool-image.png">
• <img src="my-cool-image.png" alt="">

The output of linters can be tracked over time, potentially surfaced on company dashboards, to give a sense of whether a product is improving or getting worse with respect to accessibility.

Alternative text on an image is a relatively simple example, but it’s a good illustration also of the limitations of static code analysis. Turns out it’s actually hard for software to tell which of the following is a better experience for the user because so much depends on the context:

• <img src="my-cool-image.png" alt="">
• <img src="my-cool-image.png" alt="My cool image">

Is the image decorative? If not, does the alt text effectively communicate the right information?

Suffice to say, we agree with Melanie that it’s essential to include Continuous Accessibility (CA) tools alongside Continuous Integration (CI) and Continuous Deployment (CD) systems. Enabling CA within our build pipelines allows us to catch errors before they have a chance to negatively impact the accessibility of our products for users.

Importantly, the opportunity to do so is there because many software developers already integrate tools into deployment workflows such as those enabled by GitHub Actions and GitLab CI/CD that check for everything from code formatting to performance metrics to end-to-end functionality.

Related to accessibility in particular, the following are some of the more commonly used existing tools developers integrate into CI/CD:

• ESLint, via plugins such as eslint-plugin-jsx-a11y
• axe-core
• Google Lighthouse
• ARC Toolkit
• WAVE
• IBM Equal Access (IBM EAAC)
• Evinced

The listed tools are all great. We recommend you use them! But, we also think that they only get us part way to true CA. Why? Because their ability to ensure conformance to WCAG is limited. So much so that Melanie built a whole site that tracks which failure scenarios are currently able to be validated using automation and which aren’t.

In fact, it’s possible to fool most of the tools in the preceding list and build a completely inaccessible site that passes their tests. Yikes. 😬

To be fair, CA is never going to be achieved by any single tool. It takes a village (of both humans 💪 and machines 🦾) to make a product accessible!

To sum up, we believe there is a ton of untapped potential to increase the scope of what is tested in an automated way by the machines. Linting is helpful, but not sufficient for achieving the ideals of CA.

Our vision for Continuous Accessibility

At Assistiv Labs, we envision a future where great tools are available at all stages of the SDLC to enable companies to build great experiences for users of assistive technologies.

Our goal in the near term is to invent a new class of tools to help developers create accessible experiences for end users. To that end, Continuous Accessibility is our organizing principle. As software engineers ourselves, we think systems that give near-instant insight at the code change level—with broad coverage of WCAG guidelines—will go a long way towards providing the kind of feedback developers need in order to ship highly accessible products as the default.

We built our End-to-End Accessibility Testing service to answer Melanie’s prompt for the “novel application of existing software engineering concepts” to the problem of CA, in particular her call to “let computers perform repetitive tasks so people can solve hard problems.” Read more about how it works in How End-to-End Testing moves us closer to Continuous Accessibility.