UI Automation et Microsoft Active Accessibility

Microsoft Active Accessibility était la solution précédemment utilisée pour rendre les applications accessibles. Microsoft UI Automation est le nouveau modèle d’accessibilité pour Microsoft Windows et a été conçu pour répondre aux besoins des produits de technologie d’assistance et des outils de test automatisés. UI Automation offre de nombreuses améliorations par rapport à Active Accessibility.

Cette rubrique inclut les principales fonctionnalités d’UI Automation et explique comment ces fonctionnalités diffèrent d’Active Accessibility.

Langages de programmation

Active Accessibility est basé sur le modèle COM (Component Object Model) avec la prise en charge des interfaces doubles. Ainsi, il est programmable en C/C++, en Microsoft Visual Basic 6.0 et dans les langages de script. UI Automation (y compris la bibliothèque fournisseur côté client pour les contrôles standard) est écrit en code managé et les applications clientes UI Automation sont programmées plus facilement à l’aide de C# ou de Visual Basic .NET. Les fournisseurs UI Automation, qui sont des implémentations d’interface, peuvent être écrits en code managé ou en C/C++.

Prise en charge dans Windows Presentation Foundation

Windows Presentation Foundation (WPF) est le nouveau modèle de création d’interfaces utilisateur. Les éléments WPF n’assurent pas la prise en charge native d’Active Accessibility. En revanche, ils prennent en charge UI Automation, qui inclut la prise en charge du pontage pour les clients Active Accessibility. Seuls les clients spécifiquement écrits pour UI Automation peuvent tirer pleinement parti des fonctionnalités d’accessibilité de WPF, comme la prise en charge étendue pour le texte.

Serveurs et clients

Dans Active Accessibility, les serveurs et les clients communiquent directement, en grande partie via l’implémentation de IAccessible par le serveur.

Dans UI Automation, un service principal se trouve entre le serveur (appelé fournisseur) et le client. Ce service appelle les interfaces implémentées par les fournisseurs et fournit des services supplémentaires tels que la génération d’identificateurs d’exécution uniques pour les éléments. Les applications clientes utilisent des fonctions de bibliothèque pour appeler le service UI Automation.

Les fournisseurs UI Automation peuvent fournir des informations aux clients Active Accessibility et les serveurs Active Accessibility peuvent fournir des informations aux applications clientes UI Automation. Toutefois, comme Active Accessibility n’expose pas autant d’informations que UI Automation, les deux modèles ne sont pas entièrement compatibles.

Éléments de l'interface utilisateur

Active Accessibility présente les éléments IU comme une interface IAccessible ou comme un identificateur enfant. Il est difficile de comparer deux pointeurs IAccessible pour déterminer s’ils font référence au même élément.

Dans UI Automation, chaque élément est représenté comme un objet AutomationElement. La comparaison s’effectue à l’aide de l’opérateur d’égalité ou de la méthode Equals , qui comparent tous les deux les identificateurs d’exécution uniques des éléments.

Arborescences et navigation

À l’écran, les éléments d’interface utilisateur (IU) peuvent être affichés sous forme d’arborescence. Le bureau correspond à la racine, les fenêtres d’application aux enfants immédiats et les éléments des applications à des descendants plus lointains.

Dans Active Accessibility, de nombreux éléments Automation sans importance pour l’utilisateur final sont exposés dans l’arborescence. Les applications clientes doivent examiner tous les éléments pour déterminer les éléments significatifs.

Les applications clientes UI Automation voient l’interface utilisateur via une vue filtrée. La vue ne contient que les éléments intéressants : ceux qui apportent des informations à l’utilisateur ou qui permettent l’interaction. Des vues prédéfinies contenant uniquement les éléments de contrôle et uniquement les éléments de contenu sont disponibles. En outre, les applications peuvent définir des vues personnalisées. UI Automation simplifie la tâche consistant à décrire l’IU à l’utilisateur et à aider l’utilisateur à interagir avec l’application.

Dans Active Accessibility, la navigation entre les éléments peut être spatiale (par exemple, un déplacement vers l’élément qui se trouve à gauche de l’écran), logique (par exemple, un déplacement vers l’élément de menu suivant ou vers l’élément suivant dans l’ordre de tabulation d’une boîte de dialogue) ou hiérarchique (par exemple, un déplacement du premier enfant dans un conteneur ou d’un enfant vers son parent). La navigation hiérarchique est compliquée par le fait que les éléments enfants ne sont pas toujours des objets qui implémentent IAccessible.

Dans UI Automation, tous les éléments d’interface utilisateur sont des objets AutomationElement qui prennent en charge les mêmes fonctionnalités de base. (Du point de vue du fournisseur, il s’agit d’objets qui implémentent une interface héritée de IRawElementProviderSimple.) La navigation est principalement hiérarchique : des parents aux enfants, et d’un frère à l’autre. (La navigation entre frères a un élément logique, car elle peut suivre l’ordre de tabulation.) Vous pouvez naviguer à partir de n’importe quel point de départ, à l’aide de n’importe quelle vue filtrée de l’arborescence, à l’aide de la classe TreeWalker. Vous pouvez également naviguer vers des enfants ou des descendants particuliers à l’aide de FindFirst et FindAll. Par exemple, il est très simple de récupérer tous les éléments d’une boîte de dialogue qui prennent en charge un modèle de contrôle spécifié.

La navigation dans UI Automation est plus cohérente que dans Active Accessibility. Certains éléments tels que les listes déroulantes et les fenêtres indépendantes apparaissent deux fois dans l’arborescence Active Accessibility et le fait de naviguer depuis ces éléments peut entraîner des résultats inattendus. Il est en fait impossible d’implémenter correctement Active Accessibility pour un contrôle Rebar. UI Automation permet la définition de l’état de parent et le repositionnement, afin qu’un élément puisse être placé n’importe où dans l’arborescence en dépit de la hiérarchie imposée par la propriété des fenêtres.

Rôles et types de contrôle

Active Accessibility utilise la propriété accRole (IAccessible::get_actRole) pour récupérer une description du rôle de l’élément dans l’interface utilisateur, comme ROLE_SYSTEM_SLIDER ou ROLE_SYSTEM_MENUITEM. Le rôle d’un élément est l’indice principal pour connaître ses fonctionnalités disponibles. L’interaction avec un contrôle est réalisée à l’aide de méthodes fixes telles que IAccessible::accSelect et IAccessible::accDoDefaultAction. L’interaction entre l’application cliente et l’interface utilisateur se limite à ce qui peut s’effectuer via IAccessible.

En revanche, UI Automation découple en grande partie le type de contrôle de l’élément (décrit par la propriété ControlType) de ses fonctionnalités attendues. Les fonctionnalités sont déterminées par les modèles de contrôle pris en charge par le fournisseur via son implémentation d’interfaces spécialisées. Les modèles de contrôle peuvent être combinés pour décrire l’ensemble des fonctionnalités prises en charge par un élément d’interface utilisateur particulier. Certains fournisseurs sont tenus de prendre en charge un modèle de contrôle particulier. Par exemple, le fournisseur d’une case à cocher doit prendre en charge le modèle de contrôle Toggle. D’autres fournisseurs doivent prendre en charge un ou plusieurs éléments d’un ensemble de modèles de contrôle. Par exemple, un bouton doit prendre en charge Toggle ou Invoke. D’autres encore ne prennent en charge aucun modèle de contrôle du tout. Par exemple, un volet qui ne peut pas être déplacé, redimensionné ni ancré n’a pas de modèle de contrôle.

UI Automation prend en charge des contrôles personnalisés, identifiés par la propriété Custom et pouvant être décrits par la propriété LocalizedControlTypeProperty.

Le tableau suivant montre la correspondance entre les rôles Active Accessibility et les types de contrôle UI Automation.

Pour plus d’informations sur les différents types de contrôle, consultez UI Automation Control Types.

États et propriétés

Dans Active Accessibility, les éléments prennent en charge un ensemble commun de propriétés et certaines propriétés (telles que accState) doivent décrire des aspects très différents, selon le rôle de l’élément. Les serveurs doivent implémenter toutes les méthodes de IAccessible qui retournent une propriété, y compris celles qui ne sont pas pertinentes pour l’élément.

UI Automation définit de nombreuses autres propriétés, dont certaines correspondent aux états dans Active Accessibility. Certaines sont communes à tous les éléments, tandis que d’autres sont spécifiques aux types de contrôle et aux motifs de contrôle. Les propriétés se distinguent par des identificateurs uniques et la plupart des propriétés peuvent être récupérées à l’aide d’une méthode unique, GetCurrentPropertyValue ou GetCachedPropertyValue. De nombreuses propriétés sont également facilement récupérables à partir des accesseurs de propriété Current et Cached .

Un fournisseur UI Automation n’est pas tenu d’implémenter des propriétés non pertinentes et peut simplement retourner une valeur null pour toutes les propriétés qu’il ne prend pas en charge. Le service principal UI Automation peut également obtenir des propriétés auprès du fournisseur de fenêtres par défaut. Ces propriétés sont fusionnées avec les propriétés implémentées explicitement par le fournisseur.

Outre la prise en charge de nombreuses autres propriétés, UI Automation fournit de meilleures performances en autorisant la récupération de plusieurs propriétés via un seul appel interprocessus.

Le tableau suivant montre la correspondance entre les propriétés dans les deux modèles.

Le tableau suivant indique les propriétés UI Automation qui correspondent aux constantes d’état Active Accessibility.

Les états suivants n’ont pas été implémentés par la plupart des serveurs de contrôle Active Accessibility ou n’ont aucun équivalent dans UI Automation.

Pour obtenir la liste complète des identificateurs de propriété UI Automation, consultez Vue d’ensemble des propriétés UI Automation.

Événements

Dans UI Automation, contrairement à Active Accessibility, le mécanisme d’événement ne repose pas sur le routage des événements Windows (étroitement lié aux handles de fenêtre) et ne requiert pas l’application cliente pour pouvoir installer des raccordements. Les abonnements aux événements peuvent être ajustés non seulement à des événements particuliers mais également à des parties spécifiques de l’arborescence. Les fournisseurs peuvent également ajuster leur déclenchement d’événements en assurant le suivi des événements qui sont écoutés.

Il est également plus facile pour les clients de récupérer les éléments qui déclenchent des événements, car ils sont passés directement au rappel d’événement. Les propriétés de l’élément sont automatiquement prérécupérées si une requête de cache était active quand le client s’est abonné à l’événement.

Le tableau suivant présente la correspondance des événements WinEvents Active Accessibility et UI Automation.

Sécurité

Certains scénarios de personnalisation IAccessible nécessitent l’encapsulation d’un IAccessible de base et l’appel via celui-ci. Cela a des implications en matière de sécurité, car un composant avec un niveau de confiance partiel ne doit pas être un intermédiaire sur un chemin de code.

Le modèle UI Automation supprime le besoin qu’ont les fournisseurs d’appeler via un autre code de fournisseur. Le service principal UI Automation effectue toutes les opérations d’agrégation nécessaires.

Voir aussi

• Notions de base d’UI Automation