Quick Win - Start UI Testing
I’ll admit, adding UI testing to an app that currently doesn’t have it included is probably stretching the definition of quick win, but the aim here isn’t 100% coverage - not right away anyway. Start small and add to your test suite as you gain confidence. Even a small suite of crucial happy-path UI tests will help to ensure and persist accessibility in your app. And the more you get comfortable with UI tests the more accessible your apps will become, because an app that is easy to test is also great for accessibility.
XCUI tests are great for accessibility because thats exactly what they’re testing. The tests need something machine-readable to understand what is present on screen - something else that needs something machine-readable to understand the screen is assistive technologies. So XCUI reads the accessibility tree, the hierarchy of metadata and labels that represent to assistive technology what is on screen. This means the easier your app is to UI test, the more robust the accessibility experience is. In short - any XCUI test is an accessibility test.
Paul Hudson provides this great tutorial on getting started with testing your user interface and a cheat sheet for when you want to go a little further. There are a couple of caveats for ensuring your tests are checking accessibility - reference elements by their label wherever possible. Referencing by index or identifier can make finding elements on screen easier, but be sure to check the element’s label once you’ve found it.
Android’s Espresso testing framework from Google has a Google provided extension to add accessibility checks to your existing UI tests. Once you have written an espresso test, import
androidx.test.espresso.accessibility.AccessibilityChecks and call
AccessibilityChecks.enable() at the start of your test. As your test runs espresso will automatically check the accessibility of your app and report what it finds with no extra work needed from you.