Shift-left strategy is one of the critical components of accessible software development. It allows teams to detect possible standards violations at the very beginning of a project launch, and eliminate them by choosing the appropriate technology stack, validating UI/UX design, and choosing the proper accessible techniques for the development team.
If a software development team uses accessible techniques, any shift-left in testing by automated tools and plugins can provide significant beneficial results. This kind of testing is the foundation of the shift-left approach in software development that relies on principles of early testing, the effective gathering of product requirements, and preventing critical bottlenecks.
Our colleagues share their insights about building an effective development process with a shift-left strategy in mind. They also share their tips for creating an accessible product, options for automated code verification, and some handy automated testing tools that our Accessibility Support team uses daily.
Let’s get started!
In the case of accessible product development, engaging only the QA Team at earlier stages of software development won't offer efficient results. The shift-left approach involves engaging the accessibility specialists at early development stages to clarify the accessibility requirements for all Teams, including the QA Team that will be conducting testing later following these specific requirements.
The key aspects of shift-left testing include the detection of bugs at early development stages, continuous testing best practices, and the automation of processes that will speed up product time-to-market. The shift-left approach perfectly suits the DevOps philosophy that encourages automation, continuous automation, and continuous deployment practices.
Now let’s see how the shift-to-the-left paradigm correlates with accessible product development.
Several major compliance standards define the operating systems, browsers, and assistive technologies that a software product must support:
Other accessibility standards are used locally and may be a part of product requirements. Overall, the WCAG is one of the most popular standards applied in the development of accessible websites and mobile apps.
To avoid WCAG violations as early as possible and reduce the number of issues you have to deal with at the QA stage, you’ll need to incorporate accessibility at every stage of the development cycle.
First, almost half of the 50 WCAG 2.1 level AA SC can fail at the design and prototyping stage. On average, it takes three times more effort to fix accessibility issues like technical debt if accessibility requirements are not part of the initial product design, including stories’ technical descriptions. Fixing this technical debt may include changes in product design and business logic which may trigger the rebuilding of considerable parts of the project. Existing automation tools checking for accessibility compliance catch no more than 30% of the issues, which doesn't guarantee your product’s compliance. An accessible product needs strict and thoughtful accessibility specifications or requirements in the same way as it needs business requirements. The product’s UI/UX has to comply with the standard, and developers should follow the accessible design patterns outlined in the specifications. You can't neglect manual testing with actual assistive technologies like screen readers. At the end of product development, fill in the VPAT (Voluntary Product Accessibility Template) that states the level of accessibility support and notes any exceptions, some of which may have been made at the client’s specific request.
The typical accessible development cycle includes the following stages:
Automated code checks can be a part of your shift-left approach. For example, we recommend the axe-core engine (jest-axe plugin for jest).
Unfortunately, there are only a few rules for accessibility feature verification in existing linters and plugins. For example, Stylelint has only three rules, Eslint for the web has 34, and React Native has 13 rules. The actual number of accessible techniques and examples published on the w3.org website, however, is more than 500. As a result, existing linters and plugins can not be expected to provide a sufficient level of code compliance to the standard.
Accessibility linting and unit testing with existing tools are effective when:
Remember, even if you use these tools properly, they will help catch, at most, 30% of the problematic issues.
On the other hand, these tools will return zero issues found (meaning that they are not useful at all) if:
Like functional testing, accessibility testing can be performed automatically and manually. Roughly 30% of total accessibility requirements can be tested automatically. Partial automated accessibility testing includes things like HTML and CSS mark-up; correctness of the added ARIA roles and attributes; color contrast in case the colors can be determined within the code and are not implemented as gradients; text resizing; and the page structure. Automated accessibility tests are an essential part of a shift-left strategy. They help you catch a great deal of easily preventable errors and unintended mistakes.
Most of the automated tools can be divided into three groups: Browser plug-ins, Online tools, and bookmarklets.
Browser plug-ins work as extensions for checking the web page directly within the browser. They include:
The next group is online tools. As a rule, they represent websites where you can enter the web address to get it checked. Here's a list of popular online automation tools:
Some automated tools require a vast knowledge of accessibility or code, others provide more simplified explanations. All of them are subject to false positive and false negative results, which means that their outputs must be reviewed manually. The best one to choose depends on the product and personal preferences.
"I am a huge fan of bookmarklets, and I have dozens of them bookmarked for every possible occasion. Some provide visualizations of accessibility features of web pages like landmarks, images, links, and form controls; others highlight roles, states, and properties of elements on the page. In addition, there are tools that change the appearance of a page showing it in text-only or in a grayscale mode. You should remember, however, that almost all bookmarklets are experimental products and may give faulty results."
Unfortunately, bookmarklets or browser extensions aren't a silver bullet to building a robust software product. There are limitations to keep in mind when using automated testing tools. One issue is that there are various ways to implement elements. For example, if an interactive element is created using a non-semantic element like <div> without proper attributes, there's no way for that to be detected automatically. Also, automated testing can't be applied when you need to test the following elements and cases:
Our EPAM team has been building expertise in accessibility development for a while. As a result, we've developed our own accessibility testing automated platform (ATAP) that helps us speed up the process of checking web content for accessibility, and reduce the need for manual efforts. The platform's concept also matches a shift-left DevOps paradigm that strives for maximum automation.
Here are the key features of EPAM’s ATAP platform:
Machine learning evangelist Andrew Ng states that if an average person can perform a mental task with less than one second of thought, we can probably automate it using AI either now or in the near future. Inspired by this idea and thousands of proofs of this rule in other areas, we decided to test whether we can automate more accessibility checks than typical solutions do now. It turned out that it was possible to do so.
We managed to automate new checks for situations in which it is difficult to formalize technical requirements and solve them in a classical programming way based on defined rules. To make a product valuable as a test automation tool, it wasn't enough to increase the coverage of accessibility checks alone.
As a result, we added extra functionality and integrated axe-core tests to perform the basic checks, a web interface with an automatic generator of Audit and VPAT reports, and editable versions to provide a comprehensive analysis of conformance to accessibility standards. To detect accessibility issues as early as possible in the process, we enabled the integration of the accessibility testing into existing CI/CD pipelines. Finally, we automated the creation of accessibility issues in bug tracking systems, such as Jira.
In addition to the Deque Axe-core accessibility engine integrated into the product, we designed and implemented about 70 tests. 30 tests are capable of checking the interactive elements in addition to static code analysis, while a dozen tests use machine learning models. Most of the tests we designed are related to NLP.