Accessibility traits on iOS is the system by which assistive technologies know how to present your interface to your users. The exact experience will vary between assistive technologies, in some cases they may change the intonation of what VoiceOver reads, or add additional options for navigation, sometimes they will disable that assistive technology from accessing the element, or change how the assistive tech functions. They are the ‘Role’ part of the fundamental rule of making something accessible to screen readers - WCAG’s 4.1.2: Name, Role, Value.
Disclosure: Evinced has paid for my time in writing this blog, and I have provided them feedback on the version of their tool reviewed and an early beta. I agreed to this because I believe in the product they are offering.
Testing your app for accessibility is an essential part of making an accessible app, as with any part of the software you build, if you don’t test it, how can you be sure it works? Because accessibility is human, there are no true shortcuts to this, a through manual test will always be the most productive form of accessibility testing possible. But with some carefully designed automated checks, you can detect common accessibility issues quicker and earlier. This makes fixing them easier, the chance of these errors reaching your customers is reduced, and it saves you valuable time for resolving more complex issues. It’s not an easy problem to solve - I’ve tried with A11yUITests, and Apple built their offering, Accessibility Inspector, right in to Xcode. Now a new tool has entered the arena from Evinced, the iOS Accessibility Debugger.
This is a common question I get asked - how do I go about arranging an accessibility audit for my app so I know where I can make improvements? If you’re truly looking for an answer to that question then I have a few options for you below, but first, are you asking the right question?
Accessibility Isn’t About Box Ticking # You can’t make your app accessible by getting a report, fixing the findings, and accepting it as done. Accessibility is a constant process of improvement to make sure your app works better for as many people as possible. This could mean adopting new accessibility APIs as they become available, or it could mean reacting to feedback you receive from your users. Disability happens when someone’s abilities don’t mesh with the tools we have provided, and as disability is such a wide spectrum there will always be someone disabled by your app. How that manifests will vary depending on your app, the people using it, and over time, so one assessors report is not enough to claim your app is 100% accessible, because there is no such thing. To claim this is both naive and a little offensive.
A few months ago I shared a project I’d been working on for iOS exploring the accessibility API available on that platform. The Android accessibility API is equally large and full featured, and really deserves the same treatment. So here’s A11y Box for Android.
A11y Box for Android is an exploration of what is available on the Android accessibility api and how you can make use of it in your apps. It’s open source, and open for contributions. So please feel free to fork if there’s a feature I’ve missed or something that needs a little clarification.
iOS’ UIAccessibility API is huge. I like to think I know it pretty well, but I’m always being surprised by discovering features I previously had no idea about. Like many things on iOS, the documentation for UIAccessibility is not always complete, even for parts of the API that have been around for years.
In an attempt to help spread the knowledge of some of the awesome things UIAccessibility is capable of, I’ve created A11y Box for iOS. It’s an open source project that covers every feature I know about on the UIAccessibility API, and a little more too.
A11yUITests is an extension to XCTestCase that adds tests for common accessibility issues that can be run as part of an XCUITest suite. I’ve written a detailed discussion of the tests available if you’re interested in changing/implementing these tests yourself. Alternatively, follow this quick start guide.
Getting Started # Adding A11yUITests # I’m assuming you’re already familiar with cocoapods, if not, cocoapods.org has a good introduction. There is one minor difference here compared to most cocoapods, we’re not including this pod in our app, but our app’s test bundle. This means your podfile will look something like this.
This is a personally curated list of resources I have used and think others may find helpful too. I’m always looking for new high quality mobile accessibility and inclusion resources to add here. Please share any you find with me via email or Twitter.
Code # Android # Android Developers: Build more accessible apps Android’s developer documentation for Accessibility, including design, building & testing. With videos, code samples, and documentation.