# GNOME Barrierefreiheitshandbuch für Entwickler

Das GNOME Barrierefreiheitshandbuch ist für Entwickler bestimmt, die sicherstellen wollen, dass ihre Bemühungen dem größtmöglichen Anwenderkreis zu Gute kommen. Dieses Handbuch deckt auch die Erfordernisse des US-Rehabilitationsgesetzes 508 ab.

2008
Vincent Alexander
2001, 2002
Calum Benson, Brian Cameron, Bill Haneman, Padraig O'Briain, Sharon Snider
2009
Mario Blättermann (mariobl@gnome.org)
GNOME-Dokumentationsprojekt

Das vorliegende Dokument kann gemäß den Bedingungen der GNU Free Documentation License (GFDL), Version 1.1 oder jeder späteren, von der Free Software Foundation veröffentlichten Version ohne unveränderbare Abschnitte sowie ohne Texte auf dem vorderen und hinteren Buchdeckel kopiert, verteilt und/oder modifiziert werden. Eine Kopie der GFDL finden Sie unter diesem Link oder in der mit diesem Handbuch gelieferten Datei COPYING-DOCS.

Das vorliegende Handbuch ist Teil einer Reihe von GNOME-Handbüchern, die unter der GFDL verteilt werden. Wenn Sie dieses Handbuch separat verteilen möchten, können Sie dies tun, indem Sie dem Handbuch eine Kopie der Lizenz, wie in Abschnitt 6 der Lizenz beschrieben, hinzufügen.

Bei vielen der von Firmen zur Unterscheidung ihrer Produkte und Dienstleistungen verwendeten Namen handelt es sich um Marken. An den Stellen, an denen derartige Namen in einer GNOME-Dokumentation vorkommen und wenn die Mitglieder des GNOME-Dokumentationsprojekts über diese Marken informiert wurden, sind die Namen in Großbuchstaben oder mit großen Anfangsbuchstaben geschrieben.

DAS DOKUMENT UND MODIFIZIERTE VERSIONEN DES DOKUMENTS WERDEN GEMÄSS DEN BEDINGUNGEN DER GNU FREE DOCUMENTATION LICENSE MIT DER FOLGENDEN VEREINBARUNG BEREITGESTELLT:

1. DAS DOKUMENT WIRD »WIE VORLIEGEND« GELIEFERT, OHNE JEGLICHE GEWÄHRLEISTUNG, WEDER AUSDRÜCKLICH NOCH STILLSCHWEIGEND, EINSCHLIESSLICH, ABER NICHT BESCHRÄNKT AUF, GEWÄHRLEISTUNGEN, DASS DAS DOKUMENT ODER EINE MODIFIZIERTE VERSION DES DOKUMENTS FREI VON HANDELSÜBLICHEN FEHLERN UND FÜR EINEN BESTIMMTEN ZWECK GEEIGNET IST UND KEINE RECHTE DRITTER VERLETZT. JEGLICHES RISIKO IN BEZUG AUF DIE QUALITÄT, GENAUIGKEIT UND LEISTUNG DES DOKUMENTS ODER EINER MODIFIZIERTEN VERSION DES DOKUMENTS TRAGEN SIE. SOLLTE SICH EIN DOKUMENT ODER EINE MODIFIZIERTE VERSION DAVON IN IRGENDEINER WEISE ALS FEHLERHAFT ERWEISEN, TRAGEN SIE (NICHT DER URSPRÜNGLICHE VERFASSER, AUTOR ODER EIN MITWIRKENDER) DIE KOSTEN FÜR JEGLICHE ERFORDERLICHE SERVICE-, REPARATUR- UND KORREKTURMASSNAHMEN: DIESE BESCHRÄNKUNG DER GEWÄHRLEISTUNG IST WESENTLICHER BESTANDTEIL DIESER LIZENZ. JEDE VERWENDUNG EINES DOKUMENTS ODER EINER MODIFIZIERTEN VERSION DES DOKUMENTS UNTERLIEGT DIESER BESCHRÄNKUNG; UND

2. UNTER KEINEN UMSTÄNDEN UND GEMÄSS KEINER RECHTSLEHRE, WEDER AUFGRUND VON UNERLAUBTEN HANDLUNGEN (EINSCHLIESSLICH FAHRLÄSSIGKEIT), VERTRÄGEN ODER SONSTIGEM, KANN DER AUTOR, DER URSPRÜNGLICHE VERFASSER, EIN MITWIRKENDER ODER EIN VERTEILER DES DOKUMENTS ODER EINER MODIFIZIERTEN VERSION DES DOKUMENTS ODER EIN LIEFERANT EINER DIESER PARTEIEN VON EINER PERSON FÜR DIREKTE, INDIREKTE, BESONDERE, ZUFÄLLIGE ODER ALS FOLGE AUFGETRETENE SCHÄDEN IRGENDEINER ART, EINSCHLIESSLICH, ABER NICHT BESCHRÄNKT AUF, SCHÄDEN DURCH GESCHÄFTSWERTVERLUSTE, ARBEITSAUSFÄLLE, COMPUTERAUSFÄLLE ODER FUNKTIONSSTÖRUNGEN ODER JEGLICHE ANDERE SCHÄDEN ODER VERLUSTE, DIE DURCH ODER IM ZUSAMMENHANG MIT DER VERWENDUNG DES DOKUMENTS ODER EINER MODIFIZIERTEN VERSION DES DOKUMENTS ENTSTANDEN SIND, SELBST WENN DIESE PARTEI ÜBER MÖGLICHE SCHÄDEN INFORMIERT WORDEN SEIN SOLLTE, HAFTBAR GEMACHT WERDEN.

Vincent
Alexander
GNOME-Dokumentationsprojekt
Calum
Benson
GNOME-Dokumentationsprojekt
Brian
Cameron
GNOME-Dokumentationsprojekt
Bill
Haneman
GNOME-Dokumentationsprojekt
Padraig
O'Briain
GNOME-Dokumentationsprojekt
Sharon
Snider
GNOME-Dokumentationsprojekt
GNOME 2.24 Barrierefreiheitshandbuch für Entwickler V2.24.0
September 2008

GNOME-Dokumentationsprojekt

GNOME-Dokumentationsprojekt

GNOME 2.24 Barrierefreiheitshandbuch für Entwickler V2.24.0
September 2008

GNOME-Dokumentationsprojekt

GNOME-Dokumentationsprojekt

Dieses Handbuch beschreibt Version 2.24 der GNOME-Arbeitsumgebung.

## Rückmeldungen

Wenn Sie Fehler finden oder Vorschläge zur GNOME-Arbeitsumgebung oder diesem Handbuch haben, folgen Sie den Anweisungen auf der GNOME-Seite für Rückmeldungen.

## Was ist Barrierefreiheit?

Barrierefreiheit bedeutet, Menschen mit Behinderungen zu helfen, an grundlegenden Lebensaktivitäten teilzunehmen. Das beinhaltet einer Arbeit nachzugehen und Dienste, Produkte und Informationen zu nutzen.

Im Zusammenspiel mit möglicherweise notwendigen Hilfstechnologien wie Sprachausgaben, Bildschirmlesern oder alternativen Eingabegeräten wird Menschen mit vorübergehenden oder dauernden Behinderungen die Nutzung der GNOME-Arbeitsumgebung und deren Anwendungen ermöglicht. Hilfstechnologien können auch sinnvoll sein, wenn Rechner außerhalb von Zuhause oder Büro genutzt werden. Wenn Sie beispielsweise im Stau stehen, werden Sie vielleicht die Spracheingabe und -ausgabe für E-Mail-Nachrichten bevorzugen.

Hilfstechnologien empfangen Informationen von Anwendungen über die Schnittstelle des »Accessibility Toolkit (ATK)«, welches Sie im Modul »atk« des GNOME-Softwarebestandes finden. Da die Unterstützung für die Barrierefreiheits-Schnittstelle bereits in die GNOME-Widgets eingebaut ist, sollte Ihr GNOME-Programm Hilfstechnologien bereits grundlegend unterstützen, ohne dass Mehraufwand Ihrerseits notwendig wäre. Beispielsweise können Hilfstechnologien automatisch die Beschriftungen lesen, die Sie irgendwo in der Benutzeroberfläche platzieren, mit Hilfe von GTK-Funktionsaufrufen wie `gtk_label_set_text()` oder `gtk_button_new_with_label()`. Sie finden auch heraus, ob eine Beschriftung mit einer Minihilfe gekoppelt ist, und verwenden diese für die Beschreibung des Widgets für den Benutzer.

Mit geringem Mehraufwand können Sie Ihr Programm besser auf die Zusammenarbeit mit Hilfstechnologien trimmen. Sie helfen in erster Linie bestimmten Benutzergruppen, machen Ihr Programm aber auch attraktiver für Endanwender im Verwaltungs- und Bildungssektor, wo barrierefreie Anwendungen oft gesetzlich vorgeschrieben sind.

### Arten von Behinderungen

Allein in den USA leben schätzungsweise 30 Millionen Menschen, deren Fähigkeit zur Benutzung von Rechnern durch nicht barrierefreies Design eingeschränkt ist. Weltweit haben etwa 8% der Nutzer des World Wide Web irgendeine Art von Behinderung. Solche Behinderungen fallen in eine dieser Kategorien:

- Visual Impairments - these can range from low-vision (including dim or hazy vision, extreme far- or near-sightedness, color-blindness, and tunnel vision, amongst others) to complete blindness. Poor choice of text size and color, and tasks that involve good hand-eye coordination (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.

### Wie funktioniert Barrierefreiheit 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 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 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).

#### Die GNOME Barrierefreiheits-Architektur

Diagramm der 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.

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.

### Schnelleinstieg für Entwickler

Hier einige übliche Einstiegspunkte:

#### Wie kann ich überprüfen, ob meine Anwendung barrierefrei ist oder nicht?

To start right in, see Making a GNOME Application Accessible - Overview. For a pre-codng perspective, see User Interface Guidelines for Supporting Accessibility or Coding Guidelines for Supporting Accessibility. For a checklist of post-design test items, see User Interface Checklist.

#### Wo lauern die häufigsten Fallen?

The User Interface Checklist covers all the areas that sometimes get overlooked in the design stage.

#### How do I do common ATK things?

Eine gekürzte Liste häufiger ATK-Aufrufe finden Sie hier.

#### How do I do more complex ATK things?

See Making Custom Components Accessible and Examples that Use the Accessibility API for more information.

#### Einführung in ATK, AT-SPI, GAIL und GTK+

Die GNOME Barrierefreiheits-Architektur

ATK is the toolkit that GNOME uses to enable accessibility for users needing extra support to make the most of their computers. ATK is used by tools such as screen readers, magnifiers, and input devices to permit a rich interaction with the desktop through alternative means. See the ATK SourceForge Project and the ATK Library for more information.

AT-SPI is the primary service interface by which assistive technologies query and receive notifications from running applications. The full API can be explored here. Additional material is available from the KDE Accessibility Development Community.

GAIL (GNOME Accessibility Implementation Library) is an implementation of the accessibility interfaces defined by ATK. GTK is a toolkit which is already mapped to ATK by the GAIL module. License, download and other information can be found here. The GAIL source code also serves as an excellent tutorial for advanced ATK usage. In addition, you may be interested in the GAIL Reference Manual.

GTK+ is a library for creating graphical user interfaces. It works on many UNIX-like platforms, Windows, and on framebuffer devices. GTK+ is released under the GNU Library General Public License (GNU LGPL), which allows for flexible licensing of client applications. GTK+ has a C-based object-oriented architecture that allows for maximum flexibility. Bindings for other languages have been written, including C++, Objective-C, Guile/Scheme, Perl, Python, TOM, Ada95, Free Pascal, and Eiffel.

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.

### Eine GNOME-Anwendung barrierefrei gestalten - Überblick

If your application only uses standard GTK widgets, you will probably have to do little or nothing to make your application (reasonably) accessible. But do watch out for objects in your GUI that don't have a textual description associated with them, such as graphical buttons or status indicators that don't have labels or tooltips.

You can probably also improve on the default descriptions provided for some of the widgets, and tailor them to that widget's specific purpose in your application. You 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. Additional detailed information can be found in Marc Mulcahy's 2002 GUADEC presentation, "Making GNOME Applications Accessible".

### Code-Richtlinien zur Unterstützung der Barrierefreiheit

Here are some things you can do in your code to make your program work as well as possible with assistive technologies. (You can find a list of things to consider when designing your GUI in the User Interface Guidelines for Supporting Accessibility section later in this document):

- For components that don't display a short string (such as a graphical button), specify a name for it with `atk_object_set_name()`. You might want to do this for image-only buttons, panels that provide logical groupings, text areas, and so on.

- If you can't provide a tooltip for a component, use `atk_object_set_description()` instead to provide a description that assistive technologies can give the user. For example, to provide an accessible description for a Close button:

  #### Bereitstellung einer Accessible-Beschreibung für einen GtkButton

      {
        AtkObject *obj;
        obj = gtk_widget_get_accessible(button);
        atk_object_set_description(obj,_("Closes the window"));
      }

- Verwenden Sie `atk_image_set_description()`, um eine Beschreibung in Textform für alle Bilder und Symbole in Ihrem Programm bereitzustellen.

- Falls verschiedene Komponenten eine logische Gruppe bilden, versuchen Sie, diese in einem Container unterzubringen.

- Whenever you have a label that describes another component, use `atk_relation_set_add_relation()` so that assistive technologies can find the component with which the label is associated. (If you associate the label with the component using `gtk_label_set_mnemonic_widget()`, the `ATK_RELATION_LABEL_FOR` relation is generated automatically, so the following code would not be necessary):

  #### Beziehen eines GtkLabel auf ein GtkWidget

      {
        GtkWidget *widget;
        GtkLabel *label;

        AtkObject *atk_widget, *atk_label;
        AtkRelationSet *relation_set;
        AtkRelation *relation;
        AtkObject *targets[1];

        atk_widget = gtk_widget_get_accessible(widget);
        atk_label = gtk_widget_get_accessible (GTK_WIDGET(label));

        relation_set = atk_object_ref_relation_set (atk_label);
        targets[0] = atk_widget;

        relation = atk_relation_new(targets,1, ATK_RELATION_LABEL_FOR);
        atk_relation_set_add(relation_set,relation);
        g_object_unref(G_OBJECT(relation));
      }

- Falls Sie ein benutzerdefiniertes Widget erstellen, sollten Sie sicherstellen, dass es barrierefrei ist. Benutzerdefinierte Komponenten, die von anderen GTK-Widgets abstammen, erben die notwendigen Barrierefreiheits-Informationen. Weitere Informationen hierzu finden Sie in Benutzerdefinierte Komponenten barrierefrei gestalten.

- Don't break what you get for free! If your GUI has an inaccessible container, any components inside that container may become inaccessible.

### Die Barrierefreiheits-API

Nachfolgend finden Sie einige grundlegende API-Aufrufe, die Sie in Ihrer Anwendung nutzen können, um das reibungslose Zusammenwirken mit Hilfstechnologien sicher zu stellen. Die gesamte Barrierefreiheits-API ist erweiterbar, so dass Sie beispielsweise Ihre eigenen benutzerdefinierten Accessible-Widgets erstellen können.

#### Häufig genutzte API-Aufrufe von ATK

API | Beschreibung
--- | ---
`AtkObject* gtk_widget_get_accessible (GtkWidget*)` | Gibt das Accessible-Objekt zurück, welches das angegebene GTK-Widget für eine Hilfstechnologie beschreibt.
`void atk_object_set_name (AtkObject*, const gchar*)` | Legt den Namen des Accessible-Objekts fest. Wenn beispielsweise das Objekt ein grafischer Knopf ist, der beim Anklicken die Anwendung beeendet, könnte der Name »Quit« lauten.
`void atk_object_set_description (AtkObject*, const gchar*)` | Legt die Beschreibung in Textform für das Accessble-Objekt fest. Wenn beispielsweise das Objekt ein grafischer »Close«-Knopf ist, dann könnte die Beschreibung »Closes the window« lauten.

`AtkRelation* atk_relation_new (AtkObject**, gint, AtkRelationType)`

Erstellt einen neuen Bezug zwischen dem angegebenen Schlüssel und der angegebenen Liste der Zielobjekte. Eine solche Beziehung informiert normalerweise die Hilfstechnologie darüber, dass ein Widget in einem bestimmten Verhältnis zu einem anderen steht. Beispielsweise ist ein bestimmtes GtkLabel eine Beschriftung für ein GtkTreeView im gleichen Fenster.

`void atk_image_set_description (AtkImage*, const gchar*)` | Legt die Beschreibung in Textform für das Accessible-Bildobjekt fest. Wenn das Objekzt beispielsweise ein Vorschaubild auf eine virtuelle Arbeitsfläche in einem Panel-Applet ist, dann könnte die Beschreibung »Image showing window arrangement on desktop 1« lauten.

### Beispiele für die Nutzung der Barrierefreiheits-API

Wie bereits erwähnt, sollte der Aufwand gering sein, wenn Sie Ihre Anwendung mit Hilfe der Gtk-Widgetsammlung oder jeder anderen die ATK-Schnittstelle nutzenden Widgetsammlung barrierefrei gestalten. Dies sind die zwei häufigsten Aufgaben in diesem Fall:

- Bereitstellung von Beschreibungen von Bedienelementen mit `atk_object_set_description()` oder `atk_image_set_description():`

  #### Festlegen der barrierefreien Beschreibung für einen Knopf

      {
         AtkObject *obj;
         obj = gtk_widget_get_accessible(button);
         atk_object_set_description(obj,_("Opens Preferences dialog"));
      }

- Angeben von Beziehungen zwischen unüblichen Widget-Gruppierungen mittels `atk_relation_new()` und `atk_relation_set_add()`:

  #### Festlegen einer barrierefreien Beziehung zwischen zwei Bedienelementen

      {
        GtkWidget *widget;
        GtkLabel *label;

        AtkObject *atk_widget, *atk_label;
        AtkRelationSet *relation_set;
        AtkRelation *relation;
        AtkObject *targets[1];

        atk_widget = gtk_widget_get_accessible (widget);
        atk_label = gtk_widget_get_accessible (GTK_WIDGET(label));

        relation_set = atk_object_ref_relation_set (atk_label);
        targets[0] = atk_widget;

        relation = atk_relation_new(targets,1, ATK_RELATION_LABEL_FOR);
        atk_relation_set_add(relation_set,relation);
        g_object_unref(G_OBJECT(relation));
      }

The examples in the rest of this section are mostly to give you a flavor of the scope of the ATK. They cover techniques that you may never need to use as an application developer, although they may be of interest if you are writing your own custom widgets (see Making Custom Components Accessible) or if you want to write an assistive technology application. Whatever the purpose, the GAIL source code serves as an excellent tutorial for advanced ATK usage.

#### GTK-Module

Programs that make use of GAIL (the accessibility implementation library for GTK widgets) are written as GTK modules. GTK modules are loaded into the program space if the `GTK_MODULES` environment variable specifies the module library name(s). If there are multiple module libraries, separate them with colons. For example:

`setenv GTK_MODULES "libgail:libtestprops"`

Alle GTK-Module haben eine `gtk_module_init()`-Funktion.

#### Gathering accessibility information from an application

A program that wishes to make use of ATK calls would likely need to do one (or more) of the following things:

1. Create an event watcher, for example with the `atk_add_focus_tracker()` function:

       atk_add_focus_tracker (_my_focus_tracker);

   wobei `_my_focus_tracker()` eine Funktion folgenden Prototyps ist:

       void _my_focus_tracker (AtkObject *aobject);

2. Set up a global event listener, with atk_add_global_event_listener():

       mouse_watcher_focus_id =   atk_add_global_event_listener(_my_global_listener,"Gtk:GtkWidget:enter_notify_event");

   where `_my_global_listener` has the prototype of a Glib GSignalEmissionHook. This example would cause the `_my_global_listener()` to be called whenever an enter_notify_even signal occurs on a GtkWidget object.

3. Access the ATK top-level object with the following function call.

       AtkObject *root_obj = atk_get_root();

   This returns an AtkObject which contains all toplevel windows in the currently running program. The user could then navigate through the object heirarchy by accessing the root object's children, which corresponds to the toplevel windows.

#### Querying an AtkObject's Interfaces

Having located the AtkObject associated with an object in the application (e.g. by using `gtk_widget_get_accessible()`), you can find out what interfaces it implements in various ways:

1. Use the supplied `ATK_IS_...` macros, for example:

   - `ATK_IS_ACTION(atkobj)`

   - `ATK_IS_COMPONENT(atkobj)`

   - etc. (there is one for each interface)

   If the macro returns `TRUE`, the interface calls can safely be made on that ATK object.

2. Test the role of the AtkObject by calling `atk_object_get_role()`. Any given role implements a specific number of ATK APIs.

#### Setting up an ATK Signal Handler

Using the `column_inserted` signal as an example:

    table_column_inserted_id = g_signal_connect_closure_by_id(my_atk_obj,
    g_signal_lookup("column_inserted", G_OBJECT_TYPE(my_atk_obj)),0,g_cclosure_new(G_CALLBACK (_my_table_column_inserted_func),NULL,NULL), FALSE);

This will cause `_my_table_column_inserted_func()` to be called whenever a column_inserted signal is emitted on the AtkObject `my_atk_object`.

Connecting to a signal is slightly different if the signal supports detail. The `children_changed` signal supports the `add` detail. To connect to a signal when the `add` detail is also specified, this technique is used:

    child_added_id = g_signal_connect_closure (my_atk_obj,"children_changed::add",   g_cclosure_new (G_CALLBACK(_my_children_changed_func),NULL,NULL),FALSE);

This will cause `_my_children_changed_func()` to be called whenever a `children_changed` signal with the `add` detail is emitted on the AtkObject `my_atk_obj`.

#### Implementieren eines ATK-Objekts

You will need to implement your own ATK objects for any widgets that do not already have an accessible implementation in GAIL (or the equivalent library for other widget sets). This should be implemented as a GTK module, which, as before, should be included in the `GTK_MODULES` environment variable so it is loaded at runtime.

##### Registry

For this example we will assume there is an object called GTK_TYPE_MYTYPE. The ATK implementation will be called MYATKIMP_TYPE_MYTYPE. A factory will be needed which will be called MYATKIMP_TYPE_MYTYPE_FACTORY.

To register an ATK implementation of a GTK object, these steps must be followed in the module's `gtk_module_init()` function:

1. Access the default registry:

       default_registry = atk_get_default_registry();

2. Register the ATK object in the `gtk_module_init()` function of this module by making this function call:

       atk_registry_set_factory_type (default_registry, GTK_TYPE_MYTYPE, MYATKIMP_TYPE_MYTYPE_FACTORY);

This will register the AtkObject implementation of GTK_TYPE_MYTYPE to MYATKIMP_TYPE_MYTYPE_FACTORY. This factory will be implemented so that it knows how to build objects of type MYATKIMP_TYPE_MYTYPE.

##### Factory

The factory must be implemented as a child of class type ATK_TYPE_OBJECT_FACTORY and must implement the function `create_accessible()`. This function must create an appropriate AtkObject. A factory can be used to create more than one type of object, in which case its `create_accessible()` function will need to be smart enough to build and return the correct AtkObject.

##### ATK-Implementation für ein bestimmtes Objekt

All GObjects implement a `get_type()` function. Using the above example the naming convention for this function name would be `myatkimp_mytype_get_type()`.

In this function, you specify which interfaces your object implements. If the following logic were included in this `get_type()` function, this object would implement the ATK_TEXT interface:

###### Sample `get_type()` function

    static const GInterfaceInfo atk_text_info =
    {
       (GInterfaceInitFunc) atk_text_interface_init,
       (GInterfaceFinalizeFunc) NULL,
       NULL
    };

    g_type_add_interface_static (type, ATK_TYPE_TEXT,
                                 &atk_text_info);

The function `atk_text_interface_init()`, which has the following prototype, would need to be implemented:

    void atk_text_interface_init (AtkTextIface *iface);

This function would connect the interface function calls to the specific implementation as follows:

###### Connecting custom interface calls to an AtkObject implementation

    void
    atk_text_interface_init (AtkTextIface *iface)
    {
       g_return_if_fail (iface != NULL);
       iface->get_text = myatkimp_mytype_get_text;
       iface->get_character_at_offset = myatkimp_mytype_get_character_at_offset;
       ...
    }

Then the functions `myatkimp_mytype_get_text()`, `myatkimp_mytype_get_character_at_offset()`, and the rest of the ATK_TEXT interface functions would need to be implemented.

##### AtkObject-Implementation

AtkObjects are GObjects, and all GObjects need to specify the `get_type()` function. Here is an example that sets up a class and instance initializer. This `get_type()` function also specifies that the object implements ATK_TEXT and specifies the parent object to be MYATKIMP_MYPARENTTYPE.

###### Sample `get_type()` implementation

    GType
    myatkimp_mytype_get_type (void)
    {
       static GType type = 0;

       if (!type)
       {
          static const GTypeInfo tinfo =
          {
             sizeof (GailLabelClass),
             (GBaseInitFunc) NULL,                              /* base init */
             (GBaseFinalizeFunc) NULL,                          /* base finalize */
             (GClassInitFunc) myatkimp_mytype_class_init,       /* class init */
             (GClassFinalizeFunc) NULL,                         /* class finalize */
             NULL,                                              /* class data */
             sizeof (GailLabel),                                /* instance size */
             0,                                                 /* nb preallocs */
             (GInstanceInitFunc) myatkimp_mytype_instance_init, /* instance init */
             NULL                                               /* value table */
          };

          /* Set up atk_text_info structure used below */
          static const GInterfaceInfo atk_text_info =
          {
             (GInterfaceInitFunc) atk_text_interface_init,
             (GInterfaceFinalizeFunc) NULL,
             NULL
          };

          /* Set up typename and specify parent type */
          type = g_type_register_static (MYATKIMP_MYPARENTTYPE,
                "MyatkimpMytype", &tinfo, 0);

          /* This class implements interface ATK_TYPE_TEXT */
          g_type_add_interface_static (type, ATK_TYPE_TEXT,
                                       &atk_text_info);
       }
       return type;
    }

##### Initialisierung von Klassen und Instanzen

You will have to set up a class initializer for the GObject if your AtkObject implementation either:

1. Redefines any function calls defined by the object's parent. This is typically necessary when an object needs to implement a function like `atk_object_get_n_accessible_children()`. This is necessary if the object has children, but they are not represented with widgets.

   For example, if your ATK implementation needs to over-ride the AtkObject function `get_name()`, then the class initializer would look like:

   ###### Class initializer that overrides parent's `get_name()` function

       myatkimp_mytype_class_init (GailLabelClass *klass)
       {
         AtkObjectClass *class = ATK_OBJECT_CLASS (klass);
         class->get_name = myatkimp_mytype_get_name;
       }

2. Benötigt eine `parent->init`-, `parent->notify_gtk`- oder `parent->finalize`-Funktion. Dieses Beispiel definiert alle drei:

   ###### Class initializer that defines its own `init()`, `notify_gtk()` and `finalize()` functions

       static ParentObjectType *parent_class = NULL;

       myatkimp_mytype_class_init (GailLabelClass *klass)
       {
          ParentObjectType *parent_class = (ParentObjectType*)klass;

          /*
           * Caching the parent_class is necessary if the init,
           * notify_gtk, or finalize functions are set up.
           */
           parent_class = g_type_class_ref (MYATKIMP_TYPE_PARENT);

           parent_class->init = myatkimp_mytype_widget_init;
           parent_class->notify_gtk = myatkimp_mytype_real_notify_gtk;
           parent_class->finalize = myatkimp_mytype_finalize;
       }

   1. parent->init

      A `parent->init()` function may be necessary if the ATK implementation needs to do either of the following:

      1. Cache any data obtained from a backing GTK widget.

      2. Listen to any signals from the backing GTK widget.

      Hier ein Beispiel für beides:

      ###### Eine benutzerdefinierte `init()`-Funktion

          void
          gail_tree_view_widget_init (MyatkimpMytype  *mytype,
                                      GtkWidget       *gtk_widget)
          {
             /* Make sure to call the parent's init function */
             parent_class->init (widget, gtk_widget);

             /* Cache a value in the ATK implementation */
             mytype->cached_value = gtk_widget_function_call();

             /* Listen to a signal */
             gtk_signal_connect (GTK_OBJECT (gtk_widget),
                                 "signal-type",
                                 GTK_SIGNAL_FUNC (_myatkimp_mytype_signal_type),
                                 NULL);
          }

      In this example, if the specified signal-type signal were generated on the backing `gtk_widget`, then the `_myatkimp_mytype_signal_type()` function would be called.

   2. parent->notify_gtk

      If the ATK implementation needs to listen to any property notifications on the backing GTK object, a `parent->notify_gtk()` function may be necessary. For example:

      ###### Eine benutzerdefinierte `notify_gtk()`-Funktion

          void
          myatkimp_mytype_real_notify_gtk (GObject    *obj,
                                           GParamSpec *pspec)
          {
             GtkWidget *widget = GTK_WIDGET (obj);
             AtkObject* atk_obj = gtk_widget_get_accessible (widget);

             if (strcmp (pspec->name, "property-of-interest") == 0)
             {
                /* Handle the property change. */
             }
             else
             {
                parent_class->notify_gtk (obj, pspec);
             }
          }

   3. parent->finalize

      If it is necessary to free any data when a GObject instance is destroyed, then a `finalize()` function is needed to free the memory. For example:

      ###### Eine benutzerdefinierte `finalize()`-Funktion

          void
          myatkimp_mytype_finalize (GObject *object)
          {
             MyAtkimpMyType *my_type = MYATKIMP_MYTYPE (object);

             g_object_unref (my_type->cached_value);
             G_OBJECT_CLASS (parent_class)->finalize (object);
          }

### Benutzerdefinierte Komponenten barrierefrei gestalten

Das Hinzufügen von ATK-Unterstützung zu Ihrem benutzerdefinierten Widget stellt die Zusammenarbeit mit der Barrierefreiheits-Infrastruktur sicher. Folgende grundlegende Schritte sind hierzu erforderlich:

- assess a custom widget according to the applicable User Interface Guidelines;

- determine which ATK interfaces a custom widget should implement, according to the widget's feature set and function;

- assess which ATK interfaces can be inherited from the parent widget class;

- implement the appropriate ATK interfaces for the widget class in one of two ways:

  - directly by the custom widget, or

  - in an AtkObject subtype created by a new AtkObjectFactory subclass

  If the second method is used, the appropriate factory type must be registered with the AtkObjectFactoryRegistry at runtime.

The GAIL source code serves as an excellent tutorial for advanced ATK usage.

### Richtlinien für Benutzeroberflächen zur Unterstützung der Barrierefreiheit

When designing your application's GUI, there are a number of simple guidelines you should follow to ensure that it can be used by as wide an audience as possible, whether in conjunction with assistive technologies or not. Don't be fooled into thinking that this is just a case of "making your GUI usable by people with disabilities", though, and that you shouldn't bother if you know a disabled person is never going to use your application. Following these guidelines will improve the overall usability of your application for everyone who uses it - including you!

#### Allgemein

We all get frustrated if we can't find a feature in an application, or make a mistake from which it takes a couple of minutes to recover, if it's possible to recover at all. If you have some sort of disability, the chances are the effort and time penalties involved will be several times worse. Following a few basic guidelines can help prevent these sorts of situations for all users.

- Stellen Sie eine Rückgängig-Funktion für jede Aktion bereit, welche die Benutzerdaten oder die Anwendugseinstellungen beeinflusst. Falls möglich, sollten für Rückgängig- und Wiederherstellungsfunktionen mehrere Ebenen ermöglichen und eine Chronikansicht anbieten, die eine Vorschau auf rückgängig zu machende Aktionen enthält.

- Stellen Sie Befehle zum Wiederherstellen von Standardeinstellungen bereit. Falls eine bestimmte Einstellung eine Anwendung für einen bestimmten Benutzer unbenutzbar machen könnte, beispielsweise durch eine viel zu kleine Schrift, dann kann eine Wiederherstellungsfunktion außerhalb der Anwendung sehr nützlich sein. Das kann zum Beispiel über einen entsprechenden Schalter in der Befehlszeile geschehen.

- Verhindern Sie, dass der Benutzer das Falsche tut. Das ist insbesondere für Aktionen von Bedeutung, die zufällig geschehen können (z.B. durch Mausbedienung) oder die nicht ohne Weiteres rückgängig gemacht werden können (z.B. Überschreiben von Dateien). Stellen Sie Informationsdialoge bereit oder zwingen Sie den Benutzer, gefährliche Aktionen nur in einem bestimmten Modus auszuführen.

- Überstrapazieren Sie das Gedächtnis des Benutzers nicht. Lassen Sie den Benutzer beispielsweise mehrere Dokumente gleichzeitig betrachten und stellen Sie eine Online-Hilfe oder andere Hilfeanweisungen zur Verfügung, während die beschriebene Prozedur ausgeführt wird. Ermöglichen Sie das Kopieren jeglicher angezeigter Informationen und das Einfügen an beliebigen Stellen, wo Daten eingegeben werden können.

- Lassen Sie den Benutzer keine Speichermedien einlegen. Abhängig von der jeweiligen Behinderung kann es schwierig sein, ein Medium physikalisch betrachtet einzulegen oder zu wechseln, oder das korrekte Medium richtig zu identifizieren. Falls Ihre Anwendung von CD-ROM installiert wird, sollten Sie dem Benutzer die Möglichkeit bieten, alle benötigten Dateien direkt auf die Festplatte zu kopieren.

- Vergraben Sie häufig genutzte Funktionen nicht tief in einer Menüstruktur. Egal ob Sie eine Maus, die Tastatur oder ein anderes Eingabegerät verwenden, sollten tief ineinander verschachtelte Einträge besser vermieden werden. Da sich der Benutzer daran erinnern muss, wo diese zu finden sind, ist der Zugriff zu schwierig und erfordert zu viel Zeit.

- Führen Sie den Benutzer nicht durch unnötige Schritte. Einrichtungsassistenten können zwar für Benutzer hilfreich sein, die Schwierigkeiten haben, mit vielen Optionen gleichzeitig umzugehen, aber andere wiederum möchten die Zeit oder die Anzahl der Tastenbedienungen minimieren. Solche Benutzer profitieren davon, nicht benötigte Schritte überspringen und direkt zum nächsten gewünschten Schritt gehen zu können. Stellen Sie in Ihrem Einrichtungsassistenten einen Finish-Knopf bereit, der direkt zum Ende des Assistenten führt und für die verbleibenden Schritte Standardwerte annimmt. Falls der Assistent aus sehr vielen Schritten besteht, sollten Sie den Benutzer zu Beginn fragen, ob alle diese Schritte angeboten werden oder nur diejenigen, die am häufigsten genutzt werden.

#### Tastatursteuerung

Eine gut durchdachte Tastaturschnittstelle spielt eine Schlüsselrolle beim entwerfen barrierefreier Software. Blinde Benutzer können wesentlich effektiver mit der Tastatur navigieren, weil die Nutzung der Maus die visuelle Rückmeldung des Ortes des Mauszeigers erfordert. Auch Körperbehinderungen können der Grund dafür sein, dass ein Benutzer erfolgreich mit der Maus navigieren kann, da dies von der Feinmotorik abhängt.

Es ist daher wichtig, dass alle Mausaktionen auch über die Tastatur erreichbar sind, einschließlich des Zugriffs auf alle Werkzeugleisten, Menüs, Verknüpfungen und Knöpfe. Jede von Ihrer Anwendung bereitgestellte Funktion sollte auch ausschließlich mit der Tastatur erreichbar sein. Legen Sie Ihre Maus besser zur Seite, wenn Sie Ihre Anwendung testen!

Most functionality should be easy to make accessible by using keyboard mnemonics and accelerators, and the toolkit's built-in navigation features. However, operations that rely on drag-and-drop, for example, may require more thought.

- Provide efficient keyboard access to all application features. Some users may be unable to use a mouse, and many "power-users" prefer to use the keyboard anyway. Also, some specialized assistive technology input devices may simulate keyboard events rather than mouse events. Since typing is difficult or even painful for some users, it is important to provide a keyboard interface that minimizes the number of keystrokes required for any given task.

- Use a logical keyboard navigation order. When navigating around a window with the Tab key, keyboard focus should move between controls in a predictable order. In Western locales, this is normally left to right and top to bottom.

- Ensure correct tab order for controls whose enabled state is dependent on checkbox, radio button or toggle button state. When such a button is selected, all its dependent controls should be enabled, and all the dependent controls of any other button in the group should be disabled. When the user selects a checkbox, radio button or toggle button that has dependent controls, do not automatically give focus to the first dependent control, but instead leave the focus on the button.

- Don't override existing system-level accessibility features. For example, AccessX is an Xserver extension that has been supported since X11R6. The MouseKeys feature of this extension allows mouse movement and button clicks to be simulated using the keypad. Therefore you should not add features to your application that can only be accessed by pressing keys on the keypad, as users relying on the MouseKeys feature will not be able to use them.

- Provide more than one method to perform keyboard tasks where possible. Some users may find some keys and key combinations easier to use than others.

- Provide both keyboard and mouse access to functions where possible. Some users may only be able to use either the mouse or the keyboard, but not both.

- Don't assign awkward reaches to frequently performed keyboard operations. Some people may only be able to use one hand on the keyboard, so shortcuts that can be easily used with one hand are preferable for common operations. In any case, having to frequently perform long or difficult reaches on the keyboard can increase muscle strain for all users, increasing the risk of pain or injury.

- Don't require repetitive use of simultaneous keypresses. Some users are only able to press and hold one key at a time. Assistive technologies such as AccessX may allow users to press the keys sequentially rather than simultaneously, but this of course means the operation will take longer for them.

- Ensure that any text that can be selected with the mouse can also be selected with the keyboard. This is a convenience for all users, but especially for those for whom fine control of the mouse is difficult.

- Ensure that objects that can be resized or moved by drag and drop can also be resized or moved with the keyboard. For example, icons and windows on the desktop. Where precision sizing and placement is potentially important, e.g. shapes in a diagram, also consider providing a dialog into which you can type co-ordinates, or a means of snapping objects to a user-definable grid.

- Don't use general navigation functions to trigger operations. For example, do not use basic Tab keyboard navigation in a dialog to activate any actions associated with a control.

- Show keyboard-invoked menus, windows and tooltips near the object they relate to. In GNOME 2.0, users can call up popup menus with Shift F10, and tooltips with Shift F1. Do not completely hide or obscure the object to which the menu or tooltip refers, however.

#### Maus-Interaktion

Remember that not everybody can use a mouse with equal dexterity, and that some users may have difficulty seeing or following the mouse pointer.

- Don't depend on input from mouse button 2 or button 3. As well as being physically more difficult to click, some pointing devices and many assistive technology devices only support button 1. Some assistive technologies may not emulate the mouse at all, but generate keyboard events instead.

- Allow all mouse operations to be cancelled. Pressing the Esc key should cancel any mouse operation in progress, such as dragging and dropping a file in a file manager, or drawing a shape in a drawing program.

- Provide visual feedback throughout a drag and drop operation. As the mouse passes over valid targets, highlight them and change the mouse pointer. Use the "no drop" mouse pointer when passing over invalid drop targets. See Mouse Interaction Examples.

- Don't warp the mouse pointer, or restrict mouse movement to part of the screen. This can interfere with assistive technologies, and is usually confusing even for users who don't rely on ATs.

- Don't make mouse targets too small. In general, mouse targets should be at least the size of the "hot area" around the resizable window border in the current window manager/theme - bearing in mind that a user with impaired dexterity or vision may be using a window manager with larger areas than the default.

##### Beispiele für Maus-Interaktionen

###### Beispiel eines »no-drop«-Zeigers aus CDE/Motif

Beispiel für eine »invalid drop target«-Zeigerform

#### Grafische Elemente

Provide options to customize the presentation of all the important graphical elements in your application. This will make it easier for people with visual or cognitive impairments to use.

- Don't hard-code graphic attributes such as line, border or shadow thickness. These elements should ideally be read from the GTK or window manager theme. If this is not possible, provide options within your application to change them.

- Provide descriptive names for all interface components. The GAIL library provides default accessible descriptions for many GTK widgets, but you will still need to add your own in some cases, such as for widgets that use graphics instead of text (e.g. a well in a color palette, or an icon without a label). Consider overriding the defaults with more helpful or application-specific descriptions where possible.

- Allow multi-color graphical elements (e.g. toolbar icons) to be shown in monochrome only, if possible. These monochrome images should be shown in the system foreground and background colors, which the user will have chosen for themselves (by their choice of GTK theme) for maximum legibility.

- Make interactive GUI elements easily identifiable. For example, do not make the user hover the mouse over an object to determine whether it is clickable or not. Leave sufficient space between objects and clearly delineate object boundaries. Don't show GUI elements that look pretty but don't actually do anything, unless you also provide an option to switch them off.

- Provide an option to hide graphics that don't convey essential information. Graphical images can be distracting to users with some cognitive disorders. The icons on the GNOME foot menu, for example, can be switched off whilst still leaving the menus fully functional.

#### Schriften und Text

Even to a user with normal vision, textual output provides the majority of the information and feedback in most applications. It is therefore critical to choose and position text carefully on the screen, and leave the choice of font and size to the user, to ensure that people with vision impaiments can also use your application effectively.

- Don't hard-code font styles and sizes. The user should be able to adjust all sizes and typefaces. If for some reason you cannot make this functionality available, never hardcode any font sizes smaller than 10 points.

- Provide options to turn off any graphical backdrops or "watermarks" behind text. Such images interfere with the contrast between the text and its background, which can cause difficulty for users with visual impairments.

- Label objects with names that make sense when taken out of context. Users relying on screen readers or similar assistive technologies will not necessarily be able to immediately understand the relationship between a control and those surrounding it.

- Don't use the same label more than once in the same window. If you use the same label in different windows, it will help if it means the same thing in both windows. Also, don't use labels that are spelled differently but sound the same, e.g. "Read" and "Red", as this could be confusing for users relying on screen-readers.

- Position labels consistently throughout your application. This normally means immediately below large icons, immediately to the right of small icons, and immediately above or to the left of other controls. See Fonts and Text Examples.

- When you use static text to label a control, end the label with a colon. For example, Username: to label a text field into which the user should type their username. This helps identify it as a control's label rather than an independent item of text.

- When you use static text to label a control, ensure that the label immediately precedes that control in the Tab order. This will ensure that the mnemonic (underlined character) you assign to the label will move focus to or activate the correct control when pressed.

- Provide alternatives to WYSIWYG. Some users may need to print text in a small font but edit in a larger screen font, for example. Possible alternatives include displaying all text in the same font and size (both of which are chosen by the user); a "wrap-to-window" option that allows you to read all the text in a window without scrolling horizontally; a single column view that shows the window's contents in a single column even if they will be printed in multiple columns; and a text-only view, where graphics are shown as placeholders or text descriptions. If the application has panels with child controls, consider allowing the panels to resize along with the parent window.

##### Beispiele für Schriften und Text

###### Correct label placement for various GUI elements

List control with label above List control with label above | Large file manager icon with label underneath Large file manager icon with label underneath | Small toolbar icon with label to its right Small toolbar icon with label to its right | Einstellfeld mit Beschriftung an der linken Seite Spinbox control with label to its left

#### Farbe und Kontrast

Poor choice of colors on the screen can cause problems for users with color blindness (for whom hue is important) or low-vision (for whom brightness/contrast is important). Generally, you should allow the user to customize the colors in any part of your application that conveys important information.

Users with visual impairments may require a high level of contrast between the background and text colors. Often a black background and white text is used to prevent the background from "bleeding" over. These settings are critical for users with visual impairments.

- Don't hard-code application colors. Some users need to use particular combinations of colors and levels of contrast to be able to read the screen comfortably. Therefore all the main colors you use in your GNOME application should be taken from the GTK theme, so the user can set the colors for all their applications to something legible just by changing the theme. If for some reason you do need to use colors that are not available in the theme, ensure they are customizable within the application itself.

- Don't use color as the only means to distinguish items of information. All such information should be provided by at least one other method, such as shape, position or textual description. See Color and Contrast Examples.

- Support all the high contrast GNOME themes. Ensure that when one of these themes is selected, all the text in your application appears in the high contrast foreground and background colors specified by the theme.

- Stellen Sie sicher, dass Ihre Anwendung nicht ein bestimmtes Thema mit hohem Kontrast benötigt. Testen Sie sie mit verschiedenen Themen mit hohem Kontrast, um sicher zu stellen, dass Ihre Anwendung die Einstellungen respektiert.

##### Beispiele für Farbe und Kontrast

###### Beispiel für die redundante Farbverwendung

Beispiel für die Darstellung von Aktienkursen nur mit Farben

Diese Anzeige könnte farbenblinden Benutzern mit einer Rot-Grün-Schwäche Probleme bereiten. Diese Art der Farbenblindheit betrifft in einigen Teilen der Welt ein Siebtel der Männer. Durch den mangelnden Kontrast zwischen dem roten Text und dem schwarzen Hintergrund ist die Lesbarkeit auch für Sehbehinderte beeinträchtigt, selbst unter Zuhilfenahme einer Bildschirmlupe.

Beispiel für die Darstellung von Aktienkursen mit sowohl Farben als auch Pfeilen

This display reinforces the color-coding with arrows to show the stock price movement, and uses darker shades of green and red on a lighter background to provide higher contrast. This needn't be the default color scheme if testing were to show it to be too distracting for the majority of users, but it should be possible to customize it in this way either by theming or via the application's Einstellungen dialog.

#### Vergrößerung

Viele Benutzer profitieren von der Vergrößerung von Text und Grafiken, selbst jene Benutzer ohne Sehbehinderung. Ohne Vergrößerung könnte ein sehbehinderter Benutzer möglicherweise überhaupt nicht in der Lage sein, Ihr Programm zu verwenden.

- Geben Sie dem Benutzer die Möglichkeit, den Arbeitsbereich zu vergrößern.

- Ermöglichen Sie, die Größe des Arbeitsbereiches Ihrer Anwendung zu verändern. Benutzer sollten den Arbeitsbereich auf 150-400% oder mehr vergrößern können. Testen sie Ihre Anwendung, um zu überprüfen, dass die Darstellung des betrachteten Objekts nicht durch die Vergrößerungseinstellung beeinträchtigt wird.

#### Klänge

Sowohl Leute mit eingeschränktem Hörvermögen als auch Benutzer, die Klänge auf Ihrem Rechner generell abgeschaltet haben, dürften nicht begeistert sein, wenn Ihre Anwendung Informationen allgemein über Klangausgaben bereitstellt. Stellen Sie sicher, dass der Benutzer in der Lage ist, als Klang ausgegebene Informationen auch auf anderen Wegen zu erhalten.

- Nehmen Sie nicht einfach an, dass ein Benutzer Klänge hören will. Das betrifft sowohl Benutzer mit defekten Soundkarten als auch Hörgeschädigte!

- Betrachten Sie Klänge nicht als den einzigen Weg, Informationen bereitzustellen. Geben Sie dem Benutzer die Möglichkeit, alle Klanginformationen auch visuell darstellen zu können. Dies beinhaltet geschlossene Beschriftungen und Textausgaben von allen wichtigen gesprochenen Soundclips.

- Ermöglichen Sie dem Benutzer, die Frequenz und die Lautstärke alle Warntöne und sonstigen Klänge einzustellen. Die Klänge sollten auch vollständig abschaltbar sein.

#### Animation

Sparsam verwendet, können Animationen durchaus nützlich zur Darstellung wichtiger Informationen in Ihrer Anwendung sein - und sie können natürlich auch cool aussehen. Allerdings können sie für bestimmte Benutzer auch problematisch sein, daher sollten Sie eine Möglichkeit vorsehen, die Animationen abzuschalten.

- Verwenden Sie keine blitzenden oder blinkenden Elemente mit einer Frequenz oberhalb von 2 Hz und unterhalb von 55 Hz. Dies betrifft sowohl Text als auch jegliche grafische Objekte. Alles innerhalb dieses Frequenzbereichs kann Benutzern mit Sehbehinderungen Probleme bereiten. Denken Sie daran, dass es keine »sichere« Frequenz gibt. Falls Blinken von essenzieller Bedeutung ist, dann sollten Sie die Blinkfrequenz des Systemzeigers verwenden (die an sich schon konfigurierbar ist) oder den Benutzern ermöglichen, eine eigene Frequenz festzulegen.

- Lassen Sie keine größeren Bereiche des Bildschirms blitzen oder blinken. Kleine Bereiche verursachen weit weniger Probleme für Benutzer mit Sehbehinderungen.

- Make all animations optional. The animated information should be available in at least one non-animated format, at the user's request.

#### Tastaturfokus

Showing the keyboard focus position clearly at all times is important, both for users with vision impairments as well as "power-users" who prefer to use the keyboard rather than the mouse. There should never be any confusion as to which control on the desktop has focus at any given time. You ought to be able to leave your computer with the focus on any widget in your application, then go off and phone your girlfriend or walk the dog until you've forgotten which widget you left it on. When you return, you should be able to tell straight away exactly which widget it was.

A visual focus indicator is an audio representation of the cursor position relative to the other objects on the desktop. This allows the user to move among objects interactively as the focus changes. The visual focus must be programatically exposed to assistive technologies. Note that in most cases, this is handled automatically by the ATK, without requiring you to do any additional work. However, you will need to be aware of this requirement when writing your own custom widgets, for example.

- Start focus at the most commonly used control. If no control in a window is deemed to be the "most" useful, start the focus at the first control in the window when that window is opened. Focus should not be started on the OK or Cancel buttons of a dialog even if they are the most commonly used controls, as they can always be activated immediately by pressing Enter or Escape.

- Show current input focus clearly at all times. Remember that in controls that include a scrolling element, it is not always sufficient to highlight just the selected element inside that scrolling area, as it may not be visible. See Keyboard Focus Examples.

- Show input focus only in the active window. Hide all primary visual focus indicators in all windows that do not have the focus and activation. If a single window has separate panes, only one pane should have the focus indicator, and focus indicators should be hidden in all other panes. If it's important to continue showing which item in an unfocused list is selected, for example, use a secondary focus indicator. See Keyboard Focus Examples.

- Provide appropriate feedback when the user attempts to navigate past the end of a group of related objects. When navigating a list, for example, stopping with audio feedback is usually preferable to moving the focus back to the first object in the list. Otherwise, users who are blind or have low vision may not realize they have returned to the beginning. In the case of a text search in a document, a dialog may pop up to indicate that the end of the document has been reached, and ask if you want to resume the search at the start of the document.

- Play the system default audio or visual warning signal when the user presses an inappropriate key, or when a navigation key fails to move the focus. For example, when the focus is on the first character in a text field and the user presses left arrow key, or the user tries to perform multiple selection in a single selection dialog. (Note that users with hearing difficulties should be able to configure a system-wide visual equivalent to the default warning sound.)

##### Beispiele für den Tastaturfokus

###### Example illustrating need to show focus clearly

The focused item in this window cannot be seen because it has been scrolled off-screen | One of the controls in this window has focus, but it's impossible to tell which...
The focused item in the list has been brought into view by scrolling the list | ...until you scroll the list, which reveals that one of its items is currently selected.
The list control in this example has a solid border indicating focus, whether its selected item is currently visible or not | If the list control itself is given a "focused" border, it's easy to tell it has focus even when the currently-selected item isn't visible.

###### Example illustrating use of secondary focus

Split-paned window in which both panes seem to have focus | In this example, it's impossible to tell just by looking which of the two panes actually has keyboard focus.
Split-pane window in which secondary highlighting is used to show which pane has focus | By using a secondary selection highlight color in the inactive pane, it's immediately obvious that the tree control has focus here...
Split-pane window in which secondary highlighting is used to show which pane has focus | ...and that the list control has focus here.

#### Timing

Interfaces in which things appear, disappear or happen according to some hard-coded time limit are often a hindrance to accessibility. Some users may read, type or react very slowly in comparison to others. If information they require is hidden before they are finished with it, or obscured by other information popping up which they didn't explicitly request, then your application will become very frustrating or even impossible to use.

- Don't hard-code timeouts or other time-based features. Examples include automatic scrolling when dragging an object towards the edge of a window, holding down a scrollbar button, or automatically expanding a tree node when an object is dragged over it and held for a short time. These should either be customizable in the application, the GNOME control center, or at worst, manually editable from the command line via a configuration file or GConf entry.

- Don't briefly show or hide information based on the movement of the mouse pointer. (Exception: system-provided features such as tooltips, which the user can configure on a system-wide level). If you must provide such features, make them optional so users can turn them off when a screen-review utility is installed.

#### Dokumentation

People with disabilities cannot use the application effectively if they do not have access to the required manuals and help files. Of particular importance is keyboard navigation, since this is the only way many users can navigate the application.

- Provide all documentation in an accessible format. ASCII text and HTML are both excellent formats for assistive technologies.

- Provide alternative text descriptions for all graphics in the documentation.

- Document all your application's accessibility features. Keyboard navigation and shortcuts are particularly important to document. Include an accessibility section in your documentation, where information on all the accessibility features can be found.

## Testen

There are several points of review to conduct before declaring an application accessible. Over the course of development you may want to consider automated testing techniques. Dogtail, for example, may complement your automated testing plan.

Dieser Abschnitt beschreibt eine Anzahl von Tests, die Sie manuell in einer Anwendung ausführen können, um deren Barrierefreiheit zu überprüfen. Das erfolgreiche Durchlaufen dieser Tests gewährleistet zwar nicht zwangsläufig, dass die Anwendung vollständig barrierefrei ist. Aber falls Ihre Anwendung an einem dieser Tests scheitert, dann sind weitere Aktionen notwendig, um die Barrierefreiheit zu verbessern.

### Tastatursteuerung

Die folgenden Tastaturoperationen sollten überprüft werden. Benutzen Sie in keinem Teil dieses Tests die Maus.

- Bewegen Sie den Fokus durch alle Menüleisten in der Anwendung und verwenden Sie dazu nur Tastaturbefehle.

- Überprüfen Sie, ob:

  - kontextabhängige Menüs korrekt dargestellt werden.

  - jegliche in der Werkzeugleiste sichtbare Funktionen auch über die Tastatur erreichbar sind.

  - Sie jedes Bedienelement im Client-Bereich der Anwendung und in Dialogfeldern ansprechen können.

  - Text und Objekte im Client-Bereich ausgewählt werden können.

  - alle Tastenkombinationen und Schnellzugriffe so funktionieren, wie gewünscht.

### Grafische Elemente

Testen Sie Ihre Anwendung mit einem Bildschrimleser und überprüfen Sie, ob:

- Beschriftung und Text korrekt gelesen werden, einschließlich in Menüs und Werkzeugleisten.

- Objektinformationen korrekt gelesen werden.

### Indikator für den visuellen Fokus

- Überprüfen Sie, ob der Indikator für den visuellen Fokus beim Bewegen durch die Objekte einfach zu erkennen ist.

- Die Navigation durch die Software und deren Menüs sollte deutlich sichtbar sein, wenn sich der Fokus verändert.

- Überprüfen Sie, ob der Bildschirmleser den Indikator für den visuellen Fokus verfolgt, wenn Sie eine Tastatur verwenden.

- Führen Sie ein Programm zur Vergrößerung der Bildschirminhalte aus (eine Bildschirmlupe), um sicherzustellen, dass die Bildschirmlupe den Indikator für den visuellen Fokus verfolgt, wenn Sie die Tastatur oder die Maus verwenden.

### Schriften und Text

- Ändern Sie die Schrift in der Anwendung und überprüfen Sie, ob die Einstellungen angewendet werden.

- Testen Sie die Anwendung, indem Sie die die Farben ändern und überprüfen, ob die Einstellungen wirksam werden.

- Falls Vergrößerung verfügbar ist, dann überprüfen Sie die Schrift, die Farbe und die Größe der Vergrößerungsoption.

### Farbe und Kontrast

- Geben Sie Bildschirmfotos auf einem einfarbigen Drucker aus und überprüfen Sie, ob alle Informationen sichtbar sind.

- Testen Sie Anwendungen in einer schwarzweißen Darstellung mit hohem Kontrast und überprüfen Sie, ob alle Informationen korrekt vermittelt werden.

- Testen Sie Ihre Anwendung daraufhin, ob sie mindestens drei Farbkombinationen als Thema unterstützt und dass Schemata in hohem Kontrast verfügbar sind, beispielsweise weiß auf schwarz oder gelb auf blau.

- Schalten Sie im GNOME-Kontrollzentrum die Einstellungen zu hohem Kontrast ein und überprüfen sie, ob Ihre Anwendungen diese Einstellungen akzeptiert.

- Testen Sie verschiedene Themen, um sicherzustellen, dass die Software mit allen verfügbaren Einstellungen funbktioniert.

### Klänge

Es sollte in der Anwendung eine Option geben, um akustische Benachrichtigungen visuell darstellen zu lassen.

Überprüfen Sie, ob die Ausgabe von Klängen korrekt funktioniert, indem Sie diese im GNOME-Kontrollzentrum einschalten und dann folgende Aktionen ausführen:

- Führen Sie eine Aktion aus, durch die eine akustische Warnung ausgelöst wird, und überprüfen Sie, ob die Anwendung wie erwartet funktioniert.

- Stellen Sie sicher, dass Ihre Anwendung korrekt reagiert, wenn Sie die Lautstärke erhöhen oder verringern.

- Überprüfen Sie, ob Warnmeldungen auch in einer lauteren Umgebung korrekt verstanden werden können.

### Animation

Stellen Sie sicher, dass eine Option zum Abschalten von Animationen zur Verfügung steht und diese wie erwartet funktioniert.

Schalten Sie die Animationen ab. Überprüfen Sie, ob alle Informationen immer noch korrekt vermittelt werden können.

### Tastaturfokus

- Testen Sie alle Meldungen, um zu überprüfen, ob der Benutzer ausreichend benachrichtigt werden kann, bevor eine Meldung verschwindet, mit der Option anzugeben, dass mehr Zeit notwendig ist.

- Stellen Sie sicher, dass eine Option zum Einstellen der Antwortzeit verfügbar ist und diese wie erwartet funktioniert.

### Dokumentation

Testen Sie Dokumentation im ASCII-Format mit einem Bildschirmleser, um sicherzustellen, dass diese klar und präzise von Hilfstechnologien gelesen werden kann.

Testen Sie HTML-Anwendungen mit einem Webbrowser und Bildschirmleser, um zu überprüfen, ob die Dokumentation barrierefrei ist und durch Hilfstechnologien verarbeitet werden kann.

Hinweis: Es gibt Richtlinien für Barrierefreiheit im Web auf http://www.w3.org/TR/WAI-WEBCONTENT/.

Überprüfen sie, ob in der Dokumentation folgende Informationen enthalten sind:

- State if the application does not support the standard keyboard access used by the OS.

- Identify if there are unique keyboard commands.

- Identify any unique accessibility features.

- Falls eine Aktion für die Maus dokumentiert ist, stellen Sie bitte sicher, dass eine Alternative für die Tastatur bereitsteht.

### Checkliste für Benutzeroberflächen

Dieser Abschnitt fasst die in den User Interface Guidelines for Supporting Accessibility gegebenen Richtlinien zusammen. Sie sollten diesen Abschnitt für weitere Informationen über die Einträge dieser Checkliste zu Rate ziehen.

Beim Testen einer Anwendung auf Barrierefreiheit sollten Sie alle Einträge in dieser Liste abarbeiten. Beachten Sie dabei, ob Ihre Anwendung jeden dieser Tests besteht oder scheitert, oder ob der jeweilige Test auf Ihr Programm nicht anwendbar ist.

#### Checkliste der allgemeinen Prinzipien

GP | Allgemeine Prinzipien | Pass/Fail/NA
--- | --- | ---
GP.1 | Jede Aktion, welche die Benutzerdaten oder Anwendungseinstellungen beeinflusst, kann rückgängig gemacht werden.
GP.2 | Alle Anwendungseinstellungen können auf ihre Standardwerte zurückgesetzt werden, ohne dass der Benutzer wissen muss, wie diese Einstellungen aussehen müssen.
GP.3 | Nach der Installation kann die Anwendung benutzt werden, ohne dass der Benutzer eine CD oder einen sonstigen Datenträger einlegen muss.
GP.4 | Die am häufigsten benutzten Funktionen befinden sich in der obersten Ebene der Menüstruktur.

#### Checkliste für die Tastaturnavigation

KN | Tastatursteuerung | Pass/Fail/NA
--- | --- | ---
KN.1 | Effizienter Tastaturzugriff ist auf alle Funktionsmerkmale der Anwendung möglich.
KN.2 | Alle Fenster haben einen logischen Aufbau für die Tastaturnavigation.
KN.3 | Die korrekte Reiteranrodnung wird für Bedienelemente verwendet, deren Aktivierungsstatus von Ankreuzfeldern, Radioknöpfen oder Umschalttasten abhängig ist.
KN.4 | Der Tastaturzugriff auf anwendungsspezifische Funktionen überschreibt keine vorhandenen Barrierefreiheits-Funktionsmerkmale des Systems.
KN.5 | Die Anwendung stellt eine oder mehrere Methoden zur Ausführung von Tastaturaufgaben bereit, wo immer es möglich ist.
KN.6 | Wo immer möglich, gibt es alternative Tastenkombinationen.
KN.7 | Es muss nicht umständlich nach häufig benutzten Tastaturoperationen gesucht werden
KN.8 | Die Anwendung erwartet keine wiederholten, gleichzeitigen Tastendrücke.
KN.9 | Die Anwendung stellt für alle Mausfunktionen entsprechende Bedienungsmöglichkeiten für die Tastatur bereit.
KN.10 | Jedes Objekt, das mit der Maus ausgewählt werden kann, lässt sich auch nur mit der Tastatur auswählen.
KN.11 | Jedes Objekt, das mit der Maus verschoben oder dessen Größe geändert werden kann, lässt sich ebenso auch nur mit der Tastatur verschieben oder dessen Größe ändern.
KN.12 | Die Anwendung nutzt keine generellen Navigationsfunktionen oder Auslöseroperationen.
KN.13 | Alle tastaturbezogenen Menüs, Fenster und Minihilfen erscheinen nahe des Objekts, auf welches sie sich beziehen.

#### Checkliste zur Maus-Interaktion

MI | Maus-Interaktion | Pass/Fail/NA
--- | --- | ---
MI.1 | Keine Operation ist abhängig von der Bedienung der rechten oder mittleren Maustaste.
MI.2 | Alle Mausaktionen können abgebrochen werden, bevor sie abgeschlossen werden.
MI.3 | Bei Zieh- und Ablegevorgängen wird visuelle Rückmeldung bereitgestellt
MI.4 | Der Mauszeiger gerät nie unter unmittelbare Kontrolle der Anwendung und seine Bewegungsfreiheit wird nie auf den Bidschirmbereich der Anwendung beschränkt.

#### Checkliste für grafische Elemente

GE | Grafische Elemente | Pass/Fail/NA
--- | --- | ---
GE.1 | Es gibt keine fest codierten grafischen Attribute wie »line«, »border« oder »shadow thickness«.
GE.2 | Alle mehrfarbigen grafischen Elemente können auch nach Möglichkeit einfarbig dargestellt werden.
GE.3 | Alle interaktiven Elemente der grafischen Oberfläche sind eindeutig von statischen Elementen unterscheidbar.
GE.4 | Eine Option zum Verbergen eher unwichtiger grafischer Elemente wird bereitgestellt.

#### Checkliste für Schriften und Text

FT | Schriften und Text | Pass/Fail/NA
--- | --- | ---
FT.1 | Schriftstile und -größen sind nicht fest codiert.
FT.2 | Eine Option zum Abschalten grafischer Texthintergründe steht zur Verfügung.
FT.3 | Alle Bezeichnungen ergeben auch außerhalb des Kontextes einen Sinn.
FT.4 | Beschriftungen werden innerhalb eines Fensters nicht mehrfach verwendet.
FT.5 | Die Positionierung von Beschriftungen ist innerhalb der Anwendung konsistent.
FT.6 | Alle statischen Textbschriftungen, die andere Steuerungen bezeichnen, enden mit einem Doppelpunkt.
FT.7 | Statische Textbeschriftungen, die andere Steuerungen bezeichnen, stehen unmittelbar vor diesen Steuerungen in der Anordnung.
FT.8 | Eine Alternative zu »WYSIWIG« steht zur Verfügung. Dies wäre zum Beispiel die Festlegung verschiedener Schriften für Bildschirm und Drucker in einem Texteditor.

#### Checkliste für Farben und Kontrast

CC | Farbe und Kontrast | Pass/Fail/NA
--- | --- | ---
CC.1 | Anwendungsfarben sind nicht fest kodiert, sondern werden entweder vom aktuellen Desktop-Thema oder von der Anwendungseinstellung gezeichnet.
CC.2 | Farben werden lediglich als Erweiterung der Darstellung verwendet und nicht als einzige Möglichkeit für die Darstellung von Informationen oder Aktionen.
CC.3 | Die Anwendung unterstützt alle Themen und Einstellungen mit hohem Kontrast.
CC.4 | Die Software ist nicht von einem bestimmten Thema mit hohem Kontrast abhängig.

#### Checkliste zur Vergrößerung

MG | Vergrößerung | Pass/Fail/NA
--- | --- | ---
MG.1 | Die Anwendung verfügt über eine Funktion zur Vergrößerung des Arbeitsbereiches.
MG.2 | Die Anwendung stellt eine Option zur Skalierung des Arbeitsbereiches zur Verfügung.
MG.3 | Die Funktionalität der Anwendung wird durch Vergrößerung oder Skalierung nicht beeinträchtigt.

#### Checkliste zu Klängen

AU | Klänge | Pass/Fail/NA
--- | --- | ---
AU.1 | Klänge werden nicht als einzige Möglichkeit für die Darstellung von Informationen oder Aktionen verwendet.
AU.2 | Der Benutzer kann die Frequenz und die Lautstärke aller Klänge und Warntöne einstellen.

#### Checkliste zu Animationen

AN | Animation | Pass/Fail/NA
--- | --- | ---
AN.1 | Es gibt keine blitzenden oder blinkenden Elemente mit einer Frequenz zwischen 2 Hz und 55 Hz.
AN.2 | Jedes Blitzen oder Blinken ist auf kleine Bereiche des Bildschirms beschränkt.
AN.3 | Falls Animation verwendet wird, dann ist eine Option zum Abschalten verfügbar, bereits bevor die Animation erstmals benutzt wird.

#### Checkliste für den Tastaturfokus

KF | Tastaturfokus | Pass/Fail/NA
--- | --- | ---
KF.1 | Wenn ein Fenster geöffnet wird, dann liegt der Fokus zunächst auf dem am häufigsten benutzten Bedienelement.
KF.2 | Die aktuelle Position des Fokus wird jederzeit klar und deutlich dargestellt.
KF.3 | Der Eingabefokus wird nicht in mehreren Fenstern gleichzeitig angezeigt.
KF.4 | Es werden geeignete akustische oder visuelle Rückmeldungen bereitgestellt, wenn der Benutzer versucht, an das Ende oder den Anfang einer Gruppe aufeinander bezogener Elemente zu navigieren.
KF.5 | Das Standardsignal für akustische oder visuelle Warnungen wird abgespielt, wenn der Benutzer eine in jeweiligen Fall nicht anwendbare Taste drückt.
KF.6 | Es gibt genügend Audio-Informationen für den visuellen Fokus, über die dem Benutzer mitgeteilt werden kann, was als Nächstes zu tun ist.
KF.7 | Bei der Nutzung von Hilfstechnologien, wie einem Bildschirmleser oder einer Braille-Zeile, ermittelt das Programm die Position und den Inhalt des visuellen Fokus-Indikators.

#### Timing-Checkliste

TM | Timing | Pass/Fail/NA
--- | --- | ---
TM.1 | Es gibt keine fest codierten Zeitüberschreitungen oder sonstigen zeitbasierten Funktionsmerkmale in der Anwendung.
TM.2 | Das Anzeigen oder Verbergen wichtiger Informationen wird durch die Bewegungen des Mauszeigers nicht beeinflusst.

#### Dokumentations-Checkliste

DC | Dokumentation | Pass/Fail/NA
--- | --- | ---
DC.1 | Jegliche Dokumentaiton liegt in einem barrierefreien Format vor, mit einer alternativen Beschreibung in Textform für alle Abbildungen und Diagramme.
DC.2 | Die Dokumentation enthält einen Abschnitt, in dem die Barrierefreiheits-Funktionsmerkmale der Anwendung beschrieben werden.

### GOK (GNOME-Bildschirmtastatur)

Your application should be usable via gok; key input should be generated entirely by gok, not the keyboard. The aim here would be to work with your application and the desktop in general, ensuring any type of character input can be performed with the on-screen keyboard.

The gok application ships with the GNOME Desktop so should already be present. For full documentation, refer to the official gok site.

Follow these steps to verify the correct operation of gok with your application:

1. Anmelden an der GNOME-Arbeitsumgebung

2. Ausführen von gok

3. Starten Ihrer Anwendung

4. Provide input to your application with a pointing device (e.g., mouse or head-tracker) and gok.

5. Work using the auto-completion and word prediction features of gok.

6. Verify that gok enables and disables the Menus and Toolbars buttons based on the kind of application invoked; for example, the Menus and Toolbars buttons are disabled for the 'Font properties' capplet, but the same buttons are enabled for the Gedit application.

7. Verify that the gok on-screen keyboard provided by the Compose button can be used to type in any text for the selected application; run Gedit, click on the text area, and then click on the Compose button in gok. Select the required keys from the on-screen keyboard. The characters should appear in the Gedit text area.

8. Verify that the Launcher button allows the user to launch any of the Terminal, Web Browser or Text Editor applications.

9. Verify that the Activate button allows the user to activate any of the currently running application windows on the user's desktop, including GNOME panels and the GNOME desktop.

10. Verify that the Menus button lists all the available menus in the current application. Verify that clicking on a menu button displays the sub-menu and menu items contained within the sub-menu. Finally, verify that clicking on a menu item activates the menu item. For example, click on the Help Browser application and click on the Menus button. The GOK window now displays the File, Go and Help buttons (the Help Browser menus). Click on the File button and it displays the New Window and Close Window buttons (menu items).

11. Verify that the Toolbars button lists all the available buttons in the application toolbar. For example, click on the Help Browser application and then click on the Toolbars button. The GOK window now displays the Back, Forward and Home buttons.

12. Verify that the UI Grab button displays all the button objects for the selected application window. For example, open the 'Font Properties' capplet and click on the UI Grab button in the GOK window. The GOK window should now display the names of the buttons in the capplet - Sans, Sans-serif, Close and Help.

### Accerciser

Accerciser und die GNOME-Barrierefreiheits-Architektur

Accerciser ist ein in Python geschriebenes Programm zur Untersuchung der Barrierefreiheit für die GNOME-Arbeitsumgebung. Es benutzt AT-SPI zum Inspizieren und Steuern von Widgets. So können Sie überprüfen, ob eine Anwendung korrekte Informationen für Hilfstechnologie und automatisierte Testumgebungen bereitstellt. Accerciser verfügt über eine einfache Plugin-Schnittstelle, die Sie zur Erstellung eigener Ansichten auf Barrierefreiheitsinformationen nutzen können. Die vollständige Dokumentation finden Sie im offiziellen Accerciser-Handbuch. Für eine Demonstration von Accerciser und PyATSPI (Python-wrappered access and usage of AT-SPI) lesen Sie bitte diesen Artikel. Eine exzellente Beschreibung vom Autor selbst finden Sie im Artikel Make Your Application Accessible with Accerciser.

Accerciser ist ein effektiver Ersatz für das ältere at-poke-Werkzeug.