So you want to make your application accessible, but constantly turning on Voiceover and checking through your application to see if it is set up right is getting annoying. What you really need are some tools to help you look at and check your application’s accessibility and tell you where you are going wrong. Luckily Apple provides two such tools and in this article I’m going to give you a brief overview of them both.

Accessibility Verifier

The first tool is Accessibility Verifier. As you can probably gather from the name, it verifies the accessibility of your application. It points out 4 types of issues. The first of these is Parent/Child issues. These make sure that the parent and child both agree they are related to each other and in most cases rarely show up. The next is checking for Window issues, finding any UI elements that are within a window and making sure that their window attributes are set to the correct window.

The next two are the more common issues. The first checks for missing descriptions or titles on UI elements. If you have just created a new UI you will likely get a lot of these, but they are an easy enough fix in Interface Builder (see my last article for details). Lastly we have Role Verification. This is making sure that the accessibility role for an item matches the role it should have eg that a text field isn’t seen as an AXButton.

Unfortunately Role Verification is a bit buggy in Leopard. It does point out some real problems but it also outputs errors for things that are perfectly fine. For example, if you add a table view to your UI, it will incorrectly claim that each column header’s role description should be AXSortButton. Apple is aware of this but, but whether it has been fixed in Snow Leopard or not we won’t know until it is released.

So how do you use Accessibility Verifier? Well the first thing is to launch your application. Once it is open, make sure the windows you want to test are visible. Then choose your app from the drop down menu on the left and hit Verify. This will run all the tests on your application. Selecting an error or warning will show the details of that UI element in the bottom half of the window. You can also what is shown and what tests are run by changing the report level.

Accessibility Inspector

While Accessibility Verifier points out what problems are, Accessibility Inspector can give you detailed information about the accessibility hierarchy in your app which is great for debugging, or if you are just curious. It is a small panel that sits in front of everything on your screen and gives full accessibility information about what is under the mouse cursor.

But while this is useful for general viewing, there is another side to Accessibility Inspector. Hit Command-F7 and it locks focus on the current UI element in its view. This brings up another panel that lets you view and manipulate this UI element. Some UI elements have editable accessibility attributes that you can modify from this pop up. You can also perform any accessibility actions this UI element has from this window.

But of course none of this is the most interesting part of Accessibility Inspector. What makes it really interesting is that it is open source, albeit an older version. This makes it an idea place to start studying the accessibility APIs available in OS X by seeing how Apple does the things they do with Accessibility Inspector. The source is available from Apple’s developer site as UIElementInspector.

Martin Pilkington is the person behind M Cubed Software, the creators of Minim, Lighthouse Keeper and Code Collector Pro. When he isn’t developing software he is being musical or studying for his degree. Martin’s interest in accessibility came about after taking a brief glance at Apple’s documentation one evening and realising how much can be done to improve applications with only a little work. Since then he has started a push to make the Mac the most accessible platform.