# GNOME アクセシビリティ開発者ガイド

## アクセシビリティとは何か?

アクセシビリティとは、障害のある人々が豊かな日常生活を送るのを支援するということを意味しています。その生活における活動は、就労および、サービス、製品、情報の利用を含んでいます。GNOME には、障害のある人々が GNOME ユーザー環境のすべての機能を利用することを可能とするライブラリやサポート・フレームワークがあります。

永続的または一時的障害のある人々は、必要に応じて支援技術(音声インターフェース、スクリーンリーダー、代替入力デバイスなど)と連携させることによって、GNOME デスクトップおよびそのアプリケーションを使用することができます。支援技術はまた、家庭やオフィスの外でコンピューターを使用する人々にとっても有用なものです。たとえば、渋滞に巻き込まれているときに音声入出力を利用して電子メールのチェックをすることもできます。

支援技術は、アクセシビリティ・ツールキット (ATK) API を経由してアプリケーションから情報を受けとります。その API は GNOME リポジトリの atk モジュールにて見つけることができます。アクセシビリティ API のサポートが GNOME ウィジェットに組み込まれているために、あなたの GNOME プログラムは、余計な手間を施さなくても支援技術とうまく動作するはずです。たとえば、支援技術は、通常の方法で (例として `gtk_label_set_text()` や `gtk_button_new_with_label()` などの関数呼び出しにより) プログラム内に設定したウィジェットのラベルを自動的に読み取ります。また支援技術は、あるウィジェットに関連付けられたツールチップ・テキストが存在するかどうかを調べ、ユーザーに対してウィジェットの説明をする際にそれを利用したりします。

しかしながら、もう一手間を加えることで、プログラムは支援技術とより円滑に動作することが可能となります。こうした作業によって、個々のユーザーを手助けするだけでなく、あなたの生産物を政府および教育市場にとってより魅力あるものにするでしょう。そうした市場の多くは今日、法令に基づき、アプリケーションがアクセシブルであることを要求しています。

### 障害の種類

アメリカ合衆国だけでも、推定 30,000,000 の人々がアクセシブルでないデザインのためにコンピューターの利用を妨げられていると言われています。世界全体では、ワールドワイドウェブを利用する人の約 8% が何らかの障害を持っています。障害は次のカテゴリのいずれかに分類されます:

- 視覚障害 - 視覚障害は、ロービジョン (とりわけ、かすみ目、極度の遠視または近視、色覚異常、視野狭窄を含む) から全盲まで及びます。視覚障害のあるユーザーにとって、テキストのサイズや色を選択できなかったり、手と目の協調動作が必要になったり (マウスを動かすなど) するのは、厄介なものになります。

- 運動障害 - 筋制御機能の乏しい人や身体虚弱者は、一般的なキーボードやマウスを使う上で困難を感じることがあります。たとえば、同時にふたつのキーを押したままにすることができなかったり、あるいはキーを誤って押してしまったりということがあります。

- 聴覚障害 - 聴覚障害は、音は聞こえるが話し言葉を識別できないという状態から重度難聴まで及びます。重要な情報を音だけで伝えることのあるアプリケーションは、聴覚障害のユーザーにとって問題となります。

- 認知障害および言語障害 - これは、発達性読み書き障害 (ディスレクシア) から、記憶障害や問題解決における障害、話し言葉や書き言葉の理解および使用に関わる障害まで及びます。こうしたユーザーにとって、画面の表示が複雑だったり一貫性が無かったり、あるいは言葉遣いが適切でなかったりすると、コンピューターの操作が難しくなります。

- けいれん性疾患 - 敏感なユーザーは、ある特定の光や音のパターンに対しててんかん発作を起こすことがあります。

### How Accessibility Works in GNOME

The Accessibility Toolkit (ATK) describes a set of interfaces that need to be implemented by GUI components to make them accessible. The interfaces are toolkit-independent - implementations could be written for any widget set, such as GTK, Motif or Qt.

