Project:Omega.org

Par Apple Computer, Inc. © 2005, le 29/04/2005,

traduit par Vincèn PUJOL, le 13/05/2005.

L’accessibilité représente l’accès efficace à l’information et aux technologies de l’information pour les personnes souffrant d’handicap.
L’engagement d’Apple pour l’accessibilité est enraciné dans la simplicité d’utilisation légendaire du Macintosh et est amélioré par les fonctions d’Accès Universel présentes dans Mac OS X.
A partir de la version 10.2 de Mac OS X, Apple a introduit une architecture d’accessibilité, qui définit comment des technologies d’assistance, telles qu’un lecteur d’écran ou une souris pilotée par les mouvements de tête, communiquent avec les programmes fonctionnant sous Mac OS X.

Ce document vous montre pourquoi vous devez rendre votre application accessible, un procédé qu’Apple nomme Activation de l’Accès. Une présentation des considérations de conception à prendre en compte lors du développement d’une application accessible, sera faite. Pour conclure, l’architecture d’accessibilité de Mac OS X sera décrite qui supporte à la fois l’utilisation de programmes compatibles et le développement des technologies d’aide.

A qui s’adresse ce Document ?

Pour atteindre le plus grand nombre d’utilisateurs, tous les programmes devraient être accessibles. De ce fait, tous les développeurs de logiciels devraient lire ce document pour apprendre comment l’accessibilité affecte leurs logiciels et comment Mac OS X gère l’accessibilité. Ce document est un pré-requis aux documentations spécifiques des frameworks Cocoa et Carbon, listées dans la section “A consulter également” qui décrit comment rendre accessible ce type de programmes.

Organisation de ce Document

Ce document contient les chapitres suivants:

• “Pourquoi rendre votre application accessible ?” vous aidera à justifier les coûts de développement nécessaires pour rendre votre application accessible.
• “Développer une application accessible” décrit les éléments à prendre en compte lors de la conception et montre comment rendre une application compatible avec l’accessibilité.
• “Le protocole de l’accessibilité de Mac OS X” donne une vue générale sur l’architecture d’accessibilité de Mac OS X.
• “Tester l’accessibilité” décrit l’utilisation des outils d’Apple pour tester l’accessibilité de vos programmes.
• “Raccourcis clavier de l’accessibilité” liste les raccourcis claviers réservés par Mac OS X aux fonctions d’accessibilité.

A consulter également

En plus du document Accessibility Overview, la documentation développeur d’Apple inclut plusieurs documents qui couvrent le sujet de l’accessibilité. Les documents qui couvrent des domaines spécifiques sont indiqués ci-après (en anglais).

• Getting Started with Accessibility
• Accessibility Programming Guidelines for Carbon
• Accessibility Programming Guidelines for Cocoa
• Accessibility Reference for Assistive Applications
• Carbon Accessibility Reference
• NSAccessibility Reference

En plus de ces documents, Apple maintient un site Web dédié à l’accessibilité dans Mac OS X, avec des liens vers d’autres documents concernant les technologies d’aide compatibles:

• http://www.apple.com/accessibility

Pourquoi rendre votre application accessible ?

L’accessibilité va au-delà de simplement fournir un remplaçant à une interface utilisateur pilotée à la souris. En son coeur, le but est de permettre aux gens de travailler correctement et de gérer leur vision et leur mode de travail uniques.

Ce chapitre présente plusieurs raisons sérieuses pour lesquelles vous devriez développer toutes vos applications en les rendant accessibles. Si vous souhaitez rendre vos applications accessibles, vous devriez lire ce chapitre. Ensuite, vous devriez lire les chapitres suivants pour découvrir comment Mac OS X gère l’accessibilité et la facilité que cela représente de l’incorporer dans la plupart des programmes.

Si vous développez des programmes d’aide, vous serez plus intéressés par comment Mac OS X supporte l’accessibilité. Vous pouvez choisir de passer directement à “Le protocole de l’accessibilité de Mac OS X” pour en savoir plus sur le protocole supporté par Mac OS X.

Augmenter votre base d’Utilisateurs

Des millions de personnes souffrent d’un handicap ou ont des besoins spécifiques. Cela inclut les personnes souffrant de problèmes d’audition ou de vue, et les difficultés cognitives ou d’apprentissage. L’accès aux ordinateurs est vitale pour ces personnes, car l’informatique peut apporter un niveau d’indépendance difficile à obtenir autrement.

Les populations dans le monde vieillissant de plus en plus, un nombre sans cesse plus important de personnes sont confrontées à des handicaps dûs à l’age, tel que la perte d’audition ou de la vue. Contrairement aux générations précédentes, les membres de la population vieillisante actuelle sont beaucoup plus habitués à utiliser l’informatique dans leur vie quotidienne. Ils sont plus enclins à stocker une grande partie de leurs données sous forme informatique et à utiliser les moyens modernes de communication. Les générations actuelles et futures vieillissantes s’attendent à continuer à utiliser leurs ordinateurs et leurs données, quelque soit l’état de leur vue et de leur audition. Les programmes qui gèrent les grosseurs variables de texte, l’accès par un lecteur d’écran, ou la substitution des repères visuels par des repères auditifs peuvent aider également cette population.

Même les personnes qui ne s’identifient pas forcément comme handicapés peuvent bénéficier de moyens alternatifs pour interagir avec les programmes. Par exemple les personnes souffrant du syndrome du canal carpien préfèreront des raccourcis claviers à l’utilisation d’une interface à la souris. En fournissant différents moyens d’utiliser vos programmes, vous permettez aux utilisateurs de choisir leurs propres façons de travailler et de s’exprimer, ce qui élargit votre gamme d’utilisateurs.

Pénétrer de Nouveaux Marchés

Les réglementations fédérales comme la section 508 du Rehabilitation Act de 1973 aux Etats-Unis stipulent que les ordinateurs utilisés en milieu gouvernemental ou universitaire doivent fournir dans la mesure du possible un accès adapté aux personnes souffrant d’handicap. Du fait que ces lois et d’autres prennent effet, la pénétration de ces marchés est dépendant de la capacité à fournir des programmes accessibles.

Comme les problèmes de localisation il y a quelques années, l’accessibilité est passée du stade d’une bonne idée à un élément essentiel dans la compétition entre programmes. Apple a pour volonté de fournir la meilleure plateforme pour pénétrer ces marchés.

Tirer Avantage des Fonctions d’Aide de Mac OS X

Mac OS X est conçu pour tirer profit des technologies d’aide et intègre de nombreuses fonctionnalités pour aider les personnes handicapées. Les utilisateurs accèdent à la plupart de ces fonctionnalités par le panneau Accès Universel des Préférences Systèmes. Quelques unes de ces fonctionnalités intégrées tirent profit de la même architecture d’accessibilité que les outils externes d’aide utilisent pour accéder à vos programmes.

Par exemple, VoiceOver, logiciel de lecture de l’interface des programmes introduit avec Mac OS X 10.4, s’appuie sur l’architecture d’accessibilité pour rendre la navigation et l’utilisation du système accessible aux utilisateurs souffrant de problèmes de vue. Si vous rendez votre application compatible, VoiceOver aidera une personne malvoyante à l’utiliser.

Cela n’est pas compliqué

