Wie funktioniert Barrierefreiheit in GNOME?

The Accessibility Toolkit (ATK) beschreibt eine Sammlung von Schnittstellen, die von GUI Komponenten implementiert werden müssen, um sie barrierefrei zu gestalten. Die Schnittstellen sind unabhängig vom Toolkit- - Implementierungen können für beliebige Widgets geschrieben sein, u.a. GTK, Motif und Qt.

The implementation for the GTK widgets is in a module called GAIL (GNOME Accessibility 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.

Die meisten Hilfstechnologien (AT), die auf anderen Arbeitsumgebungen laufen, fanden es wichtig, ein kompliziertes, vom Bildschirm losgelöstes Modell für Arbeitsflächenanwendungen zu unterhalten, das auf schnüffelnden Betriebssystem-Ereignissen aufbaute, sowie nicht unterstützte Betriebssystem- und Anwendungseigenschaften und APIs, und andere kaum portierbare Techniken. Dies führte zu einer »spröden« und höchst betriebssystem- und anwendungsspezifischen, manchmal sogar versionsspezifischen Unterstützung für Hilfstechnologien. Im Gegensatz dazu steht die GNOME-Arbeitsumgebung, auf der alle von Hilfstechnologien benötigten Informationen von den laufenden Anwendungen bereitgestellt werden. Diese laufen über das GNOME Accessibility Framework zu einem Toolkit-unabhängigen »Service Provider Interface« (SPI, etwa »Dienstleistungs-Anbieter-Schnittstelle«). Das SPI bietet Mittel für UNIX-basierte Hilfstechnologien, wie zum Beispiel Bildschirmleser und Bildschirmlupen, um Barrierefreiheitsinformationen für laufende Anwendungen über eine konsistente und stabile API zu erhalten und kann den Bedarf an vom Bildschirm losgelöste Modelle in vielen Fällen beseitigen. Unterstützung für Barrierefreihei für Anwendungen ist in Anwendungstoolkits über Toolkit-entprechende APIs »eingebaut« (z.B. ATK für die meisten nativen C-Anwendungen und die Java Accessibility API für Java Apps), und wird über die betreffenden »Brücken« in die allgemeine »AT-SPI«-Schnittstelle exportiert (siehe Diagramm).

Abbildung 1-1Die GNOME Barrierefreiheits-Architektur

Die in GNOME enthaltene Unterstützung für Barrierefreiheit drückt sich darin aus, dass Sie bei der Verwendung von GNOME-Repertoire-Widgets die Unterstützung für Hilfstechnologien praktisch »umsonst« erhalten, sofern die Widgets nicht auf unübliche Weise verwendet werden, was zu Konflikten in der eingebauten Unterstützung führen kann.

Ein GTK+/GNOME-Widget ist barrierefrei, wenn dessen Benutzung den allgemeinen Richtlinien zur Barrierefreiheit in diesem Dokument folgt, und es die verwendete ATK-Oberfläche seiner Rolle in der Benutzeroberfläche umsetzt. ATK-Umsetzungen werden für die Standard-GNOME-Toolkit-Widgets (d.h. nicht veraltete GTK+- und GNOME-Widgets) bereit gestellt, und in vielen Fällen erben neue Widgets passende Unterstützung für Barrierefreiheit, welche sich trivial von existierenden GTK+- oder GNOME-Widgets ableiten.

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.

Wenn Ihr Programm angepasste Widgets verwendet, müssen Sie eventuell ein wenig Arbeit leisten, um diese Widget-Eigenschaften Hilfstechnologien zugänglich zu machen. Lesen Sie auch Eigene Komponenten barrierefrei machen und Beispiele, welche die Barrierefreiheit-API verwenden für weitere Informationen.

For additional, in-depth information regarding GTK/GTK+, see the GTK+ Reference Manual, the GTK section of the ATK Guide, the GNOME-hosted GTK+ 2.0 Tutorial and the official GTK+ FAQ.