The implementation for the GTK widgets is done via the GtkAccessible class. It is the base class for accessible implementations for GtkWidget subclasses. It is a thin wrapper around AtkObject, which adds facilities for associating a widget with its accessible object. Those parts of your application that use standard GTK widgets will have a basic level of accessibility, without you having to modify your application at all.

Most assistive technologies running on other desktops have historically found it necessary to maintain a complex off-screen model of the desktop applications, based on snooping of OS events, use of unsupported OS and application features and API, and other highly non-portable techniques. This has made assistive technology support somewhat "brittle" and highly OS- and application-specific, even application-version specific. In contrast, on the GNOME Desktop, all the information required by the ATs is provided by the running applications, via the GNOME Accessibility Framework, to a toolkit-independent Service Provider Interface (SPI). The SPI provides a means for UNIX-based ATs, such as screen readers and screen magnifiers, to obtain accessibility information from running applications via a consistent, stable API, and can eliminate the need for an off-screen model in many cases. Accessibility support for applications is "built in" to application toolkits via toolkit-appropriate APIs (for instance, ATK for most native C applications and the Java Accessibility API for Java apps), and exported to the common "AT-SPI" interface via the relevant "bridge" (see diagram below).

GNOME's built-in accessibility support means that applications created using stock GNOME widgets get support for assistive technologies "for free", provided the widgets are not used in unusual ways which conflict with this built-in support.

A gtk+/GNOME widget is accessible if its use follows the general accessibility guidelines elsewhere in this document, and it implements the ATK interfaces appropriate to its role in the user interface. ATK implementations are provided for the "stock" GNOME toolkit widgets (i.e. non-deprecated gtk+ and GNOME widgets), and in many cases new widgets which derive trivially from existing GTK+ or GNOME widgets will also inherit suitable accessibility support.

Though GNOME's built-in accessibility support provides significant functionality without any accessibility-specific code changes on the part of the application, applications can often improve on the default descriptions provided for some of the widgets, and tailor them to that widget's specific purpose in your application, via straightforward calls to ATK methods in the application. For instance, in most cases applications should add or change the textual descriptions for these widgets with the appropriate ATK function call, so that an assistive technology can describe their purpose or state to the user. See Coding Guidelines for Supporting Accessibility for more information.

If your application uses custom widgets, you may have to do some work to expose those widgets' properties to assistive technologies. See Making Custom Components Accessible and Examples that Use the Accessibility API for more information.

For additional, in-depth information regarding GTK/GTK+, see the GTK+ Reference Manual, the outdated GTK+ 2.0 Tutorial and the official GTK+ FAQ.

### Developer Quick Start

Here are some common starting points:

#### How do I check to see if my application is accessible or not?

To start right in, see Making a GNOME Application Accessible - Overview. For a pre-coding 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.

#### What are the common pitfalls?

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

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

An abbreviated listing of common ATK calls can be found here.

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

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

#### Introducing ATK, AT-SPI and GTK+

GNOME Accessibility Architecture

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.

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. Its GtkAccessible class is the base class for accessible implementations for GtkWidget subclasses. It is a thin wrapper around AtkObject, which adds facilities for associating a widget with its accessible object.

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

### Making a GNOME Application Accessible - Overview

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 assistive technology can describe their purpose or state to the user. See Coding Guidelines for Supporting Accessibility for more information.

If your application uses custom widgets, you may have to do some work to expose those widgets' properties to assistive technologies. See Making Custom Components Accessible and Examples that Use the Accessibility API for more information.

### Coding Guidelines for Supporting Accessibility

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:

  #### Providing an accessible description for a GtkButton

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

- Use `atk_image_set_description()` to provide a text description for all images and icons in your program.

- If several components form a logical group, try to put them in one container.

- 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):

  #### Relating a GtkLabel to a 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));
      }

- If you create a custom widget, make sure it supports accessibility. Custom components that are descendants of other GTK widgets should override inherited accessibility information as necessary. For more information, see Making Custom Components Accessible.

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

### The Accessibility API

Here are a few of the basic API calls you may need to use in your application to ensure it works well with assistive technologies. The full accessibility API is extensive, to allow you to write your own accessible custom widgets, for example.