Mac OS X version 10.2 et supérieur intègre la gestion de l’accessibilité. Plus spécifiquement, aussi bien Carbon que Cocoa gèrent l’accessibilité dans leurs APIs. Cela signifie que la plus grande partie de l’accessibilité est librement disponible pour vos applications que vous développez avec ces frameworks. Cela vous permet de vous concentrer uniquement sur les points spécifiques à votre application pour les technologies d’aide, ce qui améliore le confort des utilisateurs et met en avant les fonctionnalités uniques de votre application.

Si vous avez déja un programme existant, vous découvrirez que l’architecture d’accessibilité de Mac OS X est conçue pour vous permettre de rendre compatible votre application de façon sélective. Cela vous permet de profiter des avantages de l’accessibilité sans avoir à modifier la conception de votre programme. Lorsque vous êtes prêts à rendre votre programme compatible, assurez-vous de lire le document qui correspond au framework choisi:

• Accessibility Programming Guidelines for Cocoa
• Accessibility Programming Guidelines for Carbon

Développer une application accessible

Concevoir une application en gardant à l’esprit l’accessibilité vous permet non seulement d’avoir un plus grand nombre d’utilisateurs, mais aussi d’avoir une meilleure expérience de la part des utilisateurs. Vous avez déja pris la décision de développer vos programmes pour Mac OS X. Maintenant, assurez-vous que vous pouvez apporter la meilleure ergonomie à tous vos utilisateurs.

Ce chapitre décrit un certain nombre de points à considérer lors de la conception d’une application. Si votre programme prévoit de supporter les fonctionnalités d’accessibilité décrites dans ce chapitre, cela sera encore plus facile à intégrer.

Malgré que ce chapitre soit plus spécifiquement dédié aux développeurs en phase de spécification d’une application, un certain nombre de points concernant l’accessibilité sont présentés qui devraient être connus de tout développeur.

Requis de Base pour la Conception

Comme première étape lors de la conception, vous devriez vous familiariser avec les informations présentes dans le document Apple Human Interface Guidelines.
Ce document présente les meilleurs usages en terme de conception pour vous permettre de créer une application de première qualité pour Mac OS X. Egalement, Apple Human Interface Guidelines apporte des renseignements détaillés pour la conception et l’implémentation d’une interface utilisateur intuitive, logique, et agréable esthétiquement, de façon à apporter à l’utilisateur le très grand confort auquel il est habitué avec le Macintosh.

Lors de la phase de conception, vous devez être conscient de nombreux points concernant l’accessibilité en relation avec les contraintes de conception et d’étude. Cette section décrit comment intégrer l’accessibilité dans vos décisions de conception les plus fondamentales. Comme pour la plupart des questions de développement avec l’accessibilité, les incorporer dans votre conception dès le départ permettra une bien meilleure maniabilité pour vos utilisateurs.

Les principes de conception décrits ici sont très importants à prendre en compte lors du développement d’une application accessible:

• Navigation complète au clavier. Pour beaucoup d’utilisateurs, une souris est difficile, voire impossible, à utiliser. De ce fait, l’utilisateur doit pouvoir accéder à toutes les fonctionnalités de votre programme en utilisant uniquement le clavier.

  Prendre cela en considération permettra de rendre accessible votre application beaucoup plus facilement.

• N’écrasez pas les raccourcis claviers du système.
  Cela s’applique aussi bien aux raccourcis claviers de Mac OS X (dont la liste figure dans le document Apple Human Interface Guidelines appendice “Keyboard Shortcuts
  Quick Reference”) qu’aux raccourcis claviers dédiés à l’accessibilité (indiqué dans “Raccourcis clavier de l’accessibilité”).
  De façon générale, vous ne devriez jamais écraser des raccourcis claviers réservés. Plus spécifiquement, vous devez prendre soin de ne pas remplacer des raccourcis claviers spécifiques à l’accessibilité sinon vos applications seront inaccessibles aux utilisateurs qui activent la fonction Accès complet au clavier.

  Un principe similaire est d’éviter de créer trop de raccourcis claviers spécifiques à votre application. Les utilisateurs ne doivent pas avoir à mémoriser un nouveau jeu de commandes claviers pour chaque programme qu’ils utilisent.

• Développer des remplaçants pour les opérations de Glisser/Déposer (Drag and Drop).
  Si votre application s’appuie sur le glisser/déposer dans son fonctionnement, vous devez fournir un autre moyen de réaliser les mêmes tâches. Cela peut ne pas être évident; en fait, cela peut nécessiter le développement d’une interface séparée pour les programmes utilisant intensivement le glisser/déposer.

  Par exemple, le Finder originel de Mac OS X était conçu pour fournir une interface simple en glisser/déposer pour le système de fichiers. De façon à conserver la compatibilité avec l’accessibilité, le Finder depuis Mac OS X 10.2 intègre la gestion du clavier qui permet aux utilisateurs de copier et déplacer des fichiers en utilisant les touches plutôt que la souris.

• S’assurer de toujours disposer d’une porte de sortie dans le programme.
  Cela est important pour tous les utilisateurs, bien sûr, mais c’est indispensable pour les utilisateurs de technologies d’aide. Un utilisateur s’appuyant sur une application assistée peut avoir une vue relativement étroite de votre programme. De ce fait, il est très important de pouvoir annuler des opérations et retracer les étapes aisément.

Attention à certains handicaps spécifiques

Suivre les indications du document “Basic Design Requirements” vous aidera à concevoir un programme facile à utiliser et qui sera donc facile à rendre accessible. Il peut y avoir des informations spécifiques à certains handicaps que vous ne connaissez pas cependant, et ces informations sont importantes à avoir à l’esprit lors de la phase de conception.

Les chapitres suivants décrivent une large gamme d’handicaps et proposent des solutions ou des idées pour des solutions de conception spécifiques et les adaptations que vous pouvez faire. L’objectif principal de ces suggestions est de proposer le plus grand nombre de solutions de substitutions pour l’affichage de contenus. Le plus de façons possibles votre programme présente les informations, au mieux vos utilisateurs trouveront une façon qui leur convient.

Handicaps Visuels

Les handicaps visuels incluent les aveugles, les daltoniens, et la vue faible. En plus de rendre votre application exploitable par les technologies d’aide, tels que les lecteurs d’écrans, vous devez aussi prendre en compte les points suivants:

• Même si les couleurs peuvent améliorer grandement l’interface utilisateur, assurez-vous que ce ne soit pas la seule source d’information. Un daltonien ne pourrait pas faire le distinguo entre deux éléments dont la seule différence est la couleur.
• Fournir une solution audio à tous les indicatifs visuels et les retours d’information. Votre application doit permettre un remplacement aisé de toutes les indications visuelles par des indications sonores.
• Fournir un moyen pour présenter les images et les contenus animés d’une façon différente. Si votre programme affiche ce genre d’éléments, pensez à fournir vos propres descriptions succintes de ces éléments afin que les aveugles ou les personnes avec une vue très réduite puissent bénéficier de l’information présentéee.

Handicaps Auditifs

Les personnes souffrant de problèmes d’audition peuvent rencontrer des difficultés pour distinguer les effets sonores de votre programme du bruit ambiant ou même être totalement incapable de les entendre. Même les utilisateurs sans difficultés auditives peuvent se trouver dans des circonstances où des avertissements sonores ne sont pas adéquats (dans une bibliothèque par exemple). Pensez à prendre en compte ces éléments lorsque vous concevez la partie audio de votre programme.

Votre application ne doit pas modifier les réglages de sortie audio définis par l’utilisateur dans les Préférences Systèmes. De plus, vous devez fournir des indications visuelles à tous les avertissements et signalisations sonores. Votre application doit permettre de remplacer facilement toutes les indications auditives par des avertissements visuels. Par exemple, un “bip” peut être remplacé ou accompagné facilement d’un flash sur l’écran.

Handicaps Cognitifs et Moteurs

Les personnes atteintes d’un handicap moteur peuvent avoir besoin d’utiliser des dispositifs de saisie différents du clavier et de la souris standards. D’autres utilisateurs peuvent rencontrer des difficultés avec la finesse de mouvement nécessaire pour faire un double-clic à la souris, ou une combinaison de touches sur le clavier. Les utilisateurs avec des difficultés d’apprentissage ou des problèmes cognitifs peuvent avoir besoin de plus de temps pour réaliser certaines actions ou répondre aux messages d’avertissement.

Pour la plupart, le support des handicaps moteurs est fourni par le matériel ou au niveau du système d’exploitation. Mac OS X fournit beaucoup de solutions de ce type dans les préférences d’Accès Universel. La fonctionnalité des Touches à auto-maintien, par exemple, permet de saisir les touches d’une combinaison clavier l’une après l’autre séquentiellement. En tant que développeur d’applications, la chose la plus importante que vous ayez à faire est de rendre vos applications compatibles pour permettre aux utilisateurs de déployer les techniques d’aide de leur choix.

Une fonction telle que les touches à auto-maintien peut aussi être utile à un utilisateur avec un handicap cognitif ou moteur qui rend difficile la réalisation de tâches simultanées. Une application qui fournit ses résultats à la fois sous formes sonore et visuelle (tout particulièrement simultanément) peut améliorer la compréhension. Les utilisateurs avec ce type de handicap bénéficient également de la redondance fournie par une application qui donne des indications à la fois sonore et visuelle.

En plus de rendre votre application accessible, vous devriez penser à intégrer également les fonctionnalités suivantes:

• Permettre la modification des temps de réponse des utilisateurs. Les utilisateurs ayant des difficultés à répondre rapidement aux évènements des programmes bénéficient ainsi de temps supplémentaire. Quand une réponse est nécessaire dans un temps imparti - tel qu’une notification qu’une action planifiée régulière va se produire - vous devez fournir au moins un moyen d’interaction qui ne nécessite pas de répondre dans un temps imparti. Vu d’une autre façon, vous devez fournir au moins une manière qui permette aux utilisateurs de régler les délais de réponse à au moins cinq fois le réglage par défaut.
• Eviter le clignotement régulier de curseurs ou d’icônes sur l’écran. La fréquence de clignotement d’un objet ne doit pas être dans la gamme 2 hertz à 55 hertz inclus. Les objets qui clignotent dans cette gamme de fréquences peuvent provoquer des complications médicales, telles que des attaques, chez certaines personnes.

Le protocole d’Accessibilité de Mac OS X

Depuis Mac OS X 10.2, Apple a introduit un framework d’accessibilité. Ce framework inclut:

• Le protocole d’accessibilité implémenté dans les frameworks Carbon et Cocoa qui permet aux technologies et outils d’aide d’interagir avec les programmes
• Les APIs utilisés par les programmes d’aide pour contrôler l’interface utilisateur d’une autre application fonctionnant sous Mac OS X

Ce chapitre présente le protocole d’accessibilité. Il décrit:

• Le modèle qui représente les applications accessibles aux technologies d’aide
• L’objet d’accessibilité qui représente les objets de l’interface utilisateur
• Quelques uns des moyens par lesquels une application d’aide interagit avec une application accessible

Si vous êtes un programmeur, vous devriez lire ce chapitre pour en savoir plus sur le protocole d’accessibilité de Mac OS X. Ensuite, si vous êtes prêts à rendre votre programme accessible, vous devriez lire Accessibility
Programming Guidelines for Cocoa ou Accessibility
Programming Guidelines for Carbon.

Important:Si votre programme utilise uniquement les objets standards, non personnalisés Carbon ou Cocoa, la majorité de votre application est déja accessible. Il reste quelques petites choses à faire néanmoins. Ce chapitre fournit des informations de base sur le protocole d’accessibilité qui vous aidera à comprendre pour quelles raisons quelques éléments doivent être faits par vous-même.

Remarque: Les développeurs Java doivent implémenter l’API d’accessibilité Java (l’ensemble javax.accessibility) pour garantir que leurs programmes soient accessibles (les interfaces Swing et AWT sont aussi accessibles l’une que l’autre). Pour plus de détails sur cette API, consulter la documentation de référence API Java 1.4.2 dans la documentation Java Reference Library.

Si vous développez un programme d’aide, vous devriez lire ce chapitre pour comprendre comment les applications accessibles se représentent dans Mac OS X. Vous y apprendrez quelles informations votre programme d’aide peut s’attendre à recevoir d’une application accessible. Pour des informations spécifiques sur l’utilisation des APIs d’accessibilité dans une application assistée, se reporter au document Accessibility Reference for Assistive Applications.

Le Modèle d’Accessibilité

Une application d’aide aide l’utilisateur à interagir avec les programmes présents sur son ordinateur. Pour cela, une application d’aide doit avoir un accès complet à l’interface utilisateur du programme et à toutes ses fonctions. De ce fait, pour être accessible, un programme doit fournir des informations sur son interface utilisateur et ses possibilités de façon standard afin que toute application ou technologie d’aide puisse y accéder.

Cela représente un vrai challenge car chaque programme a sa propre façon de représenter l’interface utilisateur. Les programmes Cocoa, par exemple, utilisent les classes NSWindow et NSControl pour afficher les fenêtres et les contrôles. Une application récente Carbon, d’un autre côté, utilise les objets HIObject et HIView pour implémenter son interface utilisateur. D’autres types d’applications utilisent d’autres éléments natifs de construction.

Apple a réesolu ce problème dans Mac OS X 10.2 avec l’introduction d’un objet générique, appelé un objet accessibilité. Dans une application accessible, un élément de l’interface utilisateur, tel qu’une fenêtre, un contrôle, et même l’application elle-même, sont représentés par un objet accessibilité. Pour en savoir plus sur l’objet accessibilité et les informations qu’il fournit, se reporter au document “L’objet
accessibilité”.

Les objets accessibilité apportent une représentation uniforme des éléments de l’interface utilisateur d’une application sans considération du framework dont dépend l’application. Le schéma 3-1 montre comment une application d’aide communique avec différents types de programmes en utilisant les objets accessibilité que les programmes contiennent.

Schéma 3-1 : Communication entre une application d’aide et d’autres programmes

Le modèle d’accessibilité de Mac OS X représente l’interface utilisateur d’une application comme une hiérarchie d’objets accessibilité. Pour la plupart, la hiérarchie est définie par les relations père-enfant entre les objets accessibilité. Par exemple, une boite de dialogue d’un programme peut contenir plusieurs boutons. L’objet accessibilié représentant la boite de dialogue contient une liste d’objets accessibilité enfants, chacun représentant un bouton dans la boite de dialogue. En retour, chaque objet accessibilité représentant un des boutons sait que son parent est l’objet accessibilité représentant la boite de dialogue.

Bien sur les objets accessibilité représentant la barre de menus et les fenêtres dans une application sont des enfants d’un objet accessibilité au niveau de l’application. Même l’object accessibilité du programme a un parent, qui est l’objet accessibilité de l’ensemble du système. Un programme n’a jamais besoin de se préoccuper de son parent système car cela est hors du champ du programme. D’un autre côté, un programme d’aide peut interroger l’objet accessibilité du système pour savoir quelle application en cours est au premier plan.

Le schéma 3-2 représente la hiérarchie des objets accessibilité dans un programme simple.

Schéma 3-2 : Hiérarchie des objets accessibilité

Un point fort de la hiérarchie des objets d’accessibilité est qu’elle peut laisser de côté la gestion de détails spécifiques qui ne s’appliquent pas à une technologie d’aide et, par extension, à l’utilisateur. Par exemple, en Cocoa, un bouton dans une fenêtre est habituellement codé comme une cellule bouton dans un contrôle bouton, ce qui est une vue de contenu dans une fenêtre. Un utilisateur n’a aucun intérêt dans le contenu détaillé de cette hiérarchie; on a seulement besoin de savoir qu’il y a un bouton dans une fenêtre. Si la hiérarchie d’accessibilité du programme contient un objet d’accessibilité pour chacun de ces objets intermédiaires, malheureusement, une application d’aide n’a pas d’autre possibilité que de les présenter à l’utilisateur. Cela entrainera beaucoup d’inconfort car l’utilisateur sera obligé de passer plusieurs étapes pour aller de la fenêtre au bouton. Le schéma 3-3 montre à quoi peut ressembler une telle hiérarchie.

Schéma 3-3: Hiérarchie d’héritage complète d’un bouton dans une fenêtre

Pour exclure ces informations inutiles, le protocole d’accessibilité permet à un programme d’indiquer des objets accessibilité à ignorer. Pour continuer avec l’exemple du bouton Cocoa, le programme peut indiquer que les objets accessibilité représentant le controle du bouton et la vue de son contenu doivent être ignorés. Cela permet à un programme de présenter à un programme d’aide uniquement les éléments significatifs de sa hiérarchie d’accessibilité. Le schéma 3-4 montre comment la même hiérarchie montrée au schéma 3-3 peut être présentée à une application d’aide.

Schéma 3-4: Hiérarchie correcte d’accessibilité à un bouton dans une fenêtre

Une technologie d’aide assiste l’utilisateur dans la réalisation de tâches en lui indiquant les objets accessibilité d’un programme qui permettent de réaliser des actions. Pour la plupart, les actions correspondent à des choses que l’utilisateur peut réaliser avec un simple clic de souris. Chaque objet accessibilité contient des informations sur les actions qu’ils gèrent, s’il y en a. L’objet accessibilité représentant un bouton, par exemple, supporte l’action d’appui. Lorsque l’utilisateur veut appuyer sur un bouton, il l’indique au programme d’aide. Le programme d’aide détermine que l’objet accessibilité du bouton supporte l’action d’appui et envoie la requête au bouton pour qu’il le fasse.

Le protocole d’accessibilité de Mac OS X prévoit seulement un certain nombre d’actions que les objets accessibilité peuvent supporter. Tout d’abord, mais cela peut sembler restrictif, du fait que les programmes peuvent réaliser un nombre considérable de tâches. Il est fondamental, cependant, de se rappeler qu’une application d’aide assiste l’utilisateur dans son utilisation de l’interface utilisateur d’un programme, elle ne simule pas les fonctions du programme. De ce fait, un programme d’aide n’a aucun intérêt à savoir ce que fait le programme lorsque l’on appuie sur un bouton, par exemple. Son travail est de dire à l’utilisateur que le bouton existe et d’indiquer au programme quand l’utilisateur veut appuyer dessus. C’est ensuite à la charge de votre programme de répondre correctement à l’appui du bouton, de la même façon qu’il le ferait si l’utilisateur avait appuyé sur le bouton de la souris.

L’Objet Accessibilité

Un objet accessibilité fournit des informations aux applications d’aide sur l’objet interface utilisateur qu’il représente. Cette information inclut la position de l’objet dans la hiérarchie d’accessibilité, sa position sur l’écran, les détails de ce qu’il représente, et les actions qu’il peut provoquer. En plus, un objet accessibilité répond aux messages envoyés par les applications d’aide et renvoie des messages décrivant ses changements d’état.

Ce chapitre décrit l’objet accessibilité. Il décrit l’information que fournit l’objet et les actions qu’il peut réaliser, il détaille également la communication entre les objets et les applications d’aide.

Remarque: Carbon et Cocoa implémente de façon différente mais nativement l’objet accessibilité. Ce chapitre décrit l’objet accessibilité de façon générale hors des spécificités de chaque framework. Pour les détails spécifiques à chque framework sur l’implémentation et l’utilisation de l’objet accessibilité, se reporter aux documents Accessibility Programming Guidelines for Cocoa et Accessibility Programming Guidelines for Carbon.

Les Attributs

Un objet accessibilité contient de nombreux attributs. Le nombre et le type d’attributs varient selon l’élément de l’interface utilisateur que l’objet représente. Quelques attributs sont indispensables pour tout objet, mais la plupart sont optionnels.

Les attributs ont des valeurs utilisées par les programmes d’aide pour connaitre l’objet de l’interface utilisateur. Par exemple, l’application d’aide obtient la valeur d’un attribut d’un objet pour déterminer quel type d’objet de l’interface utilisateur il représente.

Certaines valeurs d’attribut sont modifiables par le programme d’aide. Un exemple en est l’attribut qui représente un champ texte modifiable. Lorsque l’utilisateur saisit du texte, un programme d’aide modifie la valeur de l’attribut avec le texte saisi.

Si vous utilisez les objets standards, non modifiés Cocoa ou Carbon, la plupart des valeurs des attributs sont déja renseignés. Il y a cependant quelques valeurs d’attributs que vous devez fournir, car elles sont spécifiques à votre programme, tel que la description de la fonction des objets de l’interface utilisateur.

Le fichier AXAttributeConstants.h du framework HIServices définit tous les attributs d’objet accessibilité du protocole accessibilité de Mac OS X. Les chapitres suivants décrivent quelques uns des attributs les plus courants, en prêtant tout spécialement attention aux attributs pour lesquels vous devez fournir des valeurs:

• “Le Rôle et la Description du Rôle des Attributs”
• “L’Attribut de Description”
• “Les Attributs Titre”
• “Les Attributs de Relation”
• “Les Attributs de Valeur”

Le Rôle et la Description du Rôle des Attributs

L’attribut le plus important d’un objet accessibilité est l’attribut rôle. En effet le rôle de l’objet détermine quels autres attributs l’objet contient et indique comment les gérer à un programme d’aide. Vous pouvez imaginer le rôle comme la classe de l’objet - il définit un jeu standard de comportements et de possibilités auxquels l’objet se conforme. Pour plus d’informations sur les attributs associés à des rôles spécifiques, consulter la documentation “Roles
and Associated Attributes” (en anglais).

La valeur de l’attribut rôle est une chaine de caractères non localisée. Un logiciel d’aide peut tester par programme la valeur de l’attribut rôle afin de déterminer quel type d’objet de l’interface utilisateur l’objet accessibilité représente.

Dans le fichier AXRoleConstants.h (inclus dans le framework HIServices), Mac OS X définit un jeu de rôles standards qui décrivent la vaste majorité des types d’objets de l’interface utilisateur. Malgré qu’il soit tentant de définir de nouveaux rôles pour des objets personnalisés dans vos programmes, cela n’est pas recommandé. Un programme d’aide pourrait ne pas savoir comment gérer un objet accessibilité avec un rôle arbitraire, et les rôles supplémentaires ajoutent une complexité inutile à votre code. En lieu et place, vous devriez analyser le comportement de vos objets et choisir un rôle standard qui les représente au mieux.

L’Attribut de description du rôle contient une chaine de caractères localisée humainement compréhensible qui nomme le rôle de l’objet accessibilité. Une application d’aide présente cette chaine de caractères à l’utilisateur (un programme de lecture d’écrans, par exemple, annoncera ce texte à haute voix). Mac OS X contient une chaine de caractères de description de rôle pour chaque rôle de AXRoleConstants.h, de cette façon vous n’avez pas besoin de fournir les chaines telles que “bouton” ou “fenêtre”. Dans le cas fort improbable où votre programme a besoin de définir un nouveau rôle, vous portez la responsabilité de fournir la valeur de l’attribut de description du rôle.

L’Attribut de Description

L’Attribut de Description est presque aussi important que l’attribut de rôle. La valeur de l’attribut de description est une chaine de caractères localisée, humainement lisible, qui décrit ce que l’objet fait. Du fait qu’il décrit la fonction spécifique à l’application d’un objet de l’interface utilisateur, le protocole d’accessibilité ne peut pas deviner la description de l’objet. De ce fait, il est crucial de fournir une description pour tous les objets accessibilité de votre application qui ne soit pas déja décrit dans un attribut titre (décrit au chapitre Les Attributs Titres).

Pour comprendre l’importance aussi grande de l’attribut de description, supposons que la fenêtre de votre programme contient un bouton qui justifie à gauche le texte, et qui s’affiche sous la forme d’une flèche vers la gauche. Un programme d’aide va identifier correctement ce contrôle comme un bouton car il est représenté par un objet accessibilité avec l’attribut “bouton”. Cependant, sauf si vous fournissez une description appropriée, le programme d’aide n’a aucun moyen de savoir que ce bouton justifie le texte à gauche, et donc n’a aucun moyen de communiquer cette information à l’utilisateur.

Les Attributs Titres

L’Attribut Titre est nécessaire pour les objets de l’interface utilisateur qui incluent un titre dans leur affichage. Par exemple, le titre d’un bouton est le texte qui apparait sur le bouton, tel que le texte “OK” sur un bouton OK.

Un utilisateur ne peut pas changer le titre d’un tel objet directement, mais le titre peut changer du fait du programme si l’état de l’objet change. Par exemple, le titre d’un bouton Connection peut changer en Déconnection après qu’une connexion se soit réalisée, et non parce que l’utilisateur aurait voulu changer le titre du bouton. Un objet accessibilité qui représente un tel objet doit inclure l’attribut titre et la valeur de l’attribut doit être la chaine de caractères représentant le titre.

Beaucoup de programmes affichent du texte statique qui sert de titre pour un élément de l’interface utilisateur, mais n’est pas contenu dans l’objet lui-même. Un exemple est le mot “Rechercher” affiché sous un champ de recherche ou “Adresse:” affiché à côté d’un jeu de champs éditables. Pour un utilisateur voyant, la proximité de la chaine de caractères avec l’objet (les objets) qu’il décrit est généralement suffisant pour en déduire une relation directe entre les deux choses. Pour un logiciel d’aide, malheureusement, ces textes n’ont aucune relation avec les objets qu’ils décrivent (dans la mesure où le logiciel d’aide puisse les voir en plus).

Mac OS X version 10.4 a ajouté deux attributs spécifiques qui permettent aux programmes d’aide d’obtenir des informations sur de tels titres. Les attributs TitleUIElement et ServesAsTitleForUIElements vous permettent de définir la relation entre un texte statique et l’objet (ou les objets) qu’il décrit.

L’attribut TitleUIElement appartient à l’objet accessibilité représentant l’objet décrit. La valeur de cet attribut est l’objet accessibilité que vous créez pour représenter le texte statique. L’attribut ServesAsTitleForUIElements appartient à l’objet accessibilité texte statique que vous avez créé et sa valeur est un tableau contenant un nombre arbitraire d’objets accessibilité. Cela vous permet de lier le titre de texte statique avec un nombre quelconque d’objets de l’interface utilisateur. Malgré que ces attributs ne soient pas obligatoires, vous devez les fournir si votre interface utilisateur inclut de tels éléments de texte statique.

Les Attributs de Relation

Pour faire partie de la hiérarchie d’accessibilité, un objet accessibilité doit inclure des liens vers son parent immédiat et ses descendants (s’il en a). Cela aide un programme d’aide à traverser la hiérarchie. De plus, un objet d’accessibilité peut exprimer d’autres relations, tel que les différentes vues qui les affectent entre eux, mais ne sont pas liés au contenant.

Tous les objets d’accessibilité, à l’exception des objets au niveau application ou au niveau système, inclut un attribut de parenté. La valeur de cet attribut est généralement l’objet d’accessibilité représentant le contenant le plus proche de l’objet de l’interface utilisateur.

Si un objet de l’interface utilisateur contient d’autres objets de l’interface utilisateur, l’UIElement le représentant doit inclure l’attribut children (enfant en français). La valeur de cet attribut est un tableau contenant les UIElements des descendants accessibles.

Certaines relations sont conceptuelles plutôt que basées sur des contenants. Par exemple, il n’est pas inhabituel dans un programme d’afficher dans deux vues séparées des contenus identiques ou similaires. Mail de Mac OS X en est un exemple. La fenêtre supérieure de Mail peut afficher le sujet, l’expéditeur et la date de réception de chaque message de la boite aux lettres choisies. La fenêtre du bas, Mail peut afficher le contenu d’un message choisi dans la fenêtre du haut. Pour une personne bien voyante, la relation entre le message sélectionné en haut et le contenu du message en dessous est visible. Pour une application d’aide, d’un autre côté, cette relation directe n’existe pas. Si un programme d’aide ne peut pas exprimer cette relation à un aveugle, il lui sera impossible, par exemple, de naviguer entre les éléments de la fa&acedil;on qu’un utilisateur normal. A la place, un tel utilisateur devra passer entre tous les contrôles du programme et les différentes vues pour se déplacer entre le descriptif des messages et leurs contenus.

Mac OS X version 10.4 a ajouté l’attribut LinkedUIElements pour permettre de définir de telles relations. Comme vous pouvez le supposer, l’UIElement de chaque objet en relation doit contenir cet attribut. La valeur de cet attribut est un tableau d’UIElements afin de pouvoir spécifier des relations un-à-un ou un-à-plusieurs.

Les Attributs de Valeur

L’attribut optionnel de valeur décrit l’état de l’objet accessibilité. Cette valeur peut être le titre d’une fenêtre, l’état d’une boite à coches, ou le contenu d’un champ texte éditable.

L’attribut de valeur est souvent modifiable. Par exemple, un objet accessibilité qui représente un élément modifiable par l’utilisateur, tel qu’un champ texte éditable, a un attribut de valeur modifiable. Cela permet à un programme d’aide de modifier l’attribut de valeur pour y placer la saisie faite par l’utilisateur. De façon optionnel, les objets d’accessibilité peuvent aussi inclure des attributs qui contiennent une gamme de valeurs ou une échelle que l’objet peut accepter, tel qu’une valeur de minimum et une de maximum pour un bargraph.

Les Actions

Techniquement, une action est un attribut d’un objet accessibilité. Cependant, le protocole d’accessibilité gère les actions de façon différente des attributs, d’où la raison de ce chapitre séparé.

Un objet accessibilité peut supporter une ou plusieurs actions. Une action décrit comment l’utilisateur interagit avec l’objet de l’interface du logiciel. Il ne décrit pas la fonction de l’objet dans le cadre du programme où il est utilisé. Cela est dû au fait qu’un programme d’aide s’occupe de gérer l’interface utilisateur, et donc de ce fait les conséquences des actions ne le concernent pas. Si votre programme affiche un bouton pour imprimer. l’objet accessibilité de ce bouton supporte une action d’appui, et non une action d’imprimer.

Du fait que les actions sont génériques et se réfèrent aux possibilités des objets de l’interface utilisateur, il y en a très peu. Cela signifie que le nombre d’actions qu’un programme d’aide doit comprendre est faible et bien défini.

Dans le fichier AXActionConstants.h (situé dans le framework HIServices), Mac OS X définit sept actions supportées par un objet accessibilité:

• Appui (un bouton)
• Incrémentation (la valeur d’un bargraph ou d’un pointeur glissant)
• Décrémentation (la valeur d’un bargraph ou d’un pointeur glissant)
• Confirmer (la sélection d’un objet)
• Annuler (une sélection ou une action)
• Agrandir (une fenêtre)
• Afficher un menu (affiche un menu contextuel associé à un objet)

Lorsque l’utilisateur réalise une action, un programme d’aide envoie un message à l’objet accessibilité, pour lui demander de réaliser l’action. Votre programme doit traiter de la même façon cette action qu’il le fait quand l’utilisateur la réalise directement via l’interface utilisateur.

Chaque attribut d’action possède un descriptif de sa propriété. Une application d’aide peut annoncer à voix haute ce descriptif pour indiquer à l’utilisateur quelle action est disponible pour un objet particulier. La valeur du descriptif de la propriété est similaire à la valeur de la description du rôle dans le sens qu’il s’agit d’une courte phrase, ou d’un mot localisé sous forme humainement lisible. Contrairement à la description du rôle, cependant, le descriptif d’action n’est pas automatiquement fourni par le protocole d’accessibilité. Si votre programme crée ses propres objets qui gèrent ses actions, vous devez fournir les descriptifs d’actions appropriés.

La Communication avec les Objets Accessibilité

Au coeur de l’accessibilité se trouve la communication entre le programme d’aide et l’objet accessibilité qui représente l’interface utilisateur de votre programme. Cette communication peut être divisée en deux catégories:

• Les messages envoyés par le programme d’aide pour obtenir des informations concernant un objet accessibilité et obtenir le type d’actions qu’il supporte. Un objet accessibilité répond à ce type de demandes en envoyant ses valeurs d’attributs, les actions supportées, ou les valeurs d’attributs changeantes.
• Les messages émis par les objets d’accessibilité que les programmes d’aide peuvent surveiller. Ces messages indiquent au programme d’aide intéressé que des changements sont survenus dans l’état d’un objet accessibilité.

Si vous utilisez uniquement des objets Cocoa ou Carbon standards, non modifiés, la majorité de cette communication est transparente pour vous. Dans certains cas, vous pourriez avoir besoin de créer des réponses spécifiques à un message, mais cela est rare. Il est encore moins courant d’avoir à gérer les messages émis si vous utilisez uniquement des objets standards.

Les Messages envoyés

Un programme d’aide communique avec votre application en envoyant des messages aux objets accessibilité. En Carbon, ces messages sont transmis comme des évènements Carbon. En Cocoa, ces messages finissent en appels aux méthodes du protocole NSAccessibility. Pour plus de détails sur l’implémentation des messages spécifiques à chaque framework, se reporter aux documents Accessibility
Programming Guidelines for Cocoa ou Accessibility Programming Guidelines for Carbon.

Dans le fichier HIObject.h, Mac OS X définit un certain nombre de messages. Les types de message qu’une application d’aide peut envoyer à un objet accessibilité sont listés ci-dessous:

• Obtenir une liste des attributs des objets accessibilité
• Obtenir la valeur d’un attribut spécifique
• Vérifier si la valeur d’un attribut spécifique peut être modifiée
• Modifier la valeur d’un attribut spécifique
• Obtenir la liste des actions d’un objet accessibilité
• Obtenir la description d’une action
• Demander à l’objet accessibilité de réaliser une action spécifique
• Déterminer quel objet accessibilité se trouve sous le pointeur de la souris (test du pointeur)
• Activer ou désactiver les messages

Comme le jeu d’actions, le jeu de messages auxquels un objet accessibilité peut répondre est restreint. Ces messages donnent malgré tout à l’application d’aide de grandes possibilités de contrôle. Par exemple, en lisant et en modifiant les attributs, l’application d’aide peut réaliser les choses suivantes:

• Lire la position d’un bargraph ou d’un pointeur glissant
• Traverser la hiérarchie des objets pour trouver tous les objets accessibilité (tels que les contrôles, les contrôles étendus, et les cellules des tables) d’une fenêtre.
• Vérifier si un contrôle est actif ou pas

Les Messsages émis

En plus de répondre aux messages des applications d’aide, les objets accessibilité diffusent également les changements importants qui se produisent au sein des objets de l’interface utilisateur qu’ils représentent. Par exemple, si la saisie du clavier change de champ, ou une nouvelle fenêtre devient active, ou le titre d’un contrôle change, l’objet accessibilité pour ces objets diffuse des messages pour le signaler.

Un programme d’aide choisit de se déclarer pour les messages d’avertissement auxquels il est intéressé.

Un objet accessibilité peut envoyer des messages d’avertissement pour indiquer des changements des types suivants:

• La valeur de l’objet a changé
• L’objet a été supprimé
• La destination du clavier a changé

Sauf si vous créez des objets accessibilité pour représenter des objets personnalisés de l’interface utilisateur, il est peu probable que vous ayez à écrire du code pour envoyer les messages d’avertissement. Aussi bien Carbon que Cocoa diffusent automatiquement les messages adéquats pour les objets standards.

Cible du Clavier et de la Souris

Pour un utilisateur sans problèmes de vue, l’emplacement du curseur est facile à distinguer. De la même façon, un utilisateur peut voir aisément quel objet de l’interface utilisateur est actif pour le clavier. Une application d’aide, d’un autre côté, doit interroger le programme pour déterminer quel objet est la cible du clavier ou quel élément se trouve sous le pointeur de la souris. Un objet accessibilité apporte les réponses à ces questions en retournant les valeurs des différents attributs.

Malgré le fait que vous puissiez implémenter différemment le ciblage selon que vous utilisiez Carbon ou Cocoa, la procédure de base est que l’application d’aide demande au programme de lui indiquer l’objet accessibilité qui se trouve sous le curseur. La demande est transmise récursivement à la hiérarchie d’accessibilité jusqu’à ce qu’elle atteigne l’objet d’accessibilité le plus profond qui ne soit pas ignoré et qui contienne le pointeur de la souris.

Les objets accessibilité doivent aussi supporter les requêtes concernant la cible du clavier. Un objet accessibilité stocke l’information du focus dans un attribut dédié. La requête initiale de l’application d’aide s’adresse à l’attribut focus de l’objet d’accessibilité au niveau de l’application elle-même. Cette requête est, elle aussi, transmise à travers la hiérarchie d’accessibilité de l’application jusqu’à atteindre l’objet d’accessibilité le plus profond qui ne soit pas ignoré dont l’attribut focus est vrai ou actif. Comme pour le focus de la souris, la gestion en est différente selon que l’on soit en Carbon ou en Cocoa.

Un Exemple d’Accessibilité

Cet exemple donne une description détaillée de la façon dont un lecteur d’écran fictif avec synthèse vocale et reconnaissance vocale peut communiquer avec votre programme:

1. L’utilisateur dit “Ouvrir la fenêtre des Préférences.”
2. Le lecteur d’écran envoie un message à l’objet accessibilité du programme, en lui demandant l’attribut de sa barre de menus, qui est une référence à l’objet accessibilité de la barre de menus. Il interroge ensuite la barre de menus pour obtenir la liste de ses enfants, et interroge chaque enfant pour avoir la liste de ses attributs jusqu’à trouver celui dont le titre est le nom du programme (c’est à dire, le menu du programme). Un deuxième parcours lui permet de trouver l’élément du menu nommé Préférences dans le menu du programme. Pour finir, le lecteur d’écran dit à l’élément du menu Préférences de s’ouvrir par un clic souris.
3. Le programme ouvre la fenêtre des Préférences et la fenêtre envoie alors un message de diffusion indiquant la présence d’une nouvelle fenêtre visible et active.
4. Le lecteur d’écran, partant du principe qu’il est déclaré pour être informé quand une nouvelle fenêtre s’ouvre, interroge la fenêtre pour obtenir une liste de ses attributs. Partant du principe que l’objet d’accessilité de la fenêtre contient un attribut enfant, il interroge alors l’objet accessibilité pour connaitre la valeur de l’attribut enfant.
5. Pour chaque enfant de l’objet accessibilité de la fenêtre, le lecteur d’écran envoie une requête demandant la liste de ses attributs. Il interroge alors l’enfant pour les valeurs de son rôle, la description de son rôle, et (s’il existe) les attributs de son enfant.
6. Parmi les réponses, le lecteur d’écran apprend que la fenêtre contient quelques enfants (par exemple, trois boites à cocher).
7. Le lecteur d’écran interroge chaque boite, en leur demandant les valeurs des attributs suivants:
   • le rôle (checkBox dans le cas présent)
   • la description du rôle (“checkbox”)
   • la valeur (coché ou non coché)
   • la présence d’un enfant (aucun ici)
8. Le lecteur d’écran, connaissant maintenant quels objets (des contrôles dans le cas actuel) sont accessibles dans la fenêtre, va donner cette information à l’utilisateur en utilisant la synthèse vocale.
9. L’utilisateur peut alors demander plus d’informations sur une des boites à cocher.
10. Le lecteur d’écran interroge alors la boite à cocher demandée, en lui demandant la valeur de son attribut d’aide (en supposant qu’il existe). Il annonce cette chaine de caractères à l’utilisateur par la synthèse vocale.
11. L’utilisateur peut alors demander au lecteur d’écran de cocher la case.
12. Le lecteur d’écran envoie un message demandant que l’attribut de valeur de la boite à coches soit positionnée à 1.
13. L’objet accessibilité de la boite à côches diffuse alors que la valeur de son attribut valeur a changé.

Tester l’Accessibilité

Que vous soyez en train de concevoir un nouveau programme ou en train de rendre accessible une application existante, vous devez prévoir de tester l’accessibilité de votre produit. Tester l’accessibilité est un petit peu différent du test d’une interface utilisateur classique et Apple fournit un ensemble d’outils pour rendre cela plus facile.

Les développeurs de programmes devraient lire ce chapitre pour découvrir comment tester l’accessibilité de leurs logiciels.

Utilisation d’Accessibility Inspector

Apple fournit l’outil de test Accessibility Inspector qui se trouve dans /Developer/Applications/Utilities/Accessibility Tools. Le logiciel Accessibility Inspector présente une interface qui affiche les attributs (et valeurs), les actions, et la position dans la hiérarchie d’accessibilité de l’objet se trouvant sous le pointeur de la souris. Pour utiliser Accessibility Inspector, assurez-vous d’activer l’accès pour les périphériques d’aide dans le panneau des Préférences d’Accès universel.

Si vous commencez à rendre votre application accessible, essayez d’utiliser Accessibility Inspector pour visualiser l’information d’accessibilité que les autres programmes fournissent. Malgré qu’Accessibility Inspector ne soit pas un logiciel d’aide, il utilise les mêmes APIs des programmes d’aide pour obtenir les informations des objets accessibilité qu’il rencontre.

Vous pouvez cibler Accessibility Inspector sur un objet spécifique pour examiner ses attributs, réaliser ses actions, et accéder à ses parents et enfants (s’ils existent), en appuyant sur Commande-F7. Lorsque vous faites cela, l’affichage de Accessibility Inspector se gèle, vous permettant de déplacer la souris sans changer l’objet sur lequel l’outil est ciblé. Une seconde fenêtre apparait alors qui affiche l’information concernant l’objet sélectionné. Dans cette seconde fenêtre, vous pouvez aller au parent de l’objet, ses enfants ou tout autre objet en relation, tel que la fenêtre le contenant ou l’objet accessibilité le plus haut dans la hiérarchie. Vous pouvez aussi réaliser les actions supportées par cet objet, vous permettant ainsi de voir comment cela affecte les valeurs des différents attributs et le programme lui-même.

Au fur et à mesure que vous rendez votre application accessible, utilisez Accessibility Inspector pour vous assurer que vos objets contiennent bien les bonnes informations. Si vous découvrez qu’un objet spécifique n’est pas accessible, vous pouvez cibler Accessibility Inspector sur cet objet, examiner ses valeurs d’attributs et réaliser les actions de cet objet pour découvrir le problème.

Utilisation d’Accessibility Verifier

Apple fournit l’outil Accessibility Verifier qui se trouve dans /Developer/Applications/Utilities/Accessibility Tools. Accessibility Verifier affiche la hiérarchie d’accessibilité comprenant tous les objets réellement instanciés dans le programme choisi. Pour pouvoir utiliser Accessibility Verifier, assurez-vous d’avoir activé l’accès pour les périphériques d’aide dans les Préférences d’Accès Universel.

Vous pouvez utiliser Accessibility pour réaliser un ou plusieurs des tests suivants (sélectionnez les tests que vous voulez effectuer en cliquant sur le bouton Choose Tests…):

• Parent/Enfant. Ce test vérifie l’intégrité de la hiérarchie d’accessibilité en s’assurant que chaque paire parent/enfant une boucle fermée. Par exemple, si un enfant cité dans l’attribut enfant d’un objet parent ne se réfère pas à cet objet comme parent, cette paire parent/enfant n’est pas correcte. Les paires invalides de ce type peuvent empêcher un programme d’aide de traverser correctement la hiérarchie d’accessibilité d’un programme.
• Fenêtre. Ce test vérifie que tous les objets contenus dans une fenêtre incluent des attributs qui se réfèrent à la fenêtre le contenant. Un objet contenu dans une fenêtre n’est pas forcément un enfant de cette fenêtre, mais il doit faire référence à la fenêtre dans laquelle il se trouve pour plus de facilités pour les programmes d’aide.
• AXDescription manquant. Ce test vérifie la présence de l’attribut description dans les objets accessibilité qui en nécessitent un. Rappelez-vous du chapitre L’attribut de Description où on a dit que tous les objets accessibilité doivent fournir une information de description spécifique au contexte pour les programmes d’aide. Si un objet n’affiche pas de titre descriptif, il doit inclure un attribut de description et une valeur appropriés.
• Vérification du rôle. Ce test vérifie que les attributs d’un objet accessibilité sont corrects pour son rôle. Se reporter à la documentation “Roles
  and Associated Attributes” (en anglais) pour plus de détails sur les attributs associés à chaque rôle.

Lorsque vous cliquez sur Verify, Accessibility Verifier exécute les tests et affiche les résultats pour chacun. Les problèmes sont signalés comme des erreurs (errors) ou des avertissements (warnings), selon leur gravité. (vous pouvez filtrer les résultats en choisissant un niveau de sévérité dans le menu flottant Report Level).

Il est important de savoir que le fait de résoudre toutes les erreurs et avertissements détectés par Accessibility Verifier ne garantit pas une application parfaitement accessible. Vous devriez toujours tester votre programme avec différents logiciels d’aide pour être sûr qu’aucun problème ne subsiste.

Raccourcis clavier pour l’Accessibilité

Cette note répertorie les raccourcis clavier réservés pour l’utilisation des différentes fonctionnalités de l’Accès Universel de Mac OS X.

Pour activer ou désactiver VoiceOver, utiliser Commande-F5.

Le tableau A-1 répertorie les raccourcis clavier utilisés qui sont réservés pour les fonctions de Zoom dans Mac OS X. Un utilisateur active ou pas les fonctions de zoom dans l’onglet Vue des Préférences de l’Accès Universel.

Tableau A-1 : Raccourcis clavier utilisés pour les fonctions de zoom écran

Raccourci Clavier	Action
Option-Commande-8	Active/Désactive le zoom écran
Option-Commande-=	Zoom avant
Option-Commande– (tiret)	Zoom arrière
Commande-Option-Controle-8	Inverse les couleurs affichées à l’écran
Commande-Option-Controle-,	Réduit le contraste
Commande-Option-Controle-.	Augmente le contraste

Mac OS X version 10.2 et supérieur apporte la possibilité de l’accès au clavier complet, qui permet aux utilisateurs de naviguer parmi les fenêtres, les boites de dialogue, les menus, les barres d’outils, et le Dock en utilisant uniquement le clavier, sans souris ni dispositif de pointage.

Les utilisateurs peuvent activer l’accès au clavier complet dans le panneau des Raccourcis Clavier des Préférences Clavier et Souris. Controle-F1 est un raccourci clavier réservé pour activer/désactiver cette fonctionnalité du clavier. Controle-F7 permet de basculer entre le mode accès clavier pour tous les contrôles dans les fenêtres et les boites de dialogue et le mode par défaut, dans lequel seuls les champs textes et les listes déroulantes sont accessibles via le clavier. N’utilisez pas ces raccourcis clavier pour d’autres fonctionnalités.

Avec l’accès au clavier activé pour les fenêtres et boites de dialogue, les flèches de direction permettent de se déplacer entre les valeurs d’un contrôle. Par exemple, si l’utilisateur sélectionne un bargraph avec la touche Tabulation, les flèches déplacent le pointeur du bargraph. Pour les choix dans des listes verticales, tels que les éléments de menu, les flèches haut et bas déplacent la sélection. Pour les choix horizontaux, tels qu’une ligne de cellules, les flèches droite et gauche permettent de se déplacer. Dans certains cas, il est logique de gérer les deux directions. Par exemple. un bargraph vertical peut utiliser aussi bien la flèche vers le haut que vers la droite pour augmenter une valeur.

Dans certains cas, tels que les boutons radio, déplacer la cible sur un élément le sélectionne également. Dans d’autres cas, tels que les boutons à appui, l’utilisateur active son choix en utilisant la barre espace. En mode Accès complet au clavier, la touche Espace revient à la même fonction que le clic de la souris.

La Touche Echap (Esc) est utilisé pour annuler une boite de dialogue, et pour annuler une sélection dans une liste déroulante ou une fenêtre flottante. Dans un menu du Dock, Echap ferme le menu et déplace la cible sur l’application au premier plan.

L’utilisateur peut également rapidement déplacer la cible dans la barre de menus, le Dock, les barres d’outils, et les fenêtres en utilisant les raccourcis clavier répertoriés dans le Tableau A-2.

Ce comportement est disponible pour tous les programmes qui utilisent les contrôles standards. Si vous développez vos propres contrôles, vous devrez reproduire ces comportements pour vos utilisateurs.

Le Tableau A-2 répertorie les raccourcis clavier utilisés lorsque l’on est en mode Accès complet au clavier.

Tableau A-2 : Raccourcis clavier pour déplacer la cible en mode Accès complet au clavier

Raccourci clavier	Action
Controle-F1	Active/Désactive l’Accès complet au clavier
Controle-F2	Déplace la cible sur la barre de menu
Controle-F3	Déplace la cible sur le Dock
Controle-F4	Déplace la cible sur la fenêtre active (ou la suivante)
Shift-Controle-F4	Déplace la cible sur la fenêtre précédente
Controle-F5	Déplace la cible sur la barre d’outils
Controle-F6	Déplace la cible sur la fenêtre suivante (ou la précédente)
Shift-Controle-F6	Déplace la cible sur la fenêtre précédente
Controle-F7	Jongle entre les deux modes d’accès au clavier (tous les contrôles ou uniquement les champs texte et les listes déroulantes)
Controle-Tab	Déplace la cible sur le groupe suivant de contrôles dans une boite de dialogue ou le tableau suivant (lorsque Tab permet de passer à la cellule suivante)
Shift-Controle-Tab	Déplace la cible sur le groupe précédent de contrôles
Command-Tab	Déplace la cible sur la première (ou la suivante) icône du Dock d’un programme ouvert
Commande-Shift-Tab	Déplace la cible sur l’icône du Dock de l’application ouverte précédente
Flèches de direction	Déplace la cible sur la valeur suivante ou précédente dans un champ texte ou dans certains contrôles, tels que des menus; ainsi que les menus du Dock
Controle-Flèches de direction	Déplace la cible sur une autre valeur ou cellule dans un contrôle tel qu’un tableau
Commande-` (accent grave)	Activate la fenêtre ouverte suivante dans l’application au premier plan
Commande-Shift-` (accent grave)	Activate la fenêtre ouverte précédente dans l’application au premier plan
Commande-Option-` (accent grave)	Déplace la cible sur le tiroir de la fenêtre
Touche Espace	Sélectionne le contrôle surligné (équivalent au clic de la souris)
Touche Entrée (Enter)	Sélectionne le bouton par défaut
Echap	Annule une boite de dialogue ou une sélection dans un menu flottant ou une liste; dans un menu du Dock, Echap ferme le menu et déplace la cible sur la fenêtre au premier plan

Remarque:Les utilisateurs peuvent changer les raccourcis par défaut cités ci-dessus dans l’onglet Raccourcis clavier des Préférences Clavier et Souris ou dans l’onglet Clavier des Préférences d’Accès Universel. Quand le mode Accès complet au Clavier est actif, les raccourcis clavier définis par l’utilisateur s’imposent sur les raccourcis clavier des programmes

Textes originaux en anglais sur developer.apple.com : Accessibility Overview

vincen Développement Accessibilité, cocoa, Mac OS X