Accessibility is a critical software quality affecting more than 15% of the world’s population with some form of disabilities. Modern mobile platforms, i.e., iOS and Android, provide guidelines and testing tools for developers to assess the accessibility of their apps. The main focus of the testing tools is on examining a particular screen’s compliance with some predefined rules derived from accessibility guidelines. Unfortunately, these tools cannot detect accessibility issues that manifest themselves in interactions with apps using assistive services, e.g., screen readers. A few recent studies have proposed assistive-service driven testing; however, they require manually constructed inputs from developers to evaluate a specific screen or presume availability of UI test cases. In this work, we propose an automated accessibility crawler for mobile apps, Groundhog, that explores an app with the purpose of finding accessibility issues without any manual effort from developers. Groundhog assesses the functionality of UI elements in an app with and without assistive services and pinpoints accessibility issues with an intuitive video of how to replicate them. Our experiments show Groundhog is highly effective in detecting accessibility barriers that existing techniques cannot discover. Powered by Groundhog, we conducted an empirical study on a large set of real-world apps and found new classes of critical accessibility issues that should be the focus of future work in this area.
Groundhog utilizes an App Crawler to explore different states of the app.After each change in the app,App Crawler invokes the Snapshot Manager to capture a VM snapshot if the current state (screen) has not already been seen.Snapshot Manager provides the VMSnapshots to Action Extractor,where all the possible actions on the given state of the are sequently extracted.Groundhog then tries to locate the elements and perform these actions on them using three different proxies: TouchProxy, TalkBackProxy, and AbstractProxy. Finally, the new state of the app after performing the action is provided to the Oracle along with the initial app state. Oracle assesses if each proxy successfully performs the action and produces the final report.
The artifacts are publicly available here.