Make Your Application Accessible with Accerciser

Accerciser gives a top-down view of what your application is providing regarding assistive technologies. It does this by tapping in to the same interface that an assistive technology would use, AT-SPI. Accerciser fits the needs of many different audiences. It is a tool used by assistive technology developers to see what AT-SPI is providing their applications, and it is used by automated UI test developers by exposing the different methods and events that could be expected from their target application when they author test scripts. And, in our case, it allows user interface developers to ensure that their application is providing all of its functionality through AT-SPI. In short, it allows us to exercise the accessibility of our application.

You can obtain Accerciser by downloading it from Accerciser's Web site, or check your distribution to see if it is already packaged.

Figure 2. Accerciser's Main Window

Accerciser consists of a fairly small core. Most of Accerciser's features are in its bundled plugins. Accerciser's main window has three major areas: a tree view of the entire desktop accessible hierarchy as exposed by AT-SPI's registry, and two tabbed plugin areas. Accerciser's plugins can be toggled and rearranged simply by dragging the plugin tabs: drag a tab to another plugin area to move the plugin to that view, or drag the tab over the desktop to create a new window with a plugin view in it.

An easy way of diagnosing our application is with the Interface Viewer plugin. Accessible objects could expose a wide range of functionality by providing more than one interface type simultaneously.

The interface viewer plugin allows users to explore the functions a selected Accessible object provides. We use this plugin below to examine a fictional application.

So far, it seems that we get everything we need for our application's accessibility for free just by choosing GTK+, right? We have theme compliance, we have keyboard navigation, we even have AT-SPI support. So, where could we be falling short of full accessibility?

First, let's create a fantasy application called Limelite. Limelite is a simple song-playing program with one killer feature: by pressing a toggle button in the GUI, the vocals are magically removed from the sound output, and the user, for a few minutes, could be a rock star.

Limelite's main window is divided in two. The top shows data about the currently playing song, and the bottom has common media controls (play, pause, next and so on) and a toggle button that enables or disables karaoke mode.

Figure 3. Limelite Screenshot

To examine Limelite through Accerciser, all we need to do is run both programs. Limelite's top accessible node will appear in Accerciser's tree view. As we traverse down through this node's descendants and select child nodes, we will get a flashing rectangle around the equivalent widget of the selected accessible node. When a node is selected, the plugins will update and show information about the currently selected Accessible object.

When you spend time designing an application's interface in a visual manner, issues like proper labeling often are overlooked. We use Accerciser to find such instances quickly.

Accerciser comes with a plugin called Quick Select. Put the pointer over the widget you want to examine, say the Play button, and press Ctrl-Alt-/, the button is highlighted, and Accerciser's tree view shows the Play push button as selected. Because the Accessible's name is Play, we can be certain that an assistive technology will not have trouble conveying the function of that button.

Limelite's multimedia keys are all GTK+ “stock” labels. Stock labels are a pool of commonly used labels that GTK+ provides. It is always a good idea to use these labels when possible, as they will provide a localized string and a themeable icon in most cases. For this reason, stock labels usually are safe from an accessibility standpoint.

The one key that should concern us here is the karaoke toggle mode button. This button contains nothing but a microphone graphic. If you select it in Accerciser, you will notice there is no string representation present. A good place to double-check is in the Interface Viewer, under the Accessible section. Here, you can see there is no description for the Accessible either.

This situation easily can be ratified by directly naming the Accessible object through ATK's atk_object_set_name() function. If your UI is defined with Glade or GtkBuilder, you should be able to set the Accessible's object name in the Accessibility tab.

Figure 4. Glade-3's Accessibility Tab

Of course, the above solution will not make your interface any more clear to a user without an assistive technology. A tooltip would be a good choice in this case, both for general usability and accessibility. When a tooltip is set for a widget, GAIL automatically uses the tooltip's text as the Accessible object's description string. Assistive technologies could utilize this description string.