### Commonly used ATK API calls

API | Description
`AtkObject* gtk_widget_get_accessible (GtkWidget*)` | Returns the accessible object that describes the specified GTK widget to an assistive technology.
`void atk_object_set_name (AtkObject*, const gchar*)` | Sets the name of the accessible object. For example, if the object is a graphical button that quits the application when pressed, the name might be "Quit".
`void atk_object_set_description (AtkObject*, const gchar*)` | Sets the textual description of the accessible object. For example, if the object is a graphical "Close" button, the description might be "Closes the window".
`AtkRelation* atk_relation_new (AtkObject**, gint, AtkRelationType)` | Creates a new relation between the specified key and the specified list of target objects. A relationship normally indicates to the assistive technology that one widget is somehow related to another. For example, that a particular GtkLabel widget is the caption for a GtkTreeView in the same window.
`void atk_image_set_description (AtkImage*, const gchar*)` | Sets the textual description of the accessible image object. For example, if the object is a thumbnail of a virtual desktop in a panel applet, the description might be "Image showing window arrangement on desktop 1".

### Examples that Use the Accessibility API

As noted earlier, you should have little or no work to do to make your application accessible if you use the GTK widget set, or any other widget library that implements the ATK interfaces. The two most common things you may have to do in this case are:

- provide descriptions of some controls and images using `atk_object_set_description()` or `atk_image_set_description():`

  #### Setting the accessible description for a button

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

- Specify relationships between any unusual groupings of widgets using `atk_relation_new()` and `atk_relation_set_add()`:

  #### Specifying accessible relationship between two controls

      {
        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.

#### 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);

   where `_my_focus_tracker()` is a function with this prototype:

       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 hierarchy 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`.

#### Implementing an ATK Object

##### 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 for a Specific Object

All `GObject`s 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

`AtkObject`s are `GObjects`, and all `GObject`s 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`.

##### Class/Instance Initializers

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.

2. Requires a `parent->init`, `parent->notify_gtk`, or `parent->finalize` function.

   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.

   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:

      ###### A custom `notify_gtk()` function

          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:

      ###### A custom `finalize()` function

          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);
          }

### Making Custom Components Accessible

Adding ATK support to your custom widget will assure its cooperation with the accessibility infrastructure. These are the general steps that are required:

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

### アクセシビリティをサポートするユーザーインターフェース・ガイドライン

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!

#### General

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.

- Provide Undo for every action that changes the user's data or the application's settings. If possible, provide more than one level of undo and redo, and a history list to allow preview of what actions will be undone.

- Provide commands to restore default settings. If a particular setting could make the application completely unusable for an individual, e.g. by making the fonts very small, it would be useful to provide an option to restore the default settings outside the application itself. This could be done using a command line switch, for example.

- Help prevent users from doing the wrong thing. This is particularly important for actions that could be done by accident (e.g. mouse actions) or that cannot easily be undone (e.g. overwriting a file). Consider using confirmation dialogs or forcing the user to go into a particular mode to perform potentially destructive actions.

- Minimize users' memory load. For example, let the user view multiple documents at the same time, and ensure online help or other instructions can remain visible while they carry out the procedure being described. Allow them to copy any information that is displayed, and paste it anywhere that data can be entered.

- Don't make users insert disks. Depending on a user's particular disability, they may find it difficult to physically insert or change a disk, or they may find it hard to identify the correct disk in the first place. If your application is installed from CD-ROM, provide an option to copy all the files that will be required onto the user's hard drive.

- Don't place frequently used functions deep in a menu structure. Whether you're using a mouse, keyboard or some other input device, deeply-nested menu items are best avoided. As well as the burden of remembering where to find them, they are always more difficult and time-consuming to access.

- Don't lead users through unnecessary steps. For example, wizards are useful for users who have trouble handling large numbers of options at one time, but other users may need to minimize the amount of time or keystrokes they use. Such users benefit from being able to skip unnecessary steps or go directly to the one they need. Consider providing a Finish button in wizards that skips right to the end and assumes default responses for the intermediate steps. If the process has many steps, consider asking the user at the start if they want to run through all the steps, or just the most commonly-used ones.

