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.
When testing your app with VoiceOver or Switch Control, a common test is to ensure you can reach every interactive element on screen. If these assistive technologies can’t focus all of your buttons how will your customers be able to interact fully with your app? Except there are times when hiding buttons from your assistive technology users is the better choice. Consider an app with a table view that has many repeating interactive elements - this could be a social media app where ’like, share, reply’ etc is repeated for each post. Or perhaps an e-commerce app with ‘wishlist, buy now, add to basket’ are repeated for each item. Visually these buttons won’t interrupt your users skimming the list of content, but for VoiceOver or Switch Control users, they will have to visit each one for every item on the screen. This is going to make navigating your app long and tedious, an means your users are more likely to drop out.
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.