# Guide d'accessibilité du bureau GNOME pour les développeurs

Le guide d'accessibilité du bureau GNOME est pour les développeurs qui souhaitent s'assurer que leurs programmes sont accessibles au plus grand nombre d'utilisateurs. Ce guide couvre aussi bon nombre des critères de la section 508 (États Unis).

2008
Vincent Alexander
2001, 2002
Calum Benson, Brian Cameron, Bill Haneman, Padraig O'Briain, Sharon Snider
2010
Laurent Coudeur (laurentc@iol.ie)
2010
Bruno Brouard (annoa.b@gmail.com)
Projet de documentation GNOME

Permission vous est donnée de copier, distribuer et/ou modifier ce document selon les termes de la Licence GNU Free Documentation License (GFDL), Version 1.1 ou ultérieure publiée par la Free Software Foundation sans section inaltérable, sans texte de première page de couverture ni texte de dernière page de couverture. Vous trouverez un exemplaire de cette licence en suivant ce lien ou dans le fichier COPYING-DOCS fourni avec le présent manuel.

Ce manuel fait partie de la collection de manuels GNOME distribués selon les termes de la licence de documentation libre GNU. Si vous souhaitez distribuer ce manuel indépendamment de la collection, vous devez joindre un exemplaire de la licence au document, comme indiqué dans la section 6 de celle-ci.

La plupart des noms utilisés par les entreprises pour distinguer leurs produits et services sont des marques déposées. Lorsque ces noms apparaissent dans la documentation GNOME et que les membres du projet de Documentation GNOME sont informés de l'existence de ces marques déposées, soit ces noms entiers, soit leur première lettre est en majuscule.

LE PRÉSENT DOCUMENT ET SES VERSIONS MODIFIÉES SONT FOURNIS SELON LES TERMES DE LA LICENCE DE DOCUMENTATION LIBRE GNU SACHANT QUE :

1. LE PRÉSENT DOCUMENT EST FOURNI « TEL QUEL », SANS AUCUNE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS, ET SANS LIMITATION, LES GARANTIES DE BONNE QUALITÉ MARCHANDE OU D'APTITUDE À UN EMPLOI PARTICULIER OU AUTORISÉ DU DOCUMENT OU DE SA VERSION MODIFIÉE. L'UTILISATEUR ASSUME TOUT RISQUE RELATIF À LA QUALITÉ, À LA PERTINENCE ET À LA PERFORMANCE DU DOCUMENT OU DE SA VERSION DE MISE À JOUR. SI LE DOCUMENT OU SA VERSION MODIFIÉE S'AVÉRAIT DÉFECTUEUSE, L'UTILISATEUR (ET NON LE RÉDACTEUR INITIAL, L'AUTEUR, NI TOUT AUTRE PARTICIPANT) ENDOSSERA LES COÛTS DE TOUTE INTERVENTION, RÉPARATION OU CORRECTION NÉCESSAIRE. CETTE DÉNÉGATION DE RESPONSABILITÉ CONSTITUE UNE PARTIE ESSENTIELLE DE CETTE LICENCE. AUCUNE UTILISATION DE CE DOCUMENT OU DE SA VERSION MODIFIÉE N'EST AUTORISÉE AUX TERMES DU PRÉSENT ACCORD, EXCEPTÉ SOUS CETTE DÉNÉGATION DE RESPONSABILITÉ ; ET

2. EN AUCUNE CIRCONSTANCE ET SOUS AUCUNE INTERPRÉTATION DE LA LOI, QU'IL S'AGISSE D'UN DÉLIT CIVIL (Y COMPRIS LA NÉGLIGENCE), CONTRACTUEL OU AUTRE, L'AUTEUR, LE RÉDACTEUR INITIAL, TOUT PARTICIPANT OU TOUT DISTRIBUTEUR DE CE DOCUMENT OU DE SA VERSION MODIFIÉE, OU TOUT FOURNISSEUR DE L'UNE DE CES PARTIES NE POURRA ÊTRE TENU RESPONSABLE À L'ÉGARD DE QUICONQUE POUR TOUT DOMMAGE DIRECT, INDIRECT, PARTICULIER, OU ACCIDENTEL DE TOUT TYPE Y COMPRIS, SANS LIMITATION, LES DOMMAGES LIÉS À LA PERTE DE CLIENTÈLE, À UN ARRÊT DE TRAVAIL, À UNE DÉFAILLANCE OU UN MAUVAIS FONCTIONNEMENT INFORMATIQUE, OU À TOUT AUTRE DOMMAGE OU PERTE LIÉE À L'UTILISATION DU DOCUMENT ET DE SES VERSIONS MODIFIÉES, MÊME SI LADITE PARTIE A ÉTÉ INFORMÉE DE L'ÉVENTUALITÉ DE TELS DOMMAGES.

Vincent
Alexander
Projet de documentation GNOME
Calum
Benson
Projet de documentation GNOME
Brian
Cameron
Projet de documentation GNOME
Bill
Haneman
Projet de documentation GNOME
Padraig
O'Briain
Projet de documentation GNOME
Sharon
Snider
Projet de documentation GNOME
Guide d'accessibilité v2.24.0 pour les développeurs du bureau GNOME 2.24
Septembre 2008

Projet de documentation GNOME

Projet de documentation GNOME

Guide d'accessibilité v2.24.0 pour les développeurs du bureau GNOME 2.24
Septembre 2008

Projet de documentation GNOME

Projet de documentation GNOME

Ce manuel documente la version 2.24 du bureau GNOME.

## Votre avis

Pour rapporter une anomalie ou faire une suggestion concernant le bureau GNOME ou ce manuel, suivez les indications de la Page de réactions sur GNOME.

## Qu'est-ce que I'accessibilité ?

L'accessibilité signifie l'assistance aux personnes handicapées pour qu'elles puissent participer aux activités substantielles de la vie. Cela inclut le travail, l'accès aux services, produits et informations. GNOME inclut des bibliothèques et une structure de prise en charge qui permettent aux personnes ayant des handicaps d'utiliser toutes les fonctionnalités de l'environnement utilisateur GNOME.

En conjonction avec les technologies d'assistance, si nécessaire - interfaces vocales, lecteurs d'écran, périphériques de saisie alternatifs, et ainsi de suite - les personnes souffrant temporairement ou définitivement de handicaps peuvent donc utiliser le bureau GNOME et ses applications. Les technologies d'assistance sont aussi utiles pour les personnes utilisant un ordinateur en dehors de leur bureau ou de leur maison. Par exemple, si vous êtes pris dans un bouchon vous pouvez utiliser la commande vocale pour consulter votre courriel.

Les technologies d'assistance reçoivent des informations de l'application via l'API Accessibility Toolkit (ATK), que vous pouvez trouver dans le module atk des dépôts GNOME. Comme la prise en charge de l'API est incluse dans les éléments graphiques de GNOME, votre programme devrait fonctionner raisonnablement bien avec les technologies d'assistance sans que vous ayez à faire de travail supplémentaire. Par exemple, les technologies d'assistance peuvent lire automatiquement les étiquettes des éléments graphiques que vous utilisez normalement dans votre programme (par ex. avec des appels de fonctions GTK telles que `gtk_label_set_text()` ou `gtk_button_new_with_label()`). Elles peuvent aussi trouver si un texte d'infobulle est associé à un élément graphique et l'utiliser pour décrire l'élément graphique à l'utilisateur.

Avec seulement un petit effort supplémentaire, vous pouvez faire fonctionner votre programme encore mieux grâce aux technologies d'assistance. En plus d'aider les utilisateurs, cela rendra votre programme plus attractif aux marchés gouvernementaux et éducatifs dont la plupart exigent que leurs applications soient légalement accessibles.

### Types de handicaps

Il est estimé, rien qu'aux États Unis, qu'il y a 30 000 000 personnes dont la capacité d'accès aux ordinateurs est limitée par une conception non accessible. Globalement approximativement 8% des personnes qui utilisent Internet ont une forme de handicap. Ces handicaps sont classés comme suit :

- Déficience visuelle - Cela va de la mauvaise vue (vue faible ou floue, presbytie ou myopie extrême, daltonisme et rétrécissement du champ visuel entre autres) à la cécité complète. Un mauvais choix de taille de texte et de couleurs et des tâches requérant une bonne coordination main-œil (tel que le déplacement de la souris) peuvent causer des problèmes pour ces utilisateurs.

- Handicaps moteur - Ce sont des utilisateurs qui ont des problèmes de contrôle musculaire ou des faiblesses qui rendent l'utilisation d'un clavier standard et d'une souris difficile. Par exemple, ils peuvent être incapables d'enfoncer deux touches simultanément ou il se peut qu'ils enfoncent des touches accidentellement.

- Altération auditive - Cela va de la capacité d'entendre certains sons mais pas de distinguer les mots parlés, à la surdité profonde. Les applications qui fournissent des informations importantes uniquement par messages sonores causent des problèmes à ces utilisateurs.

- Difficultés d'expression et de raisonnement - Cela va de la dyslexie aux problèmes de mémoire, de résolution de problèmes, de compréhension et d'utilisation du langage écrit ou parlé. Un affichage complexe ou peu cohérent, un mauvais choix de mots peut rendre l'utilisation d'ordinateurs difficile pour ces utilisateurs.

- Troubles convulsifs - Certains motifs lumineux ou répétitions sonores peuvent causer des crises épileptiques pour les utilisateurs qui y sont sensibles.

### Fonctionnement de l'accessibilité dans GNOME

La boîte à outils d'accessibilité (ATK) décrit un jeu d'interfaces qui doivent être implémentées dans les composants de l'interface graphique pour les rendre accessibles. Les interfaces sont indépendantes de la boîte à outils - les implémentations peuvent être écrites pour n'importe quel jeu de d'éléments graphiques, tel que GTK, Motif ou Qt.

L'implémentation pour les éléments graphiques GTK est un module appelé GAIL pour « GNOME Accessibility Implementation Library » (bibliothèque d'implémentation d'accessibilité GNOME), qui est chargé dynamiquement au démarrage d'une application GTK. Une fois chargé, les parties de votre application qui utilisent des éléments graphiques GTK standards disposeront d'un niveau d'accessibilité de base, sans avoir à modifier votre application. Si GAIL n'est pas chargé, les éléments graphiques GTK auront une implémentation d'accessibilité qui ne renvoie aucune information, même si c'est nominalement en conformité avec l'API ATK. Les applications qui utilisent des contrôles Bonobo, particulièrement ceux hors processus, chargent aussi la prise en charge d'accessibilité depuis le module libgail-gnome. Le chargement automatique des bibliothèques de prise en charge de l'accessibilité par les applications dans le bureau GNOME dépend de la valeur de la clé gconf « /desktop/gnome/interface/accessibility ». Une valeur booléenne « true » (vrai) active la prise en charge des technologies d'assistance et les applications qui appellent gnome_program_init chargeront automatiquement les bibliothèques appropriées à l'exécution. Les « applications GTK+ pures », par ex. celles qui utilisent GTK+ mais qui ne sont pas liées à libgnome, dépendent de la valeur de la variable d'environnement GTK_MODULES, qui doit être définie à « gail:atk-bridge » pour que la prise en charge des technologies d'assistance soit activée.

La plupart des technologies d'assistance utilisées par d'autres bureaux ont historiquement nécessité de maintenir des modèles hors écran complexes des applications du bureau, basés sur la capture d'évènements du système d'exploitation (SE), l'utilisation de fonctionnalités et d'API non prises en charge par le SE et les applications, ainsi que d'autres techniques non transférables. Cela rend la prise en charge des technologies d'assistance quelque peu « fragile » et très spécifique au SE et aux applications. Par contraste, pour le bureau GNOME, toutes les informations nécessaires aux technologies d'assistance sont fournies par les applications en fonctionnement, via la boîte à outils d'accessibilité de GNOME, vers l'interface de fournisseur de services (Service Provider Interface : SPI) de la boîte à outils indépendante. L'interface SPI fournit les moyens aux technologies d'assistance basées sur UNIX, telles que les lecteurs d'écran et les loupes, d'obtenir les informations d'accessibilités depuis les applications en fonctionnement via une API stable et homogène, et peut éliminer le besoin d'un modèle hors écran dans de nombreux cas. La prise en charge des applications est « intégrée » dans les boîtes à outils via les API appropriées (par exemple, ATK pour la plupart des applications natives en C et l'API Java Accessibility pour les applications Java) et exportée vers l'interface « AT-SPI » commune via le « pont » correspondant (voir le diagramme ci-dessous).

