GNOME Accessibility Team
![/!\](/gnome/gnome-responsive/img/dialog-warning-symbolic.png "/!\"){kind=small}
The following content is being kept here for historical preservation only. The information contained herein may or may not be accurate. It is definitely not being maintained.
GNOME Accessibility for Developers (CVS draft)
How to make GNOME 2.0 Applications Accessible
Calum Benson
Sun Microsystems
<calum.benson@ireland.sun.com>
Brian Cameron
Sun Microsystems
<brian.cameron@ireland.sun.com>
Bill Haneman
Sun Microsystems
<bill.haneman@ireland.sun.com>
Sharon Snider
IBM Linux Technology Services
Padraig O'Briain
Sun Microsystems
<padraig.obriain@ireland.sun.com>
The GNOME Accessibility Project
Draft 0.7
Copyright © 2001, 2002 Calum Benson, Brian Cameron, Bill Haneman, Padraig O'Briain, Sharon Snider
Supporting Accessibility in GNOME Applications
What is Accessibility?
Accessibility means helping people with disabilities to participate in substantial life activities. That includes work, and the use of services, products, and information. GNOME includes libraries and a support framework that allow people with disabilities to utilize all of the functionality of the GNOME user environment.
In conjunction with assistive technologies if necessary— voice interfaces, screen readers, alternate input devices, and so on— people with permanent or temporary disabilities can therefore use the GNOME desktop and applications. Assistive technologies are also useful for people using computers outside their home or office. For example, if you're stuck in traffic, you might use voice input and output to check your email.
Assistive technologies receive information from applications via the Accessibility Toolkit (ATK) API, which you can find in the atk module in GNOME CVS. Because support for the accessibility API is built into the GNOME widgets, your GNOME program should function reasonably well with assistive technologies with no extra work on your part. For example, assistive technologies can automatically read the widget labels that you would normally set in your program anyway (e.g. 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.
With a little extra effort, however, you can make your program function even more smoothly with assistive technologies. Besides helping individual users, this will also make your product more attractive to government and education markets, many of which now require their applications to be accessible by law.
Types of Disability
In the US alone, there are an estimated 30,000,000 people whose ability to use computers may be compromised by inaccessible design. Globally, around 8% of the people who use the worldwide web have some sort of disability. Disabilities fall into one of these categories:
Visual Impairments. This can range from low-vision (including dim or hazy vision, extreme far or near-sightedness, colour blindness, or tunnel vision, amongst other things) to complete blindness. Poor choice of text size and colour, and tasks that involve good hand-eye co-ordination (such as moving the mouse) can cause problems for these users.
Movement Impairments. Users with poor muscle control or weaknesses can find it hard to use a standard keyboard or mouse. For example, they may be unable to hold down two keys simultaneously, or they may be more likely to strike keys accidentally.
Hearing Impairments. These can range from being able to hear some sounds but not distinguish spoken words, to profound deafness. Applications that convey important information by sound alone will cause problems for these users.
Cognitive and Language Impairments. These can range from dyslexia to difficulties remembering things, solving problems or comprehending and using spoken or written language. Complex or inconsistent displays, or poor choice of words can make using computers difficult for these users.
Seizure disorders. Certain light or sound patterns can cause epileptic seizures in some susceptible users.
How Accessibility Works in GNOME
The description below is substantially correct, but incomplete and needs some reorganization and clarification.
The Accessibility Toolkit (ATK) describes a set of interfaces that need to be implemented by GUI components to make them accessible. The interfaces are toolkit-independent-- implementations could be written for any widget set, such as GTK, Motif or Qt.
The implementation for the GTK widgets is in a module called GAIL (GNOME Accessbility Implementation Library), which is dynamically loadable at runtime by a GTK application. Once loaded, those parts of your application that use standard GTK widgets will have a basic level of accessibility, without you having to modify your application at all. (If GAIL is not loaded, GTK widgets will have a default accessibility implementation that essentially returns no information, though it nominally conforms to the ATK API.) Applications which use Bonobo controls, particularly out-of-process ones, also load accessibility support code from module "libgail-gnome". Whether or not applications on the GNOME desktop automatically load these accessibility support libraries depends on the value of a gconf key, "/desktop/gnome/interface/accessibility"; a boolean value of "true" enables support for assistive technologies and applications which call gnome_program_init will automatically load the appropriate accessibility libraries at runtime. "Pure GTK+ applications", e.g. those that use gtk+ but do not link to libgnome, rely on the value of the GTK_MODULES environment variable, which must be set to "gail:atk-bridge" in order to enable assistive technology support.
Most assistive technologies running on other desktops have historically found it necessary to maintain complex off-screen model of the desktop applications, based on snooping of OS events, use of unsupported OS and application features and API, and other highly nonportable techniques. This has made assistive technology support somewhat "brittle" and highly OS-and-application specific, even application-version specific. In contrast, on the GNOME Desktop, all the information required by the ATs is provided by the running applications, via the GNOME Accessibility Framework, to a toolkit-independent Service Provider Interface (SPI). The SPI provides a means for UNIX-based ATs, such as screen readers and screen magnifiers, to obtain accessibility information from running applications via a consistent, stable API, and can eliminate the need for an offscreen model in many cases. Accessibility support for applications is "built in" to application toolkits via toolkit-appropriate APIs (for instance, ATK for most native C applications and the Java Accessibility API for Java apps), and exported to the common "AT-SPI" interface via the relevant "bridge" (see diagram below).
Figure 1. GNOME Accessibility Architecture
GNOME's built-in accessibility support means that applications created using stock GNOME widgets get support for assistive technologies "for free", provided the widgets are not used in unusual ways which conflict with this built-in support.
A gtk+/GNOME widget is accessible if its use follows the general accessibility guidelines elsewhere in this document, and it implements the ATK interfaces appropriate to its role in the user interface. ATK implementations are provided for the "stock" GNOME toolkit widgets (i.e. non-deprecated gtk+ and GNOME widgets), and in many cases new widgets which derive trivially from existing GTK+ or GNOME widgets will also inherit suitable accessibility support.
Though GNOME's built-in accessibility support provides significant functionality without any accessibility-specific code changes on the part of the application, applications can often improve on the default descriptions provided for some of the widgets, and tailor them to that widget's specific purpose in your application, via straightforward calls to ATK methods in the application. For instance, in most cases applications should add or change the textual descriptions for these widgets with the appropriate ATK function call, so that an assisitive technology can describe their purpose or state to the user. See Coding Guidelines for Supporting Accessibility for more information.
If your application uses custom widgets, you may have to do some work to expose those widgets' properties to assistive technologies. See Making Custom Components Accessible and Examples that Use the Accessibility API for more information.