Introduction

When writing a GTK+ application, think about the fact that users with varying abilities will want to use the application. Some users with mobility impairments cannot use their hands for traditional mouse and keyboard input; other users who are blind may not be able to use a mouse, see the screen, or read a printed User's Guide.

Over the years, disabled users and Assistive Technology Vendors (ATVs) have invented incredibly clever work-arounds for these problems. Voice input replaced the mouse, mouth sticks and switches replaced the keyboard, text-to-speech synthesis replaced the screen, and online books replaced printed books.

Some products include unintentional roadblocks to people who have disabilities. Some examples:

• Programs that provide mouse only input are inaccessible for use by people who are blind or who have mobility impairments and require alternative inputs, such as input using voice recognition. In addition, programs with mouse only input may not be adaptable to devices which do not have a mouse.
• Programs that use audio-only messages (individuals who are deaf cannot hear the messages - this also applies to people with systems that do not have sound capability).
• Operating systems that define Ctrl+Alt+Del to reboot the system (try doing this with only one hand).

The following section discusses disability issues. Understanding these issues enables better understanding of how to create an accessible GTK+ solution.

Disability Needs

The following describes what disabled users need:

Users who are blind or who have low vision need:

• Keyboard alternatives to the mouse (mouseless operation).
• Text descriptions of graphics (such as short alternative or title text, and longer descriptions for complex graphics like tables).
• Text description of video and/or a descriptive audio track.
• To know which object has focus and when the focus changes.
• To know the default action and how to take that action.
• Online documentation.
• Screen magnification.
• High color contrast.

Users who are deaf or hard of hearing need:

• A visual indication of any sound.
• Text captioning of multimedia presentations.
• Text description of significant audio.

Users who are mobility impaired need:

• Voice or assistive device input
• Equivalent keyboard support for mouse input
• Modified keyboard response (sticky keys, bounce keys, repeat keys)
• Alternatives to multiple key inputs.
• Online documentation.

Users who have multiple disabilities need:

• Combinations of solutions; for example, speech output and voice input that do not conflict.

However an application developer doesn't have to provide all of the solution. Enable an application so that assistive technology (AT) programmers can obtain from the application program what it needs to present to it's users.

Why use GTK+ and the ATK for Accessibility?

GTK+ is the GNU Image Manipulation (GIMP) Toolkit, which is is a multi-platform toolkit for creating graphical user interfaces. GTK+ is based on 4 libraries: the GLib core library, GTK object library, Pango for layout and rendering, and the Accessibility Toolkit (ATK). Many of the ATK accessibility interfaces were derived from the Java accessibility API, which was developed by software accessibility engineers at Sun and IBM. ATK describes a set of interfaces that GUI components in applications need to implement to be accessible. The interfaces are toolkit-independent, meaning that the implementations could be written for any widget set, such as GTK, Motif or Qt, but this document will focus on ATK with the GTK widget set. Widgets are user interface objects like buttons, menus, dialog boxes, text entry fields, combo boxes, etc. The GTK+ libraries are like the Active Template Library (ATL) on the Microsoft Platform, which provides a ready-made framework for creating Component Object Model (COM) Objects and Components (ActiveX EXEs and ActiveX DLLs).

The accessibility enablement of an application is easier if the GTK+ accessibility features are exploited during development. First, minimal development resource is required to incorporate the accessibility features of GTK+ widgets. Second, software will be universally accessible for all users. Third, features specifically designed for disabled users often make the product more usable for non-disabled users as well. For example, a "keyboard-enabled" application improves usability for blind users who use a screen reader as well as for people who use voice recognition software.

Assistive Technology Vendors (ATVs) benefit as well. If an application implements GTK+ accessibility features, ATVs, such as screen reader vendors, can more easily make their products work with that accessible GTK+ application. Screen reader software receives information from running GTK+ applications using AT-SPI(Assistive Technology Service Provider Interface). Accessibility support for applications is "built in" to application toolkits via toolkit-appropriate APIs. For instance, ATK is the accessibility toolkit for most native C applications, and the Java Accessibility API is the toolkit for Java applications. These application accessibility APIs are then exported to the common AT-SPI interface via the relevant "bridge" (see the diagram above) of the GNOME Accessibility Platform (GAP).

Look for the ATK API library in the atk module in GNOME CVS. Because support for the accessibility API is built into the GTK widgets used by GNOME, a GNOME program should function reasonably well with assistive technologies with no extra work. For example, ATVs can automatically read the widget labels that are normally set in an application with GTK function calls such as gtk_label_set_text() or gtk_button_new_with_label()). They can also find out if there is any tooltip text associated with a widget, and use that to describe the widget to the user.

The accessibility API for GTK widgets is implemented in the GAIL (GNOME Accessbility Implementation Library) module, which a GTK application can dynamically load at runtime. Once GAIL is loaded, application components which use standard GTK widgets have a basic level of accessibility without modification. If GAIL is not loaded, GTK widgets and applications are not considered accessible. Whether or not GNOME/GTK+ applications automatically load these accessibility support libraries depends on the value of the accessibility gconf key named "/desktop/gnome/interface/accessibility". A boolean value of "true" enables support for assistive technologies. To enable GNOME accessibility features by setting the accessibility gconf key, type the following command line:

gconftool-2 --type bool --set /desktop/gnome/interface/accessibility true

If an application calls gnome_program_init, it will automatically load the appropriate accessibility libraries at runtime, but that application will be limited to running on the GNOME desktop. "Pure GTK+ applications" (those that use gtk+ but do not link to libgnome) require the user (or the application?) to set the value of the GTK_MODULES environment variable to "gail:atk-bridge" to enable assistive technology support. GTK_MODULES cause libgail.so and libatk-bridge.so to be loaded. Pure GTK+ applications could potentially run on other UNIX desktops that support ATK, such as KDE.

A GTK+ widget is accessible if it follows the guidelines found in Using GTK+ and ATK to Build Accessible Applications. ATK implementations are provided for the "stock" GTK+ widgets. In many cases new widgets which derive from existing GTK+ widgets will also inherit suitable accessibility support.

Though GTK+ widget's built-in accessibility support provides significant functionality without any accessibility-specific code changes on the part of the application, application developers can often improve on the accessible information provided for some of the widgets, and tailor it to that widget's specific purpose in an application, via straightforward calls to ATK methods in the application. For instance, in most cases developers should add or change the textual names and descriptions, add mnemonic keyboard bindings to labels, and associate labels for these widgets with the appropriate ATK function call, so that an assisitive technology can describe their purpose or state, key bindings, and labels to the user.