In this current era of digital innovation, making an application inclusive for the differently abled should be considered paramount. Global regulatory compliances for accessibility ensure that standards are followed when making applications accessible to one and all. Accessible applications obviously establish themselves firmly into the market and often have wider reach in comparison to an application that isn’t compliant.
JAWS, WAT, NVDA, etc. are some tools used to perform elaborate accessibility checks on applications that are looking to enter the market. However, many such tools are prohibitively expensive, making it challenging to gauge accessibility of applications.
As the world increasingly moves towards Agile, the global technology scenario mandates frequent and regular releases of applications. The challenge thus is to conduct elaborate and effective Regression before releasing applications on a continuous basis. Having a Functional Automation Suite, which is a collection of test cases that have been automated (typically regression test cases), will to a great extent alleviate the pressure on the QA team. But what about accessibility checks?
Accessibility testing doesn’t come cheap. It requires elaborate planning and availability of time. And time is often a sparse commodity for teams practicing continuous delivery (Agile). So what’s the solution then?
The solution is to automate accessibility tests. Section 508 of the American Federal Rehabilitation Act 1973 and European Union Web Content Accessibility Guidelines 2.0 are the primary compliances that are considered to implement this solution. Both these guidelines encompass a wide range of recommendations, a subset of which has been implemented as part of the automated accessibility library.
Most Computer Aided Software Testing (CAST) tools analyze the HTML DOM, discover elements and readout specific attributes to a differently enabled user. As mentioned earlier, testing this manually is a time-consuming and cumbersome activity. The proposed solution, which is the automation of accessibility, piggy backs on an existing Regression Suite and performs the DOM profiling almost silently. The current solution is JAVA based but can be very easily extended to other languages like .NET.
Advantages of the proposed Automation of Accessibility:
- This rides on an existing Regression Suite, thereby eliminating the need to design and maintain yet another automation framework.
- Every build/release can now be checked for Accessibility, thereby instilling confidence in the quality of the product and ensuring a certain level of compliance.
- It is an open source technology, hence carries no licensing obligations.
- Accessibility coverage is only as effective as the coverage provided by the underlying Regression Suite, although this is not a pure limitation of the solution.
- Changes in DOM hierarchies may demand some maintenance.
- The solution is only as accurate as the attribute values. If an attribute value is incorrectly mentioned as “foobar” (a nonsense word), the scripts will not report an anomaly.
Like functional test automation, the return on investment for Accessibility Automation is high, particularly for those applications under test (AUTs) where repetitive accessibility testing can be both time consuming and expensive. AUTs particularly mandated by Accessibility Compliances can gain a lot in the long run if a well-planned accessibility automation suite is laid in place. With a marginal increase in execution time, it will save an accessibility specialist’s effort, thereby enabling the specialist to focus on core/newer untestable (via automation) areas.