In last week’s video, I forecasted that I would wrap-up the three-part series on Android Accessibility APIs and build my own version of how to properly make a layout accessibility focusable. However, I have been traveling to accessibility camps and have not had the time to code this example. So instead, this week I will answer a question I had seen come up in my previous webinar on Native iOS Accessibility: how to test with the iOS Accessibility Inspector. This tool is great because it comes with your iOS toolchain and will test for VoiceOver, switch controls, braille boards, and other alternative input devices. But we’ll get into more of that below.
Follow along here in my recorded walkthrough if you’d like:
Testing Accessibility in iOS Simulator with the iOS Accessibility Inspector
One of the things that is frustrating about the iOS environment is how difficult it is to test on a device. Primarily, it is difficult to keep devices set up, manage your profiles, and your development stuff. On top of that, you never know when the toolchain’s going to break, and if it does your team agent has to go in and accept some new, updated agreement. Then you’ll have to wait for and an unknown amount of time until you can test on a device again. It’s very frustrating.
For this reason, testing in the simulator is very useful. However, when you’re testing in the simulator you do not have access to VoiceOver or the other assistive technologies on the device. Instead of using VoiceOver in the simulator, you can explore the accessibility of an app using the Accessibility Inspector. The Accessibility Inspector is not only to helpful for making an app more accessible VoiceOver applications, but it helps you explore all of the accessibility properties that are available for other assistive technologies. You can also explore switch control, braille boards, and alternative input devices.
Moreover, in the Accessibility Inspector, you can see all of the properties at once, whereas VoiceOver only can view about a subset of those properties. This is going to help you explore all of that information in one place while being a more valuable tool for developers than VoiceOver. This isn’t to say that you should always test with Accessibility Inspector as a part of your toolchain, but instead use VoiceOver at the end of that process and use the Accessibility Inspector throughout that process.
Using the Accessibility Inspector to Drive the UI in Simulator
To start the Accessibility Inspector follow the simple steps below:
- Bring up Xcode.
- Navigate to the Open Developer Tool and start the Accessibility Inspector.
- Bring up the simulator running with the application you would like to inspect.
The Accessibility Inspector can connect to a lot of different processes. The example above connects to your iOS simulator, and when you connect it, you can run it in against your MacBook Pro. Be sure to note that you’re going to get different types of feedback as the simulator treats these objects as desktop objects. The Accessibility Inspector can also be valuable if you’re a desktop application developer as the inspector also allows you to drive the UI like it does with VoiceOver. While navigating with the inspector you can click by clicking on things twice. If you want to activate a tab with the Accessibility Inspector click on it once.
Navigating an Application with Accessibility Inspector
When the Accessibility Inspector is in targeting mode, it is going to focus the same thing that VoiceOver focuses. As you cruise you mouse over controls it will be just like you were interacting with VoiceOver on a device. You’re going to get the same navigation as you’re going to in VoiceOver. When you select a target you will be able to see the labels such as traits and links. From there you will be able to identify and detect the accessibility violations in an application.
Another cool feature of the Accessibility Inspector is that it has the ability to run audits. We can do automated accessibility analysis on any page we want. It will help you identify a lot of problems, but it important to note that many of these announcements will be false positives. Take the violations that you see with a grain of salt and manually confirm the violations are actual issues.
In summary, this inspector is really useful because you can personally navigate and see the accessibility properties of the controls and see the behavior in action. One of the tools that Deque is developing is an automated tool for mobile that can run audits that do not produce false positives. Be sure to check out a demo of that here.