Make Your Application Accessible with Accerciser

You might think you need to be familiar with assistive technologies like the Orca screen reader to determine whether your application is accessible. The truth is that with just a couple simple rules and an open-source tool called Accerciser, the task at hand is fairly simple.

Before you start diagnosing your application with specialized tools like Accerciser, you should ask yourself a few straightforward questions about your application.

1) Does my application's functionality depend on colors, icons or audible feedback?

Sometimes an application uses a certain color, graphical icon or sound as an indicator of its status or as a notification for users. A simple example is a battery-status panel applet; the applet warns users that their laptop battery is low by changing the battery icon from green to red. Of course, if users are blind, neither the green nor the red icon will be helpful if a textual description is not provided. Color-blind users also will be unable to decrypt such a status indicator. As another example, a calendar application may have an audible alert with no visual indication when an appointment time is approaching. This, of course, would be a useless feature to people who are hard of hearing, or even to those who simply have their audio muted.

Such applications should offer alternative means of access to their features. Maybe a tooltip or label for the CPU monitor? Maybe an optional alert pop-up for the calendar program? These kinds of changes might not always be the perfect and most elegant solution, but remember, the line separating accessibility from usability is blurry and often nonexistent. The colored dot on the CPU monitor might look nice by itself, but give users options as to how they can use your application.

2) Can users adjust the font size and interface color scheme in my application?

If your application utilizes a standard widget library like GTK+, the answer to the question above is yes. GTK+ is fully themeable. In fact, most Linux distributions provide a set of large-print and high-contrast themes to enable greater accessibility.

The question above should be examined seriously by ambitious developers who create a custom widget that is not provided by the toolkit. A good way to test a new widget is by applying an inverted high-contrast widget theme. Does the interface show up well? Is it conforming to the user-set widget theme?

Just like themes, most modern desktop environments provide a central place where the default font style and size can be defined. If your application is rendering text through the standard code path, chances are high that the font style and size the user defined globally will be applied to your application. But, what if your application explicitly defines font style and size? Or, maybe your application does specialized text rendering? In these cases, it is important to give the option for tweaking the font in your application.

3) Can my application be used without a pointer device?

Many conditions inhibit the use of pointer devices, for example, muscle weakness, hand tremors, involuntary movement or difficulty in seeing the mouse pointer on the screen due to visual impairment. For these reasons, it is important to enable nonpointer interaction with your application's features. This, of course, is easy to test. Disconnect your mouse and hide it where you won't find it. Use your application to ensure that you could reach and use all of your program's functionality. This also is a good time to think about useful keyboard shortcuts and mnemonics. Users will thank you when you make certain functions easy to reach without strenuous interface navigation.

4) Does the focus order in my application make sense?

Because you can't assume that users will be using a mouse, tabbing focus order should be considered. Remember the last time you bought something on-line? Most users fill out the order form by tabbing to the fields and typing: first name, tab, last name, tab, street address, tab and so forth. Wouldn't it be aggravating if, after you tabbed out of the name field, the Submit button got focus? Although sighted users might find this to be an inconvenience, screen-reader users will get a larger dose of confusion, because the work flow, when using a screen reader, is dictated by the focus order.

The visual appearance of your application does not need to change in order for it to have a good tabbing order. GTK+'s API has functions for defining the focus order of a parent widget's children.

After you have asked yourself all of the above questions and provided satisfactory answers, it's time to see whether your application provides the proper instrumentation to assistive technologies, such as Orca. The functionality and state of your application are provided to the assistive technology through a CORBA-based framework called AT-SPI (Assistive Technology Service Provider Interface). From your application's side, the communication with assistive technologies is done with a library called ATK (Accessibility Toolkit), which allows you to create Accessible objects that are synonymous with your graphical widgets.

In most instances, when you use GTK+, the accessibility internals should not concern you, because GTK+ has a module called GAIL (GNOME Accessibility Implementation Library) that does most of the heavy lifting for you. GAIL takes all of GTK+'s stock widgets and provides proper Accessible objects for them using ATK.

Figure 1. Desktop Accessibility Components