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.

Die Implementierungen für die GTK-Widgets befinden sich im GAIL-Modul (GNOME Accessibility Implementation Library), das man mit jeder GTK-Anwendung zur Laufzeit dynamisch laden kann. Einmal geladen, besitzen diese Programmteile, die Standard-GTK-Widgets benutzen, grundlegende Barrierefreiheit, ohne die Notwendigkeit, die Anwendung überhaupt verändern zu müssen. Wenn GAIL nicht geladen ist, werden GTK-Widgets eine standardmäßige Implementierung der Zugänglichkeit beinhalten, die im Wesentlichen keine Informationen zurück gibt, allerdings hält es sich nominell an die ATK API. Anwendungen, die Bonobo-Steuerungen benutzen, im Besonderen out-of-process, laden ebenso Code mit Unterstützung für Barrierefreiheit aus dem Modul libgail-gnome. Ob die Anwendungen in der GNOME-Arbeitsumgebung automatisch diese Barrierefreiheit-Supportbibliotheken laden, hängt vom Wert des gconf-Schlüssels »desktop/gnome/interface/accessibility« ab; der boolesche Wert »true« schaltet den Support für unterstützende Technologien ein und Anwendungen, die gnome_program_init aufrufen, werden automatisch die richtigen Barrierefreiheitsbibliotheken zur Laufzeit laden. »Reine GTK+ Anwendungen«, z.B. solche, die GTK+ verwenden, aber nicht nach libgnomme linken, verlassen sich auf den Wert der GTK_MODULES-Umgebungsvariable, die auf den Wert »gail:atk-bridge« gesetzt werden muss, um Hilfstechnologien zu ermöglichen.

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.