Accessibility Automation

Undoubtedly as digital accessibility has garnered increased visibility, the need for a scalable and semi-automated means of testing for accessibility has become vital. Accessibility automation is the act of leveraging technology to audit user interfaces against a ruleset such as WCAG, Section 508, and other accessibility interface guidelines. With the data regarding violations, the automation engine can either generate a report or break a build process to prevent the publication of in-accessible code.

In web-based technologies, the automation engine usually works by sniffing HTML markup that exists in the document object model and also leveraging CSS properties to provide a visual smoke test. In a native app context, the automation engine often looks for defined accessibility properties that should exist on different object types. As a result, automation can help developers catch approximately 20% to 30% Opens in a new window of accessibility-related issues in their code.

In conclusion, performing accessibility automation against code does not mean that the feature or UI will be accessible. Accessibility automation will catch the low hanging fruits such as missing alt attributes, invalid markup, and broken aria references. In closing, automation will not be able to meet the level of detail that a manual audit will provide but will be a time-efficient starting point for building accessibility discipline and can be a powerful tool to use in parallel with manual testing efforts.

Any project that works on client-facing code in both a web and native app context can benefit from some degree of accessibility automation. A team with any level of testing maturity will be able to leverage accessibility automation within their projects. As a project evolves and develops a more sophisticated approach to testing, it will be able to continue to leverage accessibility automation where they see fit. Also, accessibility automation provides projects with a level of accessibility security from the publication of trivial accessibility issues. This is especially useful for teams that have a consistent wave of onboarding or have an open contributor model.

Accessibility automation sees the most benefit during the build process of projects. Due to early signaling in the build process, projects can protect themselves from the publication of in-accessible code by configurations such as a pre-commit hook or CI configurations as well. Accessibility automation can be utilized during active development in the browser, but most of those automation technologies give signaling by console outputs or secondary reports. This requires that developers proactively remediate issues. For example, axe-react, wave plugin, google accessibility scanner, Xcode accessibility inspector, and axe plugin can be executed externally, but cannot interface with a project's build to flag issues and fail builds.

Know that we know what accessibility automation is, who uses, and where it can be used, it's time to think of how we can leverage accessibility automation to establish an effective means of safeguarding our projects against accessibility issues.


* The materials outlined on this website are provided "AS IS" and are intended for illustrative purposes only. They should not be relied upon for marketing, legal, tax, financial, regulatory or other advice. You are responsible for the legal aspects of any implementation of the concepts illustrated herein. Further, Expedia, Inc. neither makes any warranty or representation as to the completeness or accuracy of this information, nor assumes any liability or responsibility that may result from reliance on such information. You should not act or rely on such content without seeking the advice of a professional. All brand names, logos and/or trademarks are the property of their respective owners, are used for identification purposes only, and do not necessarily imply product endorsement or affiliation with Expedia, Inc.