How Accessibility Works in GNOME
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 done via the GtkAccessible class. It is the base class for accessible implementations for GtkWidget subclasses. It is a thin wrapper around AtkObject, which adds facilities for associating a widget with its accessible object. 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.
Most assistive technologies running on other desktops have historically found it necessary to maintain a 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 non-portable 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 off-screen 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).
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 assistive 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.
For additional, in-depth information regarding GTK/GTK+, see the GTK+ Reference Manual, the outdated GTK+ 2.0 Tutorial and the official GTK+ FAQ.