#### Architecture de l'accessibilité de GNOME

Diagramme de l'architecture de l'accessibilité de GNOME

La prise en charge intégrée des technologies d'assistance par GNOME signifie que les applications créées en utilisant les éléments graphiques du magasin GNOME bénéficient de la prise en charge de ces technologies « gratuitement », à condition que l'utilisation des éléments graphiques ne soit pas en conflit avec la prise en charge intégrée.

Un élément graphique gtk+/GNOME est accessible si son utilisation suit les directives générales d'accessibilité décrites dans ce document, et que les interfaces ATK appropriées à son role sont implémentées dans l'interface utilisateur. Les implémentations ATK sont fournies pour les éléments graphiques de la boîte à outils du « magasin » de GNOME (par ex. les éléments graphiques non abandonnés de gtk+ et GNOME) et dans de nombreux cas, les nouveaux éléments graphiques qui sont de simples dérivés d'éléments graphiques GTK+ ou GNOME, héritent également d'une prise en charge d'accessibilité convenable.

Bien que l'accessibilité intégrée de GNOME fournisse des fonctionnalités significatives sans qu'il soit nécessaire de modifier le code de l'application avec du code spécifique à l'accessibilité, les applications peuvent souvent, pour certains éléments graphiques, être améliorées au niveau des descriptions des éléments graphiques fournies par défaut et être personnalisées pour la fonction spécifique de l'élément graphique dans l'application, à l'aide de simples appels aux méthodes ATK dans l'application. Par exemple, dans la plupart des cas, les applications devraient ajouter ou modifier le texte descriptif pour ces éléments graphiques, par un appel à la fonction ATK appropriée, pour que les technologies d'assistance puissent en décrire le but ou l'état à l'utilisateur. Pour plus d'informations, consultez les directives de codage pour la prise en charge de l'accessibilité.

Si votre application utilise des éléments graphiques personnalisés, vous allez sûrement devoir faire un peu de travail pour fournir les propriétés de ces éléments graphiques aux technologies d'assistance. Pour plus d'informations, consultez la section rendre les composants personnalisés accessibles et les exemples d'utilisation de l'API d'accessibilité.

Pour des informations supplémentaires plus détaillées sur GTK/GTK+, consultez le manuel de référence de GTK+, la section GTK du guide de ATK, le tutoriel GTK+ 2.0 hébergé par GNOME et la FAQ GTK+ officielle.

### Démarrage rapide pour le développeur

Voici quelques points de départ courants :

#### Comment vérifier que mon application est accessible ?

Pour bien commencer, consultez la section rendre une application GNOME accessible - aperçu. Pour une perspective de pré-codage, consultez les directives pour la prise en charge de l'accessibilité dans l'interface utilisateur ou les directives de codage pour la prise en charge de l'accessibilité. Pour une liste de contrôle après conception, consultez la liste de contrôle de l'interface utilisateur.

#### Pièges à éviter

La liste de contrôle de l'interface utilisateur couvre toutes les zones qui sont parfois oubliées lors de la phase de conception.

#### Comment réaliser les fonctions ATK courantes ?

Une liste abrégée des appels ATK courants se trouve ici.

#### Comment réaliser les fonctions ATK plus complexes ?

Pour plus d'informations, consultez la section rendre les composants personnalisés accessibles et les exemples d'utilisation de l'API d'accessibilité.

#### Introduction à ATK, AT-SPI, GAIL et GTK+

Architecture de l'accessibilité de GNOME

ATK est la boîte à outils qu'utilise GNOME pour activer l'accessibilité pour les utilisateurs qui ont besoin d'une assistance supplémentaire pour utiliser au mieux leurs ordinateurs. ATK est utilisée par des outils tels que les lecteurs d'écran, les loupes et les périphériques de saisie pour permettre une interaction riche avec le bureau par des moyens alternatifs. Pour plus d'informations, consultez le projet sourceforge ATK et la bibliothèque ATK.

AT-SPI est l'interface de service principale par laquelle les technologies d'assistance effectuent leurs requêtes et reçoivent les notifications des applications en fonctionnement. L'API complète peut être explorée ici. Plus d'informations sont disponibles via la communauté de développement de l'accessibilité KDE.

GAIL (GNOME Accessibility Implementation Library) est une implémentation des interfaces d'accessibilité définies par ATK. GTK est une boîte à outils qui est déjà liée à ATK par le module GAIL. La licence, la procédure de téléchargement et d'autres informations sont disponibles ici. Le code source de GAIL est aussi un excellent tutoriel pour une utilisation avancée d'ATK. De plus, vous pouvez être intéressé par le manuel de référence de GAIL.

GTK+ est une bibliothèque utilisée pour créer des interfaces graphiques. Elle fonctionne avec de nombreuses plateformes de type UNIX, Windows et avec des consoles graphiques. GTK+ est distribuée sous la licence de bibliothèque publique générale GNU (GNU LGPL), qui est une licence d'utilisation flexible pour les applications clientes. L'architecture de GTK+ se base sur le langage C orienté objet, qui permet une flexibilité maximum. Des liaisons vers d'autres langages existent pour le C++, Objective-C, Guile/Scheme, Perl, Python, TOM, Ada95, Free Pascal et Eiffel.

Pour des informations supplémentaires plus détaillées sur GTK/GTK+, consultez le manuel de référence de GTK+, la section GTK du guide de ATK, le tutoriel GTK+ 2.0 hébergé par GNOME et la FAQ GTK+ officielle.

### Rendre une application GNOME accessible - aperçu

Si votre application n'utilise que des éléments graphiques GTK standards, vous aurez peu ou pas de travail pour que votre application soit (raisonnablement) accessible. Mais faites attention aux objets dans votre GUI qui n'ont pas de texte de description associé, tel que des boutons graphiques ou des indicateurs d'état qui n'ont pas d'étiquette ou d'infobulle.

Vous pouvez aussi améliorer les descriptions par défaut fournies pour certains éléments graphiques et les personnaliser pour la fonction spécifique réalisée par l'élément graphique dans l'application. Vous pouvez ajouter ou modifier le texte de description pour ces éléments graphiques par un appel à la fonction ATK appropriée, pour qu'une technologie d'assistance puisse décrire leurs fonctions ou états à l'utilisateur. Pour plus d'informations, consultez les directives de codage pour la prise en charge de l'accessibilité.

Si votre application utilise des éléments graphiques personnalisés, vous allez sûrement devoir travailler un peu pour rendre leurs propriétés visibles par les technologies d'assistance. Pour plus d'informations, consultez la section pour rendre les composants personnalisés accessibles et les exemples d'utilisation de l'API d'accessibilité. Des informations plus détaillées peuvent être trouvées dans la présentation de Marc Mulcahy au GUADEC 2002 : « Rendre les applications GNOME accessibles ».

### Directives de codage pour la prise en charge de l'accessibilité

Voici plusieurs choses que vous pouvez faire pour que votre programme fonctionne au mieux avec les technologies d'assistance (vous trouverez une liste des choses à considérer lorsque vous concevez votre GUI dans la section sur les directives pour la prise en charge de l'accessibilité dans l'interface utilisateur plus loin dans ce document) :

- Pour les composants qui n'affichent pas de chaîne de texte courte (tel qu'un bouton graphique), donnez lui un nom avec la fonction `atk_object_set_name()`. Vous pourriez utiliser cette fonction pour les boutons qui n'affichent qu'une image, les panneaux qui regroupent des fonctions de manière logique, les zones de texte...

- Si vous ne pouvez pas fournir d'infobulle pour un composant, utilisez la fonction `atk_object_set_description()` à la place pour fournir une description que les technologies d'assistance peuvent renvoyer à l'utilisateur. Par exemple, pour fournir une description accessible pour un bouton Fermer :

  #### Description accessible pour un bouton GtkButton

      {
        AtkObject *obj;
        obj = gtk_widget_get_accessible(button);
        atk_object_set_description(obj,_("Ferme la fenêtre"));
      }

- Utilisez la fonction `atk_image_set_description()` pour fournir le texte de description pour toutes les images et icônes de votre programme.

- Si plusieurs composants forment un groupe logique, essayez de les mettre dans un même conteneur.

- Quand vous avez une étiquette qui décrit un autre composant, utilisez la fonction `atk_relation_set_add_relation()` pour que les technologies d'assistance puissent trouver le composant associé à cette étiquette (si vous associez l'étiquette au composant avec la fonction `gtk_label_set_mnemonic_widget()`, la relation `ATK_RELATION_LABEL_FOR` est générée automatiquement, donc le code suivant n'est plus nécessaire) :

  #### Lien entre un GtkLabel et un 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));
      }

- Si vous créez un élément graphique personnalisé, assurez-vous qu'il prend en charge l'accessibilité. Les composants personnalisés qui sont des descendants d'éléments graphiques GTK doivent remplacer les informations d'accessibilité héritées quand c'est nécessaire. Pour plus d'informations, consultez la section pour rendre les composants personnalisés accessibles.

- Ne cassez pas ce que vous pouvez obtenir sans effort ! Si votre GUI contient un conteneur inaccessible, tous les composants qu'il contient, risquent de l'être aussi.

### API d'accessibilité

Voici quelques-uns des appels de base à l'API dont vous pouvez avoir besoin dans votre application pour vous assurer qu'elle fonctionne correctement avec les technologies d'assistance. L'API d'accessibilité complète est vaste pour vous permettre d'écrire vos propres éléments graphiques accessibles personnalisés.

#### Appels à l'API ATK couramment utilisés

API | Description
--- | ---
`AtkObject* gtk_widget_get_accessible (GtkWidget*)` | Renvoie l'objet accessible qui décrit l'élément graphique GTK spécifié, vers une technologie d'assistance.
`void atk_object_set_name (AtkObject*, const gchar*)` | Définit le nom de l'objet accessible. Par exemple, si l'objet est un bouton graphique qui permet de quitter l'application quand on clique dessus, le nom peut être « Quitter ».
`void atk_object_set_description (AtkObject*, const gchar*)` | Définit le texte de description de l'objet accessible. Par exemple, si l'objet est un bouton graphique « Fermer », la description peut être « Ferme la fenêtre ».
`AtkRelation* atk_relation_new (AtkObject**, gint, AtkRelationType)` | Crée une nouvelle relation entre la clé spécifiée et la liste d'objets cibles spécifiée. Une relation indique normalement à la technologie d'assistance qu'un élément graphique est connecté à un autre. Par exemple, un élément graphique GtkLabel particulier est la légende d'un élément graphique GtkTreeView dans la même fenêtre.
`void atk_image_set_description (AtkImage*, const gchar*)` | Définit le texte de description d'un objet image accessible. Par exemple, si l'objet est une miniature d'un bureau virtuel dans une applet de tableau de bord, la description peut être « Image montrant l'arrangement des fenêtres sur le bureau 1 ».

### Exemples d'utilisation de l'API d'accessibilité

Comme remarqué plus tôt, vous avez peu ou pas de travail à faire pour rendre votre application accessible si vous utilisez les éléments graphiques de GTK, ou n'importe quel élément graphique provenant de bibliothèques qui implémentent les interfaces ATK. Les deux choses les plus courantes que vous allez faire dans ce cas sont :

- fournir des descriptions pour certains contrôles et images avec les fonctions `atk_object_set_description()` ou `atk_image_set_description()` :

  #### Définition de la description d'accessibilité pour un bouton

      {
         AtkObject *obj;
         obj = gtk_widget_get_accessible(button);
         atk_object_set_description(obj,_("Ouvre la boîte de dialogue Préférences"));
      }

- spécifier des relations entre tout regroupement inhabituel d'éléments graphiques en utilisant les fonctions `atk_relation_new()` et `atk_relation_set_add()` :

  #### Spécification des relations d'accessibilité entre deux contrôles

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

Les exemples dans la suite de cette section, vont vous donner un aperçu de l'étendue d'ATK. Ils couvrent des techniques dont vous pouvez ne jamais avoir besoin en tant que développeur d'application, bien qu'elles puissent vous intéresser si vous écrivez vos propres éléments graphiques personnalisés (consultez la section pour rendre vos composants personnalisés accessibles) ou si vous voulez écrire une application de technologie d'assistance. Quel que soit votre but, le code source de GAIL est un excellent tutoriel pour une utilisation avancée d'ATK.

#### Modules Gtk

Les programmes qui utilisent GAIL (la bibliothèque d'implémentation d'accessibilité pour les éléments graphiques GTK) sont écrits sous la forme de modules GTK. Les modules GTK sont chargés dans l'espace du programme si la variable d'environnement `GTK_MODULES` spécifie le(s) nom(s) de la bibliothèque de module. S'il y a plusieurs bibliothèques de modules, séparez-les par des deux-points. Par exemple :

`setenv GTK_MODULES "libgail:libtestprops"`

Tous les modules GTK possèdent une fonction `gtk_module_init()`.

#### Collecte des informations d'accessibilité depuis une application

Un programme qui souhaite utiliser des appels ATK doit faire une (ou plusieurs) des actions suivantes :

1. Créer un moniteur d'évènement, par exemple avec la fonction `atk_add_focus_tracker()` :

       atk_add_focus_tracker (_mon_moniteur_evenement);

   où `_mon_moniteur_evenement()` est une fonction qui utilise ce prototype :

       void _mon_moniteur_evenement (AtkObject *aobject);

2. Définir un auditeur d'évènements global avec la fonction atk_add_global_event_listener() :

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

   où `_mon_auditeur_global` contient le prototype Glib GSignalEmissionHook. Cet exemple fait en sorte que la fonction `_mon_auditeur_global()` soit appelée quand un signal enter_notify_even se produit sur un objet GtkWidget.

3. Accéder aux objets de niveau supérieur d'ATK avec l'appel de fonction suivant :

       AtkObject *root_obj = atk_get_root();

   Cela retourne un AtkObject qui contient toutes les fenêtres de niveau supérieur du programme actuellement en fonction. L'utilisateur peut alors naviguer dans la hiérarchie des objets en accédant aux enfants de l'objet racine, ce qui correspond aux fenêtres de niveau supérieur.

#### Requête d'interfaces d'un AtkObject

Après avoir localisé l'objet AtkObject associé avec un objet dans l'application (par ex. avec la fonction `gtk_widget_get_accessible()`), vous pouvez trouver quelles interfaces il implémente de plusieurs façons :

1. Utilisez les macros `ATK_IS_...` fournies, par exemple :

   - `ATK_IS_ACTION(atkobj)`

   - `ATK_IS_COMPONENT(atkobj)`

   - etc. (il y en a une pour chaque interface)

   Si la macro renvoie `TRUE` (VRAI), les appels de l'interface peuvent être effectués sans problème sur cet objet ATK.

2. Testez le rôle de l'objet AtkObject en appelant la fonction `atk_object_get_role()`. Chacun des rôles obtenus implémente un numéro spécifique d'API ATK.

#### Configuration d'un gestionnaire de signal ATK

Utilisez le signal `column_inserted` comme exemple :

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

La fonction `_ma_fonct_tableau_colonne_inseree()` est alors appelée à chaque fois qu'un signal column_inserted est émis sur l'objet AtkObject `mon_obj_atk`.

La connexion à un signal est un peu différente si le signal prend en charge les détails. Le signal `children_changed` prend en charge le détail `add`. Pour se connecter à un signal quand le détail `add` est aussi spécifié, cette technique est utilisée :

    child_added_id = g_signal_connect_closure (mon_obj_atk,"children_changed::add",   g_cclosure_new (G_CALLBACK(_ma_fonct_enfant_modifie),NULL,NULL),FALSE);

La fonction `_ma_fonct_enfant_modifie()` est alors appelée quand un signal `children_changed` avec le détail `add` est émis sur l'objet AtkObject `mon_obj_atk`.

#### Implémentation d'un objet ATK

Vous devrez implémenter vos propres objets ATK pour tous les éléments graphiques qui n'ont pas déjà une implémentation accessible dans GAIL (ou la bibliothèque équivalente pour d'autres jeux d'éléments graphiques). Vous devez implémenter ceci sous la forme d'un module GTK, qui, comme précédemment, doit être inclus dans la variable d'environnement `GTK_MODULES` afin qu'il soit chargé au lancement.

##### Registre

Dans cet exemple nous allons supposer qu'il existe un objet appelé GTK_TYPE_MONTYPE. L'implémentation ATK est appelée MON_IMP_ATK_TYPE_MONTYPE. Une fabrique est nécessaire et est appelée MON_IMP_ATK_TYPE_MONTYPE_FABRIQUE.

Pour enregistrer l'implémentation ATK d'un objet GTK, les étapes suivantes doivent être suivies dans la fonction `gtk_module_init()` du module :

1. Accès au registre par défaut :

       default_registry = atk_get_default_registry();

2. Enregistrement de l'objet ATK dans la fonction `gtk_module_init()` de ce module à l'aide de l'appel de fonction suivant :

       atk_registry_set_factory_type (default_registry, GTK_TYPE_MONTYPE, MON_IMP_ATK_TYPE_MONTYPE_FABRIQUE);

Cela enregistre l'implémentation de l'AtkObject de GTK_TYPE_MONTYPE dans MON_IMP_ATK_TYPE_MONTYPE_FABRIQUE. Cette fabrique sera implémentée afin qu'elle sache construire les objets de type MON_IMP_ATK_TYPE_MONTYPE.

##### Fabrique

La fabrique doit être implémentée comme un enfant du type de classe ATK_TYPE_OBJECT_FACTORY et doit implémenter la fonction `create_accessible()`. Cette fonction doit créer un objet AtkObject approprié. Une fabrique peut être utilisée pour créer plus d'un type d'objet, dans ce cas sa fonction `create_accessible()` doit être suffisamment intelligente pour construire et renvoyer l'objet AtkObject correct.

##### Implémentation ATK pour un objet spécifique

Tous les objets GObject implémentent une fonction `get_type()`. En utilisant l'exemple précédent, la convention d'attribution de nom pour cette fonction est `mon_imp_atk_montype_get_type()`.

Dans cette fonction, vous spécifiez quelles interfaces sont implémentées par votre objet. Si la logique suivante est incluse dans cette fonction `get_type()`, cet objet implémente alors l'interface ATK_TEXT :

###### Exemple de fonction `get_type()`

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

La fonction `atk_text_interface_init()`, qui possède le prototype suivant, doit être implémentée :

    void atk_text_interface_init (AtkTextIface *iface);

Cette fonction connecte les appels de la fonction d'interface à l'implémentation spécifique comme suit :

###### Connexion des appels d'interface personnalisés à une implémentation d'AtkObject

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

Ensuite les fonctions `mon_imp_atk_montype_get_text()`, `mon_imp_atk_montype_get_character_at_offset()` et le reste des fonctions de l'interface ATK_TEXT doivent être implémentés.

##### Implémentation d'AtkObject

Les AtkObject sont des objets GObjects et tous les GObject doivent spécifier la fonction `get_type()`. Voici un exemple qui définit une classe et un initialisateur d'instance. Cette fonction `get_type()` spécifie aussi que l'objet implémente ATK_TEXT et spécifie l'objet parent comme un MON_IMP_ATK_MONTYPEPARENT.

###### Exemple d'implémentation de `get_type()`

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

       if (!type)
       {
          static const GTypeInfo tinfo =
          {
             sizeof (GailLabelClass),
             (GBaseInitFunc) NULL,                                  /* initialisation base */
             (GBaseFinalizeFunc) NULL,                              /* finalisation base */
             (GClassInitFunc) mon_imp_atk_montype_class_init,       /* class init */
             (GClassFinalizeFunc) NULL,                             /* class finalize */
             NULL,                                                  /* données de la classe */
             sizeof (GailLabel),                                    /* taille de l'instance */
             0,                                                     /* nbre préallocations */
             (GInstanceInitFunc) mon_imp_atk_montype_instance_init, /* instance init */
             NULL                                                   /* tableau de valeur */
          };

          /* Organisation de la structure atk_text_info utilisée ci-dessous */
          static const GInterfaceInfo atk_text_info =
          {
             (GInterfaceInitFunc) atk_text_interface_init,
             (GInterfaceFinalizeFunc) NULL,
             NULL
          };

          /* Organisation du typename et spécification du type du parent */
          type = g_type_register_static (MON_IMP_ATK_MONTYPEPARENT,
                "monimpatkmontype", &tinfo, 0);

          /* Cette classe implémente l'interface ATK_TYPE_TEXT */
          g_type_add_interface_static (type, ATK_TYPE_TEXT,
                                       &atk_text_info);
       }
       return type;
    }

##### Initialisateurs de classe/instance

Vous allez devoir configurer un initialisateur de classe pour l'objet GObject dans l'un des deux cas suivants : si votre implémentation d'AtkObject

1. redéfinit un des appels de fonction défini par l'objet parent. C'est en général nécessaire quand un objet doit implémenter une fonction comme `atk_object_get_n_accessible_children()`. C'est nécessaire si l'objet possède des fils qui ne sont pas représentés par des éléments graphiques.

   Par exemple, si votre implémentation ATK doit remplacer la fonction `get_name()` d'AtkObject alors l'initialisateur de classe ressemblera à :

   ###### Initialisateur de classe qui remplace la fonction `get_name()` du parent.

       mon_imp_atk_montype_class_init (GailLabelClass *klass)
       {
         AtkObjectClass *class = ATK_OBJECT_CLASS (klass);
         class->get_name = mon_imp_atk_montype_get_name;
       }

2. ou si elle requiert une fonction `parent->init`, `parent->notify_gtk` ou `parent->finalize`. Cet exemple définit les trois :

   ###### Initialisateur de classe qui définit ses propres fonctions `init()`, `notify_gtk()` et `finalize()`

       static ParentObjectType *parent_class = NULL;

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

          /*
           * La mise en cache de parent_class est nécessaire si les fonctions
           * init, notify_gtk ou finalize sont configurées.
           */
           parent_class = g_type_class_ref (MONATKIMP_TYPE_PARENT);

           parent_class->init = mon_imp_atk_montype_widget_init;
           parent_class->notify_gtk = mon_imp_atk_montype_real_notify_gtk;
           parent_class->finalize = mon_imp_atk_montype_finalize;
       }

   1. parent->init

      Une fonction `parent->init()` peut être nécessaire si l'implémentation ATK a besoin d'effectuer l'une des actions suivantes :

      1. mettre en cache toutes les données obtenues à partir de l'élément graphique GTK auxiliaire,

      2. écouter tous les signaux émis par l'élément graphique GTK auxiliaire.

      Voici un exemple des deux :

      ###### Une fonction personnalisée `init()`

          void
          gail_tree_view_widget_init (Monimpatkmontype  *montype,
                                      GtkWidget       *gtk_widget)
          {
             /* Être sûr d'appeler la fonction init du parent */
             parent_class->init (widget, gtk_widget);

             /* Mettre en cache une valeur dans l'implementation ATK */
             montype->cached_value = gtk_widget_function_call();

             /* Écouter un signal */
             gtk_signal_connect (GTK_OBJECT (gtk_widget),
                                 "type-signal",
                                 GTK_SIGNAL_FUNC (_mon_imp_atk_montype_signal_type),
                                 NULL);
          }

      Dans cet exemple, si le signal type-signal spécifié est généré par le `gtk_widget` auxiliaire alors la fonction `_mon_imp_atk_montype_signal_type()` est appelée.

   2. parent->notify_gtk

      Si l'implémentation d'ATK doit écouter toutes les notifications de propriété de l'objet GTK auxiliaire, une fonction `parent->notify_gtk()` peut être nécessaire. Par exemple :

      ###### Une fonction personnalisée `notify_gtk()`

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

             if (strcmp (pspec->name, "propriété-concernée") == 0)
             {
                /* Gestion de la modification de propriété. */
             }
             else
             {
                parent_class->notify_gtk (obj, pspec);
             }
          }

   3. parent->finalize

      S'il est nécessaire de libérer toutes les données quand une instance GObject est détruite alors il y a besoin d'une fonction `finalize()` pour libérer la mémoire. Par exemple :

      ###### Une fonction personnalisée `finalize()`

          void
          mon_imp_atk_montype_finalize (GObject *object)
          {
             MonImpAtkMonType *mon_type = MONIMPATK_MONTYPE (object);

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

### Rendre les composants personnalisés accessibles

L'ajout de la prise en charge ATK à votre élément graphique personnalisé assure de sa coopération avec les infrastructures d'accessibilité. Voici les étapes générales requises :

- accéder à un élément graphique personnalisé en suivant les directives d'interface utilisateur concernées ;

- déterminer quelles interfaces ATK un élément graphique personnalisé doit implémenter selon l'ensemble de ses fonctionnalités et la fonction de l'élément graphique ;

- évaluer quelles interfaces ATK peuvent être héritées de la classe de l'élément graphique parent ;

- implémenter les interfaces ATK appropriées pour la classe d'élément graphique d'une des deux façons suivantes :

  - directement par un élément graphique personnalisé ou

  - dans un sous-type AtkObject créé par une nouvelle sous-classe AtkObjectFactory.

  Si la seconde méthode est utilisée, le type de fabrique approprié doit être enregistré avec l'objet AtkObjectFactoryRegistry à l'exécution.

Le code source GAIL est un excellent tutoriel pour une utilisation avancée d'ATK.

### Directives pour la prise en charge de l'accessibilité dans l'interface utilisateur

Lors de la conception de l'interface graphique de votre application, il y a un certain nombre de directives simples que vous devez suivre pour être certain qu'elle puisse être utilisée par le plus grand nombre, que ce soit en conjonction avec des technologies d'assistance ou non. Ne faites pas l'erreur de penser qu'il s'agit seulement de « rendre l'interface graphique utilisable pour les personnes handicapées » et que vous n'avez pas à vous inquiéter de savoir si une personne possédant un handicap utilisera un jour votre application. Suivre ces directives améliorera l'ergonomie globale de votre application pour tous les utilisateurs, vous y compris.

#### Généralités

Nous sommes tous un jour ou l'autre frustrés de ne pas trouver une fonctionnalité dans une application ou de faire une erreur qui prend plusieurs minutes pour être corriger ; si c'est possible de la corriger. Si vous avez un handicap quelconque, il y a de bonnes chances que les efforts et la perte de temps soient bien plus importants. Suivez ces quelques directives de base pour prévenir ce type de situations pour tous les utilisateurs.

- Fournissez la possibilité d'annuler chacune des actions qui modifient les données de l'utilisateur ou les paramètres de l'application. Si possible, fournissez plusieurs niveaux d'annulation et de rétablissement, ainsi qu'un historique pour permettre de prévisualiser quelles actions seront annulées.

- Fournissez des commandes pour restaurer les paramètres par défaut. Si un paramètre particulier peut rendre l'application complètement inutilisable pour un individu, par exemple en réduisant la taille des polices, il est alors utile de fournir une option de restauration des paramètres par défaut en dehors de l'application elle-même. Par exemple, à l'aide d'une option en ligne de commande.

- Aidez les utilisateur à ne pas commettre d'erreurs. Ceci est particulièrement important pour des actions qui peuvent être lancées accidentellement (comme les actions avec la souris) ou qui ne sont pas faciles à annuler (comme l'écrasement d'un fichier). Considérez la possibilité d'utiliser des boîtes de dialogue de confirmation ou de forcer l'utilisation d'un mode particulier pour effectuer des actions potentiellement dangereuses.

- Minimisez le travail mémoire des utilisateurs. Par exemple, permettez à l'utilisateur de regarder plusieurs documents en même temps et assurez-vous que l'aide en ligne ou d'autres instructions peuvent rester visibles pendant que la tâche décrite est effectuée. Permettez le copier-coller de toutes les informations affichées partout où des données peuvent être saisies.

- Ne faites pas insérer de disques aux utilisateurs. En fonction du handicap de l'utilisateur, il se peut qu'il lui soit difficile d'insérer physiquement un disque ou de le changer, il se peut aussi qu'il ne soit pas capable d'identifier le bon disque dans un premier temps. Si votre application est installée à partir d'un CD-ROM, fournissez l'option de copier tous les fichiers nécessaires sur le disque dur de l'utilisateur.

- Ne placez pas les fonctions utilisées fréquemment profondément dans la structure des menus. Que vous utilisiez une souris, le clavier ou tout autre périphérique de saisie, il vaut mieux éviter les éléments de menus placés profondément. En plus de l'effort de mémoire pour les trouver, ils sont toujours plus difficiles et longs à accéder.

- N'imposez pas aux utilisateurs des étapes inutiles. Par exemple, les assistants sont utiles pour des utilisateurs qui ont des problèmes pour manipuler un grand nombre d'options à la fois, mais d'autres utilisateurs ont besoin de minimiser le temps et le nombre de saisies au clavier. Ces utilisateurs sont aidés s'il est possible de sauter des étapes inutiles et d'aller directement à l'étape voulue. Pensez à fournir dans les assistants un bouton Terminer qui va directement à la fin et utilise les réponses par défaut pour les étapes intermédiaires. Si le processus contient de nombreuses étapes, pensez à demander à l'utilisateur s'il souhaite effectuer toutes les étapes ou seulement celles utilisées le plus fréquemment.

#### Navigation au clavier

Une interface utilisateur clavier bien conçue joue un rôle important quand vous concevez un logiciel accessible. Les utilisateurs non-voyants peuvent naviguer plus efficacement dans le logiciel à l'aide du clavier, alors que l'utilisation de la souris dépend des retours d'informations visuels fonction de la position du pointeur. Il est aussi possible qu'un handicap moteur empêche un utilisateur d'utiliser la souris, à cause du degré de contrôle nécessaire à sa manipulation.

Il est donc important de rendre toutes les actions de la souris disponibles depuis le clavier et d'inclure une touche d'accès à toutes les barres d'outils, les menus, liens et boutons. Chaque fonction de votre application se doit d'être disponible en utilisant uniquement le clavier. Cachez votre souris lors de vos tests s'il le faut !

La plupart des fonctionnalités doivent être accessibles facilement à l'aide de mnémoniques et raccourcis clavier et de fonctions de navigation intégrées de la boîte à outils. Par contre, des opérations qui requièrent un glisser-déposer, par exemple, peuvent nécessiter plus de réflexion.

- Fournissez un accès clavier efficace pour toutes les fonctionnalités de l'application. Certains utilisateurs ne peuvent pas se servir d'une souris, et de nombreux « utilisateurs avancés » préfèrent utiliser le clavier. De nombreux périphériques de technologie d'assistance simulent des évènements claviers plutôt que des évènements souris. Comme la frappe est difficile voire même douloureuse pour certains utilisateurs, il est important de fournir une interface clavier qui minimise le nombre de frappes de touches nécessaire pour une tâche donnée.

- Utilisez un ordre de navigation clavier logique. Lors d'une navigation dans une fenêtre avec la touche Tab, le focus clavier doit se déplacer entre les contrôles dans un ordre prévisible. Dans les environnements linguistiques occidentaux, c'est habituellement de la gauche vers la droite et de haut en bas.

- Assurez-vous que l'ordre de parcours des contrôles avec la touche Tab reste correct pour ceux dont l'état activé dépend de l'état d'une case à cocher, d'un bouton radio et d'un bouton poussoir. Lorsqu'un bouton de ce type est sélectionné, tous les contrôles en dépendant doivent être activés et tous ceux qui dépendent d'un autre bouton du groupe doivent être désactivés. Lorsque l'utilisateur sélectionne une case à cocher, un bouton radio ou un bouton poussoir qui possèdent des contrôles en dépendance, ne donnez pas automatiquement le focus au premier contrôle dépendant mais laissez plutôt le focus sur le bouton qui commande cette dépendance.

- Ne sur-définissez pas les caractéristiques existantes d'accessibilité au niveau système. Par exemple, AccessX est une extension de Xserver qui est prise en charge depuis X11R6. La caractéristique MouseKeys de cette extension permet de simuler à l'aide du pavé numérique les déplacements de la souris et les clics de boutons. Par conséquent, vous ne pouvez pas ajouter des caractéristiques à l'application qui ne seraient atteintes qu'en utilisant le pavé numérique ; les utilisateurs comptant sur les fonctionnalités de MouseKeys ne pourraient plus les utiliser.

- Fournissez plus d'une méthode pour réaliser les tâches au clavier lorsque c'est possible. Certains utilisateurs peuvent trouver certaines touches ou combinaisons plus faciles que d'autres.

- Fournissez si possible la possibilité d'utiliser à la fois le clavier et la souris pour accéder à une fonction. Certains utilisateurs ne peuvent utiliser que le clavier ou la souris, mais pas les deux.

- N'attribuez pas de moyens d'accès complexes aux opérations clavier fréquemment utilisées. Certaines personnes ne peuvent utiliser qu'une seule main sur le clavier, donc les raccourcis utilisables facilement d'une seule main sont préférables pour les opérations courantes. Dans tous les cas, avoir à réaliser des extensions ou des positionnements difficiles sur le clavier augmente pour tous les utilisateurs le risque de se froisser un muscle, donc de douleurs ou de blessures.

- N'exigez pas des utilisations répétées d'appuis simultanés de touches. Certains utilisateurs ne sont capables que d'appuyer et tenir une seule touche enfoncée à la fois. Les technologies d'assistance telles que celles d'AccessX permettent aux utilisateurs d'appuyer sur les touches de manière séquentielle plutôt que simultanément, mais bien sûr cela signifie que l'opération prendra plus de temps pour eux.

- Assurez-vous que tout texte pouvant être sélectionné avec la souris puisse également l'être avec le clavier. C'est une facilité pour tous les utilisateurs, mais elle s'adresse plus spécialement à ceux qui ont des difficultés à contrôler finement le mouvement de la souris.

- Assurez-vous que les objets qui peuvent être redimensionnés ou déplacés par un glisser-déposer peuvent également l'être avec le clavier, par exemple les icônes ou les fenêtres sur le bureau. Lorsqu'un positionnement et un redimensionnement précis peut se révéler important (par ex. les formes dans un diagramme), pensez également à fournir, soit une boîte de dialogue dans laquelle l'utilisateur peut saisir des coordonnées, soit un moyen de placer les objets sur une grille définie par ce dernier.

- N'utilisez pas de fonctions générales de navigation pour déclencher des actions. Par exemple, n'utilisez pas l'usuelle navigation clavier avec la touche Tab dans une boîte de dialogue pour activer une action associée à un contrôle.

- Affichez les menus appelés par le clavier, les fenêtres et les infobulles auprès des objets auxquels ils sont associés. Dans GNOME 2.0, les utilisateurs peuvent activer les menus contextuels avec MajF10 et les infobulles avec MajF1. Toutefois, ne masquez ou n'obscurcissez pas entièrement l'objet auquel le menu ou l'infobulle se rapporte.

#### Interaction avec la souris

Prenez en compte le fait que tous les utilisateurs ne peuvent pas utiliser une souris avec la même dextérité et que certains d'entre eux peuvent aussi avoir des difficultés pour voir ou suivre le pointeur de la souris.

- Les entrées ne doivent pas dépendre du bouton central ou de droite. En plus d'être physiquement plus difficils à cliquer, certains dispositifs de pointage et de nombreux dispositifs de technologies d'assistance ne prennent en charge ou n'émulent que le bouton gauche de la souris 1. Certaines technologies d'assistance n'émulent même pas du tout la souris mais génèrent des évènements clavier à la place.

- Permettez à toutes les opérations d'être annulées avant leur fin. Un appui sur la touche Échap doit annuler toutes opérations de la souris en cours telles qu'une action de glisser-déposer d'un fichier ou le dessin d'une forme dans une application de dessin.

- Fournissez un retour visuel pendant toute la durée d'une opération de glisser-déposer. Quand la souris passe au dessus de cibles valides, mettez-les en évidence et modifiez le pointeur de la souris. Utilisez le pointeur de souris « dépôt impossible » lorsque vous passez au dessus de cibles de dépôt non valides. Consultez également les exemples d'interaction avec la souris.

- Ne déformez pas le pointeur de la souris ou ne restreignez pas le mouvement de la souris à une partie de l'écran. Cela peut interférer avec les technologies d'assistance et est habituellement perturbant pour les utilisateurs qui n'utilisent pas les technologies d'assistance.

- Ne créez pas de cibles trop petites pour la souris. En général, les cibles doivent être au minimum de la taille de la « zone sensible » autour de la bordure d'une fenêtre redimensionnable dans le gestionnaire/thème de fenêtres actuel ; en gardant à l'esprit qu'un utilisateur à mobilité ou vision réduite peut utiliser un gestionnaire de fenêtres avec des zones plus grandes que celles par défaut.

##### Exemples d'interaction avec la souris

###### Exemple de pointeur « dépôt impossible » de CDE/Motif

Exemple d'une forme de pointeur de « cible de dépôt non valide »

#### Éléments graphiques

Fournissez une option pour personnaliser la présentation de tous les éléments graphiques importants de votre application. Cela la rend plus facile d'utilisation pour des personnes ayant des problèmes visuels ou des difficultés de raisonnement.

- Ne codez pas de manière permanente les attributs graphiques tel que ligne, bordure ou largeur des ombres. Ces éléments devraient être idéalement lus depuis le thème GTK ou celui du gestionnaire de fenêtres. Si ce n'est pas possible, fournissez des options dans votre application pour les modifier.

- Fournissez des noms descriptifs pour tous les composants de l'interface. La bibliothèque GAIL fournit des descriptions accessibles par défaut pour de nombreux éléments graphiques GTK, mais vous devrez ajouter vos propres descriptions dans certains cas, par exemple les éléments graphiques qui utilisent une image au lieu d'un texte (par ex. un pot dans une palette de couleurs ou une icône sans étiquette). Pensez à remplacer les valeurs par défaut avec d'autres plus utiles ou plus spécifiques à l'application quand c'est possible.

- Permettez, si possible, l'affichage monochrome des éléments graphiques en couleurs (par ex. les icônes de barre d'outils). Ces images monochromes doivent s'afficher avec les couleurs de premier et d'arrière-plan que l'utilisateur a lui-même choisi (via son choix de thème GTK) pour une lisibilité maximale.

- Rendez les éléments de l'interface graphique facilement reconnaissables. Par exemple, ne forcez pas l'utilisateur à survoler un objet pour déterminer s'il est cliquable ou pas. Laissez suffisamment d'espace entre les objets et délimitez clairement les limites des objets. N'affichez pas d'élément dans l'interface graphique qui soient beaux mais ne servent à rien, sauf si vous fournissez une option pour les désactiver.

- Fournissez une option pour cacher les graphiques qui ne sont pas nécessaires à la compréhension. Les images peuvent distraire les utilisateurs ayant des difficultés de raisonnement. Les icônes du menu GNOME, par exemple, peuvent être désactivées tout en laissant les menu fonctionnels.

#### Police et texte

Même pour un utilisateur avec une vision normale, la majorité des informations et retours d'information sont textuels dans la plupart des applications. Il est donc critique de choisir et de positionner le texte soigneusement à l'écran, ainsi que de laisser le choix de la police et de sa taille à l'utilisateur, pour s'assurer que les personnes ayant des problèmes de vision puissent aussi utiliser votre application efficacement.

- Ne codez pas de manière permanente les styles et tailles des polices de caractères. L'utilisateur doit être capable d'adapter toutes les tailles et tous les styles. Si pour une raison quelconque vous ne pouvez pas rendre cette fonctionnalité disponible, ne codez jamais des tailles de police inférieures à 10 points.

- Fournissez l'option de désactiver toutes les toiles de fond graphiques ou « filigranes » placés derrière le texte. Ces images interfèrent avec le contraste entre le texte et l'arrière-plan, ce qui peut causer des difficultés pour les utilisateurs qui ont des problèmes de vision.

- Donnez aux objets un nom porteur de sens, même pris hors contexte. Les utilisateurs qui utilisent des lecteurs d'écran ou d'autres technologies d'assistance ne sont pas nécessairement capables de comprendre immédiatement la relation entre un contrôle et son environnement.

- N'utilisez pas la même étiquette plus d'une fois dans la même fenêtre. Si vous utilisez la même étiquette dans des fenêtres différentes, il est préférable qu'elles aient le même sens. Pour la même raison, n'utilisez pas d'étiquettes qui s'épellent différemment, mais qui se prononcent d'une façon proche, par ex. « emprunte » et « empreinte », car cela peut troubler les utilisateurs qui utilisent des lecteurs d'écran.

- Positionnez les étiquettes de façon consistante partout dans votre application. En général immédiatement sous les grandes icônes, à droite des petites icônes et au dessus ou à gauche des autres contrôles. Consultez les exemples de polices et de texte.

- Quand vous utilisez un texte statique pour nommer un contrôle, terminez l'étiquette par deux-points. Par exemple, Nom d'utilisateur : pour nommer une zone de texte dans lequel l'utilisateur doit saisir son nom d'utilisateur. Cela aide à l'identifier comme étiquette du contrôle plutôt que comme élément indépendant.

- Quand vous utilisez un texte statique pour nommer un contrôle, assurez-vous que l'étiquette précède le contrôle dans l'ordre de parcours des contrôles avec la touche Tab. Cela assure que le mnémonique (caractère souligné) que vous attribuez à l'étiquette active ou déplace le focus vers le contrôle correct quand il est utilisé.

- Fournissez des alternatives au WYSIWYG (What You See Is What You Get). Certains utilisateurs peuvent par exemple avoir besoin d'imprimer le texte avec des petites polices, mais d'utiliser des grandes polices d'écran pour l'édition. Les alternatives possibles sont soit l'affichage de tout le texte dans la même police et taille (toutes deux choisies par l'utilisateur), soit une option « retour à la ligne automatique » qui permet de lire tout le texte d'une fenêtre sans défilement horizontal, soit un affichage en colonne unique (le contenu de la fenêtre est sur une seule colonne bien qu'il soit imprimé sur plusieurs colonnes), soit un affichage texte-seulement pour lequel les graphiques sont remplacés par des substituants ou des descriptions textuelles. Si l'application possède des panneaux contenant des contrôles fils, pensez à permettre aux panneaux de se redimensionner en même temps que la fenêtre parente.

##### Exemples de polices et de texte

###### Placement correct des étiquettes pour divers éléments de l'interface graphique

Contrôle liste avec une étiquette au dessus Contrôle liste avec une étiquette au dessus

Grande icône de gestionnaire de fichiers avec une étiquette en dessous Grande icône de gestionnaire de fichiers avec une étiquette en dessous

Petite icône de barre d'outils avec une étiquette à droite Petite icône de barre d'outils avec une étiquette à droite

Contrôle de zone de sélection numérique avec une étiquette à sa gauche Contrôle de zone de sélection numérique avec une étiquette à sa gauche

#### Couleur et contraste

Un mauvais choix de couleurs à l'écran peut poser des problèmes pour les utilisateurs atteint de daltonisme (pour qui la teinte est importante) ou les mal-voyants (pour lesquels la luminosité/le contraste sont importants). En général, vous devez laisser à l'utilisateur la possibilité de personnaliser les couleurs dans toutes les parties de votre application qui transmettent des informations importantes.

Les utilisateurs qui ont des problèmes de vision peuvent avoir besoin d'un fort niveau de contraste entre les couleurs de l'arrière-plan et du premier plan. Souvent un arrière-plan noir et du texte blanc empêche l'arrière-plan de « baver ». Ces paramètres sont critiques pour les utilisateurs malvoyants.

- Ne codez pas de manière permanente les couleurs de l'application. Certains utilisateurs ont besoin de combinaisons de couleurs et de niveaux de contraste particuliers pour pouvoir lire l'écran confortablement. Les couleurs principales que vous utilisez dans votre application GNOME doivent donc provenir du thème GTK, pour que l'utilisateur puisse définir des couleurs lisibles pour toutes les applications simplement en changeant de thème. Si pour une raison quelconque, vous devez utiliser des couleurs qui ne sont pas disponibles dans le thème, assurez-vous qu'elles soient personnalisables dans l'application elle-même.

- N'utilisez pas la couleur comme seul moyen de distinguer les éléments d'informations. Toutes les informations doivent également être transmises par au moins une autre méthode parmi la forme, la position ou la description textuelle. Consultez la section exemples de couleurs et de contrastes.

- Prenez en charge tous les thèmes à fort contraste de GNOME. Assurez-vous que lorsqu'un de ces thèmes est sélectionné, tous les textes de l'application s'affichent avec les couleurs de premier plan et d'arrière-plan de fort contraste spécifiées par le thème.

- Assurez-vous que votre application n'est pas dépendante d'un thème à fort contraste particulier. Testez-la avec des différents thèmes à fort contraste pour vérifier que l'application respecte les réglages.

##### Exemples de couleur et contraste

###### Exemple d'utilisation redondante de couleurs

Exemple montrant des modifications du prix d'action utilisant uniquement la couleur

Cet affichage peut causer des problèmes pour un utilisateur daltonien au rouge et vert (le daltonisme atteint jusqu'à un homme sur sept dans certaines parties du monde). Le manque de contraste entre le texte rouge et le fond noir rend aussi le texte peu lisible pour une personne ayant une vision faible, même en utilisant la loupe.

Exemple montrant des modifications du prix d'action en utilisant la couleur et des flèches

Cet affichage renforce le code de couleur à l'aide de flèches pour afficher les modifications de cours et utilise des tons de vert et de rouge plus sombres sur un fond clair pour fournir plus de contraste. Il n'est pas nécessaire que ce schéma de couleurs soit celui par défaut si votre test montrent qu'il détourne trop l'attention de la majorité des utilisateurs, mais il doit être possible de le personnaliser de cette façon, soit en créant un thème ou via la boîte de dialogue Préférences de l'application.

#### Zoom

De nombreux utilisateurs, même ceux qui n'ont pas de problème de vue, tirent profit d'un agrandissement du texte et des images. Par contre sans agrandissement, un utilisateur malvoyant ne pourra sûrement pas accéder et utiliser le programme.

- Donnez la possibilité à l'utilisateur d'agrandir la zone de travail.

- Fournissez des options dans l'application pour changer l'échelle de la zone de travail. Les utilisateurs ont besoin d'une option pour agrandir la zone de travail de 150 à 400% et même parfois plus. Testez l'application pour vérifier que l'objet visualisé reste insensible aux modifications de taille.

#### Audio

Les personnes malentendantes, ainsi que celles qui coupent le son de l'ordinateur, seront désavantagées si votre application se base sur du son pour transmettre des informations. En général, assurez-vous que l'utilisateur puisse faire en sorte que les informations audio soient transmises d'une autre façon.

- Ne supposez pas qu'un utilisateur entendra les informations audio. Cela s'applique aussi bien aux utilisateurs dont la carte son est cassée qu'à ceux qui sont malentendants !

- N'utilisez pas l'audio comme seul moyen de transmettre les informations. Donnez la possibilité à l'utilisateur d'avoir aussi toutes les informations audio de façon visuelle. Ceci inclue la fourniture de légendes minutieuses ou de transcriptions de tous les messages sonores parlés importants.

- Permettez aux utilisateurs de configurer la fréquence et le volume de toutes les alarmes sonores et des autres sons. Cela comprend aussi la possibilité d'une coupure complète du son.

#### Animation

Utilisées avec parcimonie, les animations peuvent être utiles pour attirer l'attention vers des informations importantes dans votre application - et ça donne aussi un air branché. Cependant, cela peut causer des problèmes à certains utilisateurs donc, assurez-vous qu'ils puissent les désactiver.

- N'utilisez pas d'éléments qui flashent ou qui clignotent à une fréquence supérieure à 2 Hz et inférieure à 55 Hz. Cela vaut pour le texte mais aussi pour les images. Toute valeur comprise entre ces fréquences peut causer des problèmes pour les utilisateurs susceptibles d'avoir des crises épileptiques induites par la vision. Notez qu'aucune gamme fréquentielle n'est sûre. Si le clignotement est essentiel, vous devez utiliser la fréquence de clignotement du curseur (qui devrait être personnalisable) ou permettre aux utilisateurs de choisir la fréquence eux-mêmes.

- Ne faites pas flasher ou clignoter de grandes zones de l'affichage. Des petites parties sont moins susceptibles de déclencher des crises chez les personnes sensibles.

- Rendez toutes les animations optionnelles. Les informations animées doivent être disponibles au moins dans un format statique, à la demande de l'utilisateur.

#### Focus au clavier

Un affichage clair et permanent de la position du focus clavier est important pour les utilisateurs malvoyants ainsi que pour les « utilisateurs avancés » qui préfèrent utiliser le clavier plutôt que la souris. Il ne devrait jamais y avoir de confusion possible pour savoir lequel des contrôles sur le bureau possède le focus à un instant donné. Vous devez être capable de laisser votre ordinateur avec le focus sur n'importe quel élément graphique de l'application puis, d'aller téléphoner à votre ami(e), de sortir le chien jusqu'à ce que vous ayez oublié de quel élément graphique il s'agissait. Quand vous revenez, vous devez être capable de dire instantanément quel élément graphique possède le focus.

Un indicateur de focus visuel est une représentation audio de la position relative du curseur par rapport aux autres objets du bureau. Cela permet à l'utilisateur de se déplacer parmi les objets interactivement avec le changement de focus. Le focus visuel doit être programmé pour être analysé par les technologies d'assistance. Notez que c'est en général pris en charge automatiquement par ATK, sans que vous n'ayez à effectuer un travail supplémentaire. Cependant, vous devez être sensible à cette exigence quand vous écrivez vos éléments graphiques personnalisés par exemple.

- Au départ, donnez le focus au contrôle le plus utilisé. Si aucun contrôle ne peut être considéré comme le plus utilisé, donnez le focus au premier contrôle de la fenêtre quand celle-ci s'ouvre. Le focus ne doit pas être placé au départ sur les boutons Valider ou Annuler d'une boîte de dialogue, même si ce sont les plus utilisés, car ils peuvent toujours être activés immédiatement en appuyant sur Entrée ou Échap.

- Affichez le focus actuel de saisie clairement à tout moment. Rappelez-vous que dans les contrôles qui comprennent un élément de défilement, il n'est pas toujours suffisant de mettre en évidence l'élément sélectionné dans la zone de défilement car il peut ne pas être visible. Consultez les exemples de focus clavier.

- Affichez le focus de saisie seulement dans la fenêtre active. Masquez tous les indicateurs de focus visuel primaire de toutes les fenêtres qui ne sont pas actives ou n'ont pas le focus. Si une fenêtre possède plusieurs volets, un seul des volets doit avoir un indicateur de focus et les indicateurs de focus des autres volets doivent tous être cachés. S'il est important de continuer de montrer quel élément dans une liste sans focus est sélectionné, utilisez par exemple un indicateur de focus secondaire. Consultez les exemples de focus clavier.

- Fournissez un retour d'information approprié lorsque l'utilisateur tente de naviguer au delà d'un groupe d'objets liés. Lors du parcours d'une liste, par exemple, s'arrêter avec l'émission d'un son est préférable au retour au début de la liste. Sinon les utilisateurs aveugles ou malvoyants peuvent ne pas s'apercevoir qu'ils sont retournés au début. Dans le cas d'une recherche de texte dans un document, une boite de dialogue peut être ouverte pour indiquer que la fin du document a été atteinte et demander si la recherche doit être reprise au début du document.

- Utilisez l'alerte audio ou visuelle par défaut du système lorsque l'utilisateur appuie sur une touche incorrecte, ou quand une touche de navigation ne peut déplacer le focus. Par exemple, quand le focus est sur le premier caractère dans un champ de texte et que l'utilisateur appuie sur la flèche gauche, ou quand l'utilisateur essaie de faire une sélection multiple dans un dialogue à sélection unique (notez que les utilisateurs ayant des problèmes auditifs doivent avoir la possibilité de configurer un équivalent visuel système à l'alerte sonore par défaut).

##### Exemples de focus clavier

###### Exemple illustrant le besoin d'afficher le focus clairement

L'élément ayant le focus dans cette fenêtre est invisible car il a été déplacé hors de vue à l'écran | Un des contrôles dans cette fenêtre possède le focus, mais il est impossible de savoir lequel...
L'élément qui possède le focus dans la liste a été rendu visible en faisant défiler la liste | ... jusqu'à ce que vous fassiez défiler la liste, ce qui montre qu'un des éléments de la liste est actuellement sélectionné.
Le contrôle de liste de cet exemple possède une bordure pleine indiquant le focus, que l'élément sélectionné soit visible ou non | Si le contrôle de liste possède une bordure « de focus », il est facile de deviner qu'il possède le focus même si l'élément sélectionné n'est pas visible.

###### Exemple d'utilisation d'un focus secondaire

Fenêtre séparée en deux volets dans laquelle les deux volets semblent avoir le focus | Dans cet exemple, il est impossible de dire, seulement en regardant, lequel des deux volets possède le focus clavier.
Fenêtre séparée en deux volets dans laquelle la mise en évidence secondaire est utilisée pour indiquer le volet qui a le focus | Par l'utilisation d'une deuxième couleur de mise en évidence de sélection dans le volet inactif, il est immédiatement clair que le contrôle d'arborescence possède le focus ici...
Fenêtre séparée en deux volets dans laquelle la mise en évidence secondaire est utilisée pour indiquer le volet qui a le focus | ... et que le contrôle de liste possède le focus ici.

#### Synchronisation

Les interfaces où des choses apparaissent, disparaissent ou se produisent à des instants figés de façon permanente causent souvent des problèmes d'accessibilité. Certains utilisateurs lisent, saisissent ou réagissent très lentement par rapport à d'autres. Si les informations dont ils ont besoin sont masquées avant d'en avoir terminé avec elles ou que d'autres informations les cachent, sans qu'elles aient été demandées explicitement, alors votre application est très frustrante ou même impossible à utiliser.

- Ne codez pas de façon permanente des délais ou des fonctions basées sur le temps. Quelques exemples sont le défilement automatique lorsqu'un objet est déplacé près du bord d'une fenêtre, l'enfoncement du bouton d'une barre de défilement, ou le développement automatiquement d'une arborescence lorsqu'un objet est déplacé et laissé un court moment au dessus d'elle. Ceux-ci doivent être configurables dans l'application, via le centre de contrôle de GNOME ou, au pire, modifiable manuellement depuis la ligne de commande, via un fichier de configuration ou une entrée Gconf.

- N'affichez ou ne cachez pas brièvement des informations en fonction du mouvement du pointeur de souris (sauf pour les fonctions du système telles que les infobulles que l'utilisateur peut configurer au niveau du système). Si vous devez fournir de telles fonctions, assurez-vous qu'elles soient optionnelles afin que les utilisateurs puissent les désactiver quand un lecteur d'écran est installé.

#### Documentation

Les personnes avec des handicaps ne peuvent pas utiliser l'application de manière efficace s'ils n'ont pas accès aux manuels et aux fichiers d'aide nécessaires. La navigation au clavier est particulièrement importante, car c'est le seul moyen pour de nombreux utilisateurs de parcourir l'application.

- Fournissez toute la documentation dans un format accessible. Le texte au format ASCII et HTML sont tous deux excellents pour les technologies d'assistance.

- Fournissez des descriptions alternatives textuelles pour toutes les illustrations de la documentation.

- Documentez toutes les fonctionnalités d'accessibilité de votre application. Il est particulièrement important de documenter la navigation au clavier et les raccourcis. Ajoutez une section accessibilité à votre documentation contenant les informations spécifiques à l'accessibilité.

## Test

Il y a de nombreux points de contrôles à vérifier avant de déclarer qu'une application est accessible. Au cours du développement, vous pouvez vouloir utiliser des techniques de tests automatisées. Par exemple, Dogtail peut compléter votre plan de test automatisé.

Cette section décrit un certain nombre de tests que vous pouvez effectuer manuellement sur une application pour tester son accessibilité. Même si tous les tests sont réussis, cela ne veut pas nécessairement dire que l'application est entièrement accessible, par contre si l'application ne passe pas un de ces tests, du travail complémentaire doit être fait pour améliorer cet aspect de son accessibilité.

### Navigation au clavier

Les opérations au clavier suivantes doivent être testées. N'utilisez pas la souris dans ce qui suit.

- Uniquement à l'aide du clavier, déplacez le focus dans toutes les barres de menu de l'application.

- Vérifiez que :

  - les menus contextuels s'affichent correctement,

  - toutes les fonctions énumérées dans la barre d'outils peuvent être réalisées grâce au clavier,

  - vous pouvez actionner chaque contrôle dans la zone client de l'application et dans les boîtes de dialogue,

  - le texte et les objets dans la zone client peuvent être sélectionnés,

  - tous les raccourcis clavier ou touches de raccourci fonctionnent comme prévu.

### Éléments graphiques

Testez l'application avec un lecteur d'écran et vérifiez que :

- les étiquettes et le texte sont lus correctement, ainsi que les menus et les barres d'outils,

- les informations des objets sont lues correctement.

### Indicateur de focus visuel

- Vérifiez que lors de déplacements parmi les objets, l'indicateur de focus visuel est facile à identifier.

- La navigation au clavier dans le logiciel et les menus doit être clairement visible lors du déplacement du focus.

- Vérifiez que le lecteur d'écran suit l'indicateur de focus visuel lors de vos déplacements à l'aide du clavier.

- Utilisez le programme de loupe d'écran (s'il est disponible) et vérifiez que la loupe suit l'indicateur de focus visuel quand vous naviguez avec le clavier et la souris.

### Police et texte

- Modifiez la police de l'application et vérifiez que les réglages sont conservés.

- Testez l'application en changeant les couleurs et vérifiez que tous les réglages sont conservés.

- Si un zoom est possible, testez la police, la couleur et la taille en utilisant les options de zoom.

### Couleur et contraste

- Imprimez des captures d'écran en noir et blanc et vérifiez que toutes les informations sont visibles.

- Testez l'application en utilisant des réglages en noir et blanc uniquement et un fort contraste et vérifiez que toutes les informations sont transmises correctement.

- Testez que l'application fournit au moins trois combinaisons de schémas de couleurs et que des thèmes à fort contraste sont disponibles (par ex. blanc sur noir ou jaune sur bleu).

- Activez les paramètres à fort contraste dans le centre de contrôle de GNOME et vérifiez que l'application respecte ces paramètres.

- Testez plusieurs thèmes pour vous assurer que le logiciel fonctionne pour tous les réglages disponibles.

### Audio

L'application doit posséder une option pour afficher à l'écran les alertes sonores.

Vérifiez que le son fonctionne correctement en activant le son dans le centre de contrôle GNOME puis effectuez les tâches suivantes :

- effectuez une action qui doit générer une alerte sonore et vérifiez que l'application fonctionne comme prévu,

- vérifiez que l'application fonctionne correctement quand vous baissez ou augmentez le volume,

- vérifiez que les messages d'avertissement et les alertes peuvent être entendus correctement dans un environnement de travail bruyant.

### Animation

Vérifiez qu'une option est disponible pour arrêter les animations et qu'elle fonctionne comme prévu.

Désactivez les animations. Vérifiez que toutes les informations sont toujours transmises correctement.

### Focus au clavier

- Testez tous les messages pour vérifier que l'utilisateur est averti avant qu'il ne disparaisse et que l'option pour augmenter ce délai est disponible.

- Assurez-vous qu'il existe une option pour ajuster le temps de réponse et vérifiez qu'elle fonctionne comme prévu.

### Documentation

Testez la documentation en texte ASCII avec un lecteur d'écran pour vérifier qu'elle est claire et précise et peut être lue par les technologies d'assistance.

Testez les applications HTML en utilisant un navigateur Web et un lecteur d'écran pour vérifiez que la documentation est accessible aux technologies d'assistance.

Note : des directives pour l'accessibilité Web sont disponibles à l'adresse : http://www.w3.org/TR/WAI-WEBCONTENT/.

Vérifiez que les informations suivantes sont contenues dans la documentation :

- Indication si l'application ne prend pas en charge l'accès clavier standard utilisé par le système d'exploitation.

- Identification des commandes clavier particulières.

- Identification de toutes les fonctions d'accessibilité particulières.

- Si une action est documentée pour la souris, assurez-vous qu'il y ait une alternative au clavier.

### Liste de contrôle de l'interface utilisateur

Cette section résume les directives données par les directives pour la prise en charge de l'accessibilité dans l'interface utilisateur. Vous devez vous référer à cette section du guide pour plus d'informations sur les éléments de la liste de contrôle donnés ici.

Quand vous testez une application pour l'accessibilité, vous devez valider chaque élément de la liste. Pour chaque test, notez si l'application passe ou échoue ou si cela ne s'applique pas à l'application.

#### Liste de contrôle des principes généraux

PG | Principes généraux | Succès/échec/NA
--- | --- | ---
PG.1 | Toutes les actions qui modifient les données de l'utilisateur ou les paramètres de l'application peuvent être annulées.
PG.2 | Tous les paramètres de l'application peuvent être restaurés sans que l'utilisateur n'ait à se rappeler quels étaient les paramètres par défaut.
PG.3 | Après l'installation, l'application peut être utilisée sans que l'utilisateur n'ait à aucun moment à insérer une disquette ou un CD.
PG.4 | Les fonctions les plus fréquemment utilisées se trouvent au premier niveau de la structure des menus.

#### Liste de contrôle de la navigation à l'aide du clavier

NC | Navigation au clavier | Succès/échec/NA
--- | --- | ---
NC.1 | Toutes les fonctions de l'application sont disponibles de manière efficace avec le clavier.
NC.2 | L'ordre de navigation au clavier est logique dans toutes les fenêtres.
NC.3 | L'ordre de tabulation correct est utilisé pour les contrôles dont l'activation dépend de cases à cocher, boutons radio ou boutons poussoir.
NC.4 | Les touches d'accès clavier spécifiques de l'application ne supplantent pas les fonctions d'accessibilité du système.
NC.5 | L'application fournit, quand c'est possible, plus d'une méthode pour effectuer les tâches au clavier.
NC.6 | Il existe des combinaisons de touches alternatives partout où c'est possible.
NC.7 | Il n'y a pas de combinaisons de touches difficiles à effectuer pour les opérations clavier fréquentes.
NC.8 | L'application n'utilise pas de combinaisons d'enfoncements de touches simultanés et répétitifs.
NC.9 | L'application fournit un accès au clavier équivalent pour toutes les fonctions de la souris.
NC.10 | Tous les textes ou objets qui peuvent être sélectionnés avec la souris, peuvent l'être aussi uniquement à l'aide du clavier.
NC.11 | Tous les texte ou objets qui peuvent être redimensionnés ou déplacés avec la souris peuvent l'être aussi uniquement avec le clavier.
NC.12 | L'application n'utilise pas de fonctions de navigation générales pour déclencher des opérations.
NC.13 | Tous les menus appelés via le clavier, toutes les fenêtres et les infobulles apparaissent près des objets auxquels ils sont liés.

#### Liste de contrôle de l'interaction avec la souris

IS | Interaction avec la souris | Succès/échec/NA
--- | --- | ---
IS.1 | Aucune opération ne dépend d'appui sur les boutons droit ou milieu de la souris.
IS.2 | Toutes les opérations de la souris peuvent être annulées avant qu'elles ne se terminent.
IS.3 | Un retour visuel d'informations est fourni pendant les opérations de glisser-déposer.
IS.4 | Le pointeur de souris n'est jamais mis sous contrôle de l'application ou son mouvement n'est pas restreint à une partie de l'écran par l'application.

#### Liste de contrôle des éléments graphiques

EG | Éléments graphiques | Succès/échec/NA
--- | --- | ---
EG.1 | Il n'y a pas d'attribut graphique codé de manière permanente comme l'épaisseur des lignes, bordures ou ombres.
EG.2 | Tous les éléments graphiques multicolores peuvent être affichés, si possible, en monochrome.
EG.3 | Tous les éléments interactifs de l'interface graphique sont facilement différentiables des éléments statiques.
EG.4 | Il existe une option pour masquer les images non essentielles.

#### Liste de contrôle de la police et du texte

PT | Police et texte | Succès/échec/NA
--- | --- | ---
PT.1 | Le style et la taille des polices ne sont pas codés de manière permanente.
PT.2 | Il existe une option pour désactiver les toiles de fond graphiques derrière le texte.
PT.3 | Toutes les étiquettes possèdent des noms compréhensibles hors contexte.
PT.4 | Aucun nom d'étiquette n'est utilisé plusieurs fois dans la même fenêtre.
PT.5 | La position des étiquettes est homogène dans toute l'application.
PT.6 | Toutes les étiquettes textuelles statiques qui identifient d'autres contrôles se terminent par deux points (:).
PT.7 | Les étiquettes textuelles statiques qui décrivent d'autres contrôles, précèdent immédiatement ceux-ci dans l'ordre de tabulation.
PT.8 | Il existe une alternative au WYSIWYG. Par exemple, la possibilité de spécifier des polices d'affichage et d'impression différentes pour un éditeur de texte.

#### Liste de contrôle des couleurs et du contraste

CC | Couleur et contraste | Succès/échec/NA
--- | --- | ---
CC.1 | Les couleurs de l'application ne sont pas codées de manière permanente, mais sont extraites du thème de bureau actuel ou des paramètres de l'application.
CC.2 | La couleur n'est utilisée que pour mettre en évidence et non pas comme seul moyen de transmettre des informations ou des actions.
CC.3 | L'application prend en charge tous les thèmes et paramètres à fort contraste disponibles.
CC.4 | Le logiciel ne dépend pas d'un thème ou de paramètres à fort contraste particuliers.

#### Liste de contrôle des agrandissements

AG | Zoom | Succès/échec/NA
--- | --- | ---
AG.1 | L'application fournit la possibilité à l'utilisateur de faire un zoom de la zone de travail.
AG.2 | L'application fournit l'option de modifier l'échelle de la zone de travail.
AG.3 | Les fonctionnalités de l'application ne sont pas affectées par l'utilisation d'un agrandissement ou des paramètres d'échelles.

#### Liste de contrôle audio

AU | Audio | Succès/échec/NA
--- | --- | ---
AU.1 | Le son n'est pas utilisé comme seul moyen de transmettre une partie des informations.
AU.2 | L'utilisateur peut configurer la fréquence et le volume de tous les sons et les messages sonores d'alerte.

#### Liste de contrôle des animations

AN | Animation | Succès/échec/NA
--- | --- | ---
AN.1 | Il n'y a pas d'élément qui flashe ou clignote à une fréquence comprise entre 2 et 55 Hz.
AN.2 | Tout flash ou clignotement est restreint à une petite partie de l'écran.
AN.3 | Si une animation est utilisée, il existe une option pour la désactiver avant qu'elle ne soit affichée.

#### Liste de contrôle du focus clavier

FC | Focus au clavier | Succès/échec/NA
--- | --- | ---
FC.1 | Quand une fenêtre est ouverte, le focus est donné au contrôle le plus utilisé.
FC.2 | La position actuelle du focus de saisie est clairement affichée à tout moment.
FC.3 | La position du focus de saisie n'est affichée que dans une seule fenêtre à la fois.
FC.4 | Un retour d'information sonore ou visuel est fourni quand l'utilisateur tente de naviguer au delà du début ou de la fin d'un groupe d'objets liés.
FC.5 | Le signal d'avertissement sonore ou visuel par défaut est utilisé lorsque l'utilisateur appuie sur une touche incorrecte.
FC.6 | Il y a suffisamment d'informations audio concernant le focus visuel pour que l'utilisateur sache ce qu'il doit faire ensuite.
FC.7 | Pendant l'utilisation de technologies d'assistance, comme un lecteur d'écran ou un périphérique pour le braille, le programme actuel indique la position et le contenu de l'indicateur de focus visuel.

#### Liste de contrôle pour la synchronisation

SC | Synchronisation | Succès/échec/NA
--- | --- | ---
SC.1 | Il n'y a pas de délai ou de fonction basée sur le temps, codés de manière permanente dans l'application.
SC.2 | L'affichage ou le masquage d'informations importantes ne sont pas déclenchés uniquement par des déplacements de la souris.

#### Liste de contrôle de la documentation

DC | Documentation | Succès/échec/NA
--- | --- | ---
DC.1 | Toute la documentation est dans un format accessible, avec des descriptions alternatives fournies pour toutes les figures et diagrammes.
DC.2 | La documentation contient une section décrivant toutes les fonctions d'accessibilité.

### GOK (GNOME Onscreen Keyboard) : clavier visuel GNOME

Votre application doit être utilisable avec gok ; la saisie clavier doit être entièrement réalisée par gok et pas par le clavier. Le but ici est de travailler avec votre application, et le bureau en général, pour vous assurer que la saisie de tous types de caractères est possible avec le clavier visuel.

L'application gok est fournie avec le bureau GNOME et devrait donc déjà être présente. Pour une documentation complète, consultez le site officiel de gok.

Suivez les étapes suivantes pour vérifier le fonctionnement correct de gok avec votre application :

1. Connectez-vous au bureau GNOME

2. Lancez gok

3. Démarrez votre programme

4. Fournissez des entrées à votre application à l'aide d'un périphérique de pointage (par ex. souris ou capteur de mouvements de tête) et gok.

5. Utilisez les fonctions de prédiction de mot et d'auto-complétion de gok.

6. Vérifiez que gok active et désactive les menus et les boutons des barres d'outils en fonction du type d'application appelée ; par exemple, les menus et les boutons des barres d'outils sont désactivés pour la capplet « Propriétés de la police » , mais ces mêmes boutons sont activés pour l'application Gedit.

7. Vérifiez que la touche Composition fournie par le clavier visuel de l'application gok peut être utilisée pour saisir n'importe quel texte dans l'application sélectionnée ; lancez Gedit, cliquez sur la zone de texte puis, cliquez sur la touche de composition dans l'application gok. Sélectionnez les touches requises depuis le clavier visuel. Les caractères doivent s'afficher dans la zone de texte de Gedit.

8. Vérifiez que le bouton Lanceur permet à l'utilisateur de lancer n'importe laquelle des applications parmi Terminal, Navigateur Web ou Éditeur de texte.

9. Vérifiez que le bouton Activer permet à l'utilisateur d'activer n'importe quelle fenêtre d'une application actuellement en cours sur le bureau de l'utilisateur, ainsi que les tableaux de bord et le bureau GNOME.

10. Vérifiez que le bouton Menus affiche tous les menus disponibles dans l'application actuelle. Vérifiez qu'un clic sur un bouton de menu affiche le sous-menu et ses éléments. Enfin, vérifiez qu'un clic sur un élément de menu active cet élément. Par exemple, cliquez sur l'application Aide et soutien et cliquez sur le bouton Menus. La fenêtre GOK affiche maintenant les boutons Fichier, Aller à et Aide (les menus de l'application Aide et soutien). Cliquez sur le bouton Fichier et les boutons Nouvelle fenêtre et Fermer la fenêtre s'affichent (éléments du menu).

11. Vérifiez que la liste des boutons des Barres d'outils est complète. Par exemple, cliquez sur l'application Aide et soutien puis, cliquez sur le bouton Barres d'outils. La fenêtre GOK affiche maintenant les boutons Précédent, Suivant et Sommaire.

12. Vérifiez que le bouton Capturer l'IU affiche tous les objets boutons de la fenêtre d'application sélectionnée. Par exemple, ouvrez la capplet « Propriétés de la police » et cliquez sur le bouton Capturer l'IU dans la fenêtre GOK. La fenêtre GOK doit maintenant afficher les noms des boutons de la capplet : Sans, Sans-serif, Fermer et Aide.

### Accerciser

Accerciser et l'architecture d'accessibilité de GNOME

Accerciser est un explorateur d'accessibilité interactif Python pour le bureau GNOME. Il utilise AT-SPI pour inspecter et contrôler les éléments graphiques, il vous permet de vérifier si une application fournit les informations correctes aux technologies d'assistance et aux structures de tests automatiques. Accerciser utilise une structure de greffons que vous pouvez utiliser pour créer des visualisations personnalisées des informations d'accessibilité. La documentation complète se trouve dans le manuel officiel d'Accerciser. Pour une démonstration d'Accerciser et de PyATSPI (Python-wrappered access and usage of AT-SPI : accès Python-wrappered et utilisation de AT-SPI), consultez cet article. Pour une excellente visite guidée par son auteur, consultez l'article Make Your Application Accessible with Accerciser (Rendre son application accessible avec Accerciser).

Accerciser a en réalité remplacé l'outil at-poke plus ancien.