#### キーボード・ナビゲーション

A well-designed keyboard user interface plays a key role when you are designing accessible software. Blind users can navigate software more effectively using the keyboard, because using the mouse depends on visual feedback of the mouse pointer location. Also, mobility impairments can prevent a user from successfully navigating using the mouse, because of the fine motor control skills required.

It is therefore important to make all mouse actions available from the keyboard, and include keyboard access to all toolbars, menus, links and buttons. Every function your application provides should be available using the keyboard alone. Hide your mouse while you're testing your application if you have to!

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.

#### マウス操作

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.

##### Mouse Interaction Examples

###### Example of "no-drop" pointer from CDE/Motif

Example of an "invalid drop target" pointer shape

#### グラフィック要素

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. GTK 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.

#### フォントとテキスト

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 impairments 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.

##### Fonts and Text Examples

###### 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 | Spinbox control with label to its left Spinbox control with label to its left

#### 色とコントラスト

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.

- Ensure your application is not dependent on a particular high-contrast theme. Test it with different high-contrast themes to ensure your application respects the settings.

##### Color and Contrast Examples

###### Example illustrating redundant use of color

Example showing changes in stock price using color only | This display could cause problems for a red-green color-blind user (color-blindness affects as many as 1 in 7 males in some parts of the world). The lack of contrast between the red text and black background would also make it hard to read for a user with low vision, even with a screen magnifier.
Example showing changes in stock price using both color and arrows | 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 Preferences dialog.

#### 拡大表示

Many users, even those not visually impaired, benefit from magnification of text and graphics. However, without magnification, a visually impaired user may not be able to access and use the program at all.

- Provide the ability for the user to magnify the work area.

- Provide options in the application to scale the work area. Users need to have an option to magnify the work area 150% to 400% or more. Test the application to confirm the object you are viewing is not affected by changing the magnification settings.

#### 音声

People who have difficulty hearing, as well as those who work with the sound on their computers turned off, will be disadvantaged if your application relies on sound to convey information. In general, make sure that the user is able to have any audible information conveyed in other ways.

- Don't assume that a user will hear audio information. This applies as much to users with broken soundcards as it does to those with hearing impairments!

- Don't use audio as the only means of conveying information. Give the user the option to have all audio information provided in a visual way as well. This includes providing closed captioning or transcripts for any important spoken sound clips.

- Allow users to configure frequency and volume of all warning beeps and other sounds. This includes being able to turn off sound altogether.

#### アニメーション

Used sparingly, animation can be useful for drawing attention to important information in your application - and it can look cool, too. However, it can be problematic for some users, so make sure they can turn it off.

- Don't use flashing or blinking elements having a frequency greater than 2 Hz and lower than 55 Hz. This includes text as well as any graphical objects. Anything in this frequency range may cause particular problems for users susceptible to visually-induced seizures. Note that there is no "safe" frequency, though. If flashing is essential, you should use the system's cursor blink frequency (which should itself be customizable), or allow users to configure the frequency themselves.

- Don't flash or blink large areas of the screen. Small areas are less likely to trigger seizures in those susceptible to them.

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

#### キーボード・フォーカス

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 programmatically 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.)

##### Keyboard Focus Examples

###### 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.

#### タイミング

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.

#### ドキュメンテーション

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.

## テスト

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. LDTP, for example, may complement your automated testing plan.

本節では、アプリケーションのアクセシビリティを検証するために手動で行われるいくつかのテストについて説明します。すべてのテストをパスしたからといって、必ずしもそのアプリケーションが十分にアクセシブルであるというわけではありませんが、いずれかのテストに失敗するならば、それはアクセシビリティの面で改良の必要性があるということになります。

### キーボード・ナビゲーション

次のキーボード操作をテストしてください。このテストではマウスを使用してはいけません。

- キーボードだけを使用し、アプリケーションのすべてのメニューバーを通してフォーカス移動を行ってください。

- 以下のことを確認してください:

  - コンテキストに依存するメニューが正しく表示される。

  - キーボードを使用し、ツールバー上の任意の機能を実行できる。

  - アプリケーションおよびダイアログボックスのクライアント領域において、すべてのコントロールを操作できる。

  - クライアント領域内のテキストおよびオブジェクトが選択可能である。

  - 任意のキーボード・エンハンスメントあるいはショートカットが設計通りに機能する。

### グラフィック要素

スクリーンリーダーを使用し、以下のことを確認してください:

- メニューおよびツールバーを含め、ラベルとテキストが正しく読み上げられる。

- オブジェクトの情報が正しく読み上げられる。

### ビジュアル・フォーカス・インジケーター

- オブジェクト間を移動する際に、ビジュアル・フォーカス・インジケーターが見つけやすいことを確認してください。

- フォーカスが移動する際に、ソフトウェアおよびメニューを通じたキーボード・ナビゲーションをはっきりと目で追うことができる。

- キーボード操作に伴うビジュアル・フォーカス・インジケーターの移動をスクリーンリーダーが追跡していることを確認してください。

- (利用可能であれば) 画面拡大プログラムを実行し、キーボードおよびマウス操作に伴うビジュアル・フォーカス・インジケーターの移動を拡大鏡が追跡していることを確認してください。

### フォントとテキスト

- アプリケーション内でフォントを変更し、設定が維持されていることを確認してください。

- アプリケーションの配色変更をテストし、すべての設定が維持されていることを確認してください。

- 拡大機能が利用可能な場合、拡大オプションを使用し、フォント、色および大きさのテストを行ってください。

### 色とコントラスト

- スクリーンショットを白黒プリンターで印刷し、すべての情報が視認できることを確認してください。

- 白黒のハイコントラスト設定を使用してアプリケーションをテストし、すべての情報が正しく伝わることを確認してください。

- アプリケーションが少なくとも3つのカラースキームを提供していること、およびハイコントラストの配色 (たとえば黒地に白あるいは青地に黄) が利用可能であることをテストしてください。

- Turn on high-contrast settings in the GNOME Control Center and confirm that the application respects these settings.

- 使用可能なすべての設定でソフトウェアが動作できるように、様々なテーマをテストしてください。

### 音声

音声アラートを視覚的に表示するオプションをアプリケーションに用意してください。

GNOME コントロール・センターでサウンド設定を有効化し、音声機能が正しく動作することをテストしてください。また、以下の動作確認を行ってください。

- 音声アラートを発生させる動作を実行し、アプリケーションが設計通りに機能することを確認してください。

- 音量の上げ下げを行いながらアプリケーションが正しく動作することを確認してください。

- 騒がしい作業環境においても、警告メッセージ、警告アラートが正しく聞き取れることを確認してください。

### アニメーション

アニメーションを停止させるオプションが利用可能であること、およびその状態でアプリケーションが設計通りに動作することを確認してください。

アニメーション機能をオフにしても、すべての情報が正しく伝わることを確認してください。

### キーボード・フォーカス

- すべてのメッセージを検証し、メッセージがタイムアウトする前に情報が伝わること、および必要に応じてメッセージの表示時間を延長するオプションがあることを確認してください。

- 応答時間を調整するオプションが含まれていることを確認し、アプリケーションが設計通りに動作することを確かめてください。

### ドキュメンテーション

スクリーンリーダーを使って ASCII テキストのドキュメントを検証し、ドキュメントの情報が明瞭かつ的確であること、また支援技術による読み取りが可能であることを確認してください。

ウェブブラウザーとスクリーンリーダーを使って HTML 形式のアプリケーションを検証し、ドキュメントが支援技術に対してアクセシブルであることを確認してください。

注: Web アクセシビリティのガイドラインが http://www.w3.org/TR/WAI-WEBCONTENT/ で手に入ります。

以下の情報がドキュメントに盛り込まれていることを確認してください:

- OS が使用する標準的なキーボード・アクセスをアプリケーションがサポートしない場合、それを明記する。

- 固有のキーボード・コマンドがある場合、それを明記する。

- あらゆる固有のアクセシビリティ機能について明記する。

- マウス動作が文書化されている場合、キーボードによる代替手段を設ける。

### ユーザーインターフェースのチェックリスト

本節では、アクセシビリティをサポートするユーザーインターフェース・ガイドラインにおいて提示した指針の概要を述べます。ここにあげられたチェックリストの各項目についてより詳細に知りたい場合は、ガイドラインの方を参照してください。

アクセシビリティについてアプリケーションをテストする場合、本リストの各項目について一通り確認してください。アプリケーションがテストに成功するか失敗するか、あるいはテストを適用できないかを記してください。

### 一般原則に関するチェックリスト

GP | 一般原則 | 成功/失敗/NA
GP.1 | ユーザーのデータやアプリケーションの設定を変更するあらゆる動作は、元に戻すことができる。
GP.2 | アプリケーションのすべての設定は、ユーザーがそのデフォルト値を覚えていなくてもデフォルトの状態に戻すことができる。
GP.3 | アプリケーションをインストールした後は、いつでもディスクや CD を挿入することなく使用できる。
GP.4 | 最も頻繁に利用される機能は、メニューのトップレベルで見つけることができる。

### キーボード・ナビゲーションのチェックリスト

KN | キーボード・ナビゲーション | 成功/失敗/NA
KN.1 | アプリケーションのすべての機能に対する効率的なキーボード・アクセスが提供されている。
KN.2 | すべてのウィンドウにおいて、理にかなったキーボード・ナビゲーション・オーダーが適用されている。
KN.3 | あるチェックボックスやラジオボタン、トグルボタンの状態に依存する有効状態を持つコントロールに対して適切なタブ・オーダーが使われている。
KN.4 | アプリケーション固有の機能に対するキーボード・アクセスが、既に存在するシステムレベルのアクセシビリティ機能を上書きしていない。
KN.5 | 可能な限り、キーボードによる作業を行うための方法が1つ以上提供されている。
KN.6 | 可能な限り、代替となるキーの組み合わせによる操作が利用できる
KN.7 | 頻繁に実行されるキーボード作業に対して、やりにくい操作が割り当てられていない。
KN.8 | アプリケーションが、繰り返しキーを押したり、同時に複数のキーを押したりする操作を要求しない。
KN.9 | すべてのマウス機能に対して同等のキーボード機能が提供されている。
KN.10 | マウスを使って選択できる任意のテキストやオブジェクトは、キーボードだけでも同様に選択可能である。
KN.11 | マウスを使用してサイズ変更したり移動したりできる任意のオブジェクトは、キーボードだけでも同様にサイズ変更や移動が可能である。
KN.12 | ある処理を起動させるために、一般的なナビゲーション機能を使用していない。
KN.13 | キーボードから呼び出したあらゆるメニューやウィンドウ、ツールチップは、関連するオブジェクトの近くに表示される。

### マウス操作のチェックリスト

MI | マウス操作 | 成功/失敗/NA
MI.1 | No operations depend on input from the right or middle mouse buttons.
MI.2 | すべてのマウス操作は、それが完了する前に取り消すことができる。
MI.3 | ドラッグ・アンド・ドロップ操作を行っている間は、その反応が視覚的に表示される。
MI.4 | アプリケーションの制御下においてマウスポインターが突然別の場所に移動しない。そうでなければ、マウスポインターの移動がアプリケーションの画面内に制限されている。

### グラフィック要素のチェックリスト

GE | グラフィック要素 | 成功/失敗/NA
GE.1 | 線や枠線、影の濃淡といったグラフィック要素の属性がハードコードされていない。
GE.2 | できる限り、多色のグラフィック要素が単色の設定でも表示可能である。
GE.3 | すべての対話型 GUI 要素は、静的な GUI 要素と容易に区別することができる。
GE.4 | 重要でないグラフィック要素を非表示にするオプションが提供されている。

### フォントとテキストのチェックリスト

FT | フォントとテキスト | 成功/失敗/NA
FT.1 | フォントのスタイルやサイズがハードコードされていない。
FT.2 | テキストの背景画像を消すオプションが提供されている。
FT.3 | すべてのラベルが、そのコンテキストから切り離されても意味のわかりやすい名称を与えられている。
FT.4 | 1つのウィンドウ内に同じ名称のラベルが複数使われていない。
FT.5 | ラベルの配置方法がアプリケーションを通じて一貫している。
FT.6 | 他のコントロールを特定するためのテキストラベルはすべてコロン (:) で終端している。
FT.7 | 他のコントロールを特定する静的なテキストラベルは、タブオーダーにおいてそのコントロールの直前に来る。
FT.8 | WYSIWYG の代替機能が提供されている。たとえば、テキストエディター上で異なるスクリーンフォントとプリンターフォントが指定できる。

### 色とコントラストのチェックリスト

CC | 色とコントラスト | 成功/失敗/NA
CC.1 | アプリケーションの配色がハードコードされておらず、使用しているデスクトップのテーマかアプリケーションの設定に基づいて描画されている。
CC.2 | 色が拡張機能としてのみ使用されており、情報や動作を伝える唯一の手段として使用されていない。
CC.3 | 利用可能なすべてのハイコントラストのテーマや設定をサポートしている。
CC.4 | 特定のハイコントラストのテーマや設定に依存していない。

### 拡大表示のチェックリスト

MG | 拡大表示 | 成功/失敗/NA
MG.1 | 作業領域を拡大表示できる機能がアプリケーションに備わっている。
MG.2 | 作業領域を倍率表示するオプションがある。
MG.3 | アプリケーションの機能が、拡大表示や倍率設定によって左右されない。

### 音声のチェックリスト

AU | 音声 | 成功/失敗/NA
AU.1 | サウンドが、ある情報を伝達する唯一の手段として使用されていない。
AU.2 | ユーザーが、あらゆるサウンドや警告音の頻度および音量を設定できる。

### アニメーションのチェックリスト

AN | アニメーション | 成功/失敗/NA
AN.1 | 2ヘルツ超、55ヘルツ未満の周波数で点滅する要素が存在しない。
AN.2 | あらゆる点滅要素の使用が、画面の小さな領域内に限定されている。
AN.3 | アニメーションが使用される場合、表示の前にアニメーション機能を停止させるオプションが利用可能である。

### キーボード・フォーカスのチェックリスト

KF | キーボード・フォーカス | 成功/失敗/NA
KF.1 | ウィンドウを開くと、最もよく使われるコントロールにフォーカスが当たっている。
KF.2 | 現在の入力フォーカスの位置が、常にはっきりと表示される。
KF.3 | 入力フォーカスが、常に1つのウィンドウのみに表示される。
KF.4 | ユーザーが、一連のオブジェクト群において終端を越えて先頭 (あるいはその逆) にフォーカスを移そうとする場合、適切な音声または視覚的応答が与えられる。
KF.5 | ユーザーが誤ったキー操作を行った場合、デフォルトの音声または視覚的警告が発生する。
KF.6 | ユーザーが次に何をすればよいのかわかるように、ビジュアル・フォーカスに対する十分な音声情報が用意されている。
KF.7 | スクリーンリーダーや点字デバイスなどの支援技術を利用する場合、使用中のプログラムがビジュアル・フォーカス・インジケーターの位置や内容を示している。

### タイミングのチェックリスト

TM | タイミング | 成功/失敗/NA
TM.1 | アプリケーションにおけるタイムアウトや時間に基づく機能のタイミングがハードコードされていない。
TM.2 | マウスポインターを動かしただけで、重要な情報が表示されたりあるいは非表示になったりしない。

### ドキュメンテーションのチェックリスト

DC | ドキュメンテーション | 成功/失敗/NA
DC.1 | すべてのドキュメントがアクセシブルな形式となっており、あらゆる図表に対するテキスト形式の代替表示が提供されている。
DC.2 | ドキュメントには、アプリケーションの全アクセシビリティ機能について説明したセクションが設けられている。

### GOK (GNOME オンスクリーン・キーボード)

The information on this page is partially outdated: GNOME 3's Caribou has effectively replaced GNOME 2's gok.

アプリケーションは gok を通じて利用可能であるべきであり、キー入力を、キーボードからではなく、もっぱら gok から行ってみるとよいでしょう。本節のねらいは、任意の型式の文字入力がオンスクリーン・キーボードで行えるように、対象のアプリケーションとデスクトップ一般について扱うことです。

gok は、GNOME デスクトップに搭載されているため、すでに利用可能なはずです。完全なドキュメントが必要な場合は、gok のオフィシャル・サイトを参照してください。

以下の手順に従い、対象のアプリケーションに対してgok の正しい操作ができるか検証してください。

1. GNOME デスクトップにログインする。

2. gok を起動する。

3. 対象のアプリケーションを起動する。

4. ポインティングデバイス (たとえばマウスやヘッドトラッカー) および gok を使ってアプリケーションに入力を与える。

5. gok の自動補完および単語予測機能を使って作業を行う。

6. gok が、起動されたアプリケーションの種類に基づいてメニューボタンとツールバーボタンを有効化、また無効化するのを検証する。たとえば、メニューボタンとツールバーボタンは「フォントのプロパティ」キャプレットに対しては無効化されるが、Gedit に対しては有効化される。

7. キーボードボタンから起動される gok のオンスクリーン・キーボードを使って、対象のアプリケーションに対して任意のテキストを入力することが可能か検証する。Gedit を起動し、テキストエリアをクリックし、そして gok のキーボードをクリックする。オンスクリーン・キーボードから必要なキーを選択する。Gedit のテキストエリアに入力した文字が表示されるはずである。

8. ランチャーボタンから任意の端末、ウェブ・ブラウザーあるいはテキスト・エディターが起動できるかを検証する

9. 実行中ボタンを使って、GNOME パネルや GNOME デスクトップを含めてデスクトップ上で起動している任意のアプリケーションのウィンドウをアクティブにすることができるかを検証する。

10. メニューボタンを押すと、対象のアプリケーションで利用可能なすべてのメニューがリストアップされるかを検証する。メニューのどれか1つのボタンをクリックすると、サブメニューおよびサブメニューに含まれるメニュー項目が表示されることを検証する。最後に、メニュー項目のボタンをクリックし、対応するメニュー項目を実行することができるかを検証する。たとえば、ヘルプ・ブラウザー を起動し、メニューボタンをクリックする。GOK のウィンドウにファイル、ジャンプおよびヘルプボタン (ヘルプ・ブラウザーのメニューに対応する) が表示される。ファイルボタンをクリックすると、新しいウィンドウボタンと閉じるボタン (メニュー項目に対応する) が表示される。

11. ツールバーボタンが、対象のアプリケーションのツールバーで利用可能なすべてのボタンをリストアップしているかを検証する。たとえば、ヘルプ・ブラウザーを起動し、ツールバーボタンをクリックする。GOK のウィンドウに戻るボタン、進むボタンおよびホームボタンが表示される。

12. UI の取得ボタンをクリックすると、対象のアプリケーションのウィンドウに上に見えるすべてのボタン・オブジェクトが表示されるかを検証する。例えば、「フォントのプロパティ」キャプレットを開き、GOK のウィンドウのUI の取得ボタンをクリックする。GOK のウィンドウには、キャプレットにおけるボタンの名称 - Sans、Sans-serif、閉じるおよびヘルプ - は表示されないはずである。

### Accerciser

Accerciser and the GNOME Accessibility Architecture

Accerciser is an interactive Python accessibility explorer for the GNOME Desktop. It uses AT-SPI to inspect and control widgets, allowing you to check if an application is providing correct information to assistive technologies and automated test frameworks. Accerciser has a simple plugin framework which you can use to create custom views of accessibility information. Full documentation can be found in the Official Accerciser Manual. For a demonstration of Accerciser and PyATSPI (Python-wrapped access and usage of AT-SPI), see this article. For an excellent walkthrough from the author, see the article titled Make Your Application Accessible with Accerciser.

Accerciser は、事実上旧来の at-poke ツールに取って代わりました。