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 Hilfestechnologien. 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 Zugänglichkeitsinformationen 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. Zugänglichkeitssupport 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).
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.
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.
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.