UI Automation et Active Accessibility
Microsoft Active Accessibility est l’API héritée qui a été introduite dans Windows 95 et qui a été conçue pour rendre les applications Windows accessibles. Microsoft UI Automation est le nouveau modèle d’accessibilité pour Windows et vise à répondre aux besoins des produits de technologies d’assistance et des outils de test automatisés. UI Automation offre de nombreuses améliorations par rapport à Microsoft Active Accessibility. Cette rubrique explique les différences entre les deux technologies.
Cette rubrique contient les sections suivantes.
- Langages de programmation
- Serveurs et clients
- Éléments de l’interface utilisateur
- Arborescences et navigation
- Rôles et types de contrôle
- États et propriétés
- Événements
- Accéder aux propriétés et objets d’Active Accessibility à partir de UI Automation
- Rubriques connexes
Langages de programmation
Microsoft Active Accessibility est basé sur le Component Object Model (COM) avec prise en charge des interfaces doubles, et est donc programmable en C/C++ et en langages de script.
Lorsque UI Automation a été introduit, l’API client était limitée au code managé, tandis que l’API fournisseur incluait à la fois des implémentations managées et non managées. Avec Windows 7, une nouvelle API client basée sur COM a été introduite pour faciliter la programmation des applications clientes UI Automation en C/C++.
Serveurs et clients
Dans Microsoft Active Accessibility, les serveurs et les clients communiquent directement, en grande partie via l’implémentation serveur de l’interface IAccessible.
Dans UI Automation, un service central se situe entre le serveur (fournisseur) et le client. Le service central fait des appels aux interfaces implémentées par les fournisseurs et fournit des services supplémentaires, tels que la génération d’identifiants uniques d’exécution pour les éléments UI. Les applications clientes accèdent à ce service central en créant un objet CUIAutomation. Cet objet prend en charge un ensemble d’interfaces client qui sont distinctes des interfaces fournisseur. Pour plus d’informations, veuillez consulter la section Création de l’objet CUIAutomation.
Les fournisseurs UI Automation peuvent fournir des informations aux clients Microsoft Active Accessibility, et les serveurs Microsoft Active Accessibility peuvent fournir des informations aux applications clientes UI Automation. Cependant, comme Microsoft 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
Microsoft Active Accessibility présente un élément d’interface utilisateur sous forme d’interface IAccessible associée à un identifiant d’enfant. Il est difficile de comparer deux pointeurs IAccessible pour déterminer s’ils se réfèrent au même élément.
Dans UI Automation, chaque élément est représenté comme un objet qui expose l’interface IUIAutomationElement aux clients. Les éléments peuvent être comparés par leurs identifiants d’exécution, qui sont récupérés à l’aide de IUIAutomationElement::GetRuntimeId.
Arborescences et navigation
Les éléments UI sur l’écran peuvent être vus comme une structure arborescente avec le bureau comme racine, les fenêtres d’application comme enfants immédiats, et les éléments au sein des applications comme descendants supplémentaires.
Dans Microsoft Active Accessibility, de nombreux éléments UI sans pertinence pour les utilisateurs finaux sont exposés dans la structure arborescente. Les applications clientes doivent examiner tous les éléments de l’arborescence pour déterminer lesquels sont pertinents.
Les applications clientes UI Automation voient l’interface utilisateur via une vue filtrée. L’affichage contient uniquement les éléments qui fournissent des informations à l’utilisateur ou avec lesquels l’utilisateur peut interagir. Des affichages prédéfinis incluant uniquement les éléments de contrôle et uniquement les éléments de contenu sont disponibles, et les applications clientes peuvent définir des affichages personnalisés. UI Automation facilite la description de l’interface utilisateur à l’utilisateur et l’aide à interagir avec les applications.
Dans Microsoft Active Accessibility, la navigation entre les éléments est spatiale, par exemple, passer à l’élément situé à gauche sur l’écran, logique, par exemple, passer à l’élément de menu suivant ou à l’élément suivant dans l’ordre des onglets dans une boîte de dialogue, ou hiérarchique, par exemple, passer au premier élément enfant dans un conteneur ou d’un élément enfant à son élément 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 UI sont des objets COM qui exposent l’interface IUIAutomationElement et prennent en charge les mêmes fonctionnalités de base. Du point de vue du fournisseur, les objets COM implémentent une interface héritée de IRawElementProviderSimple. La navigation est principalement hiérarchique ; c’est-à-dire des parents vers les enfants, et d’un élément frère à l’autre. Cependant, la navigation entre frères possède un élément logique, car elle peut suivre l’ordre des onglets. Un client peut naviguer à partir de n’importe quel point de départ, en utilisant n’importe quel affichage filtré de l’arborescence, en utilisant IUIAutomationTreeWalker. Un client peut également naviguer vers des enfants ou descendants particuliers en utilisant IUIAutomationElement::FindFirst et IUIAutomationElement::FindAll. Par exemple, il est facile de récupérer tous les éléments dans 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 Microsoft Active Accessibility. Certains éléments, tels que les listes déroulantes et les fenêtres contextuelles, apparaissent deux fois dans l’arborescence de Microsoft Active Accessibility, et la navigation à partir de ces éléments peut donner des résultats inattendus. Il est difficile d’implémenter correctement Microsoft Active Accessibility pour un contrôle de rebar. UI Automation permet le repositionnement et le changement de parent, de sorte qu’un élément peut être placé n’importe où dans l’arborescence, malgré la hiérarchie imposée par la propriété des fenêtres.
Rôles et types de contrôle
Microsoft Active Accessibility utilise la propriété accRole (IAccessible::get_accRole) pour récupérer une description du rôle de l’élément dans l’interface utilisateur, tel que 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 s’effectue à l’aide de méthodes fixes telles que IAccessible::accSelect et IAccessible::accDoDefaultAction. L’interaction entre l’application cliente et l’interface utilisateur est limitée à ce qui peut être fait via IAccessible.
En revanche, UI Automation découple le type de contrôle de l’élément, qui est décrit par la propriété IUIAutomationElement::CurrentControlType (ou IUIAutomationElement::CachedControlType), de sa fonctionnalité attendue. 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 complet de fonctionnalités prises en charge par un élément UI particulier. Certains fournisseurs doivent prendre en charge un modèle de contrôle particulier. Par exemple, le fournisseur pour une case à cocher doit prendre en charge le modèle de contrôle Toggle. D’autres fournisseurs doivent prendre en charge un ou plusieurs modèles de contrôle. Par exemple, un bouton doit prendre en charge soit le modèle de contrôle Toggle, soit le modèle Invoke. D’autres ne prennent en charge aucun modèle de contrôle. Par exemple, un volet qui ne peut pas être déplacé, redimensionné ou ancré n’a aucun modèle de contrôle.
UI Automation prend en charge les contrôles personnalisés, qui sont identifiés par la constante UIA_CustomControlTypeId et peuvent être décrits par la propriété IUIAutomationElement::CurrentLocalizedControlType (ou IUIAutomationElement::CachedLocalizedControlType).
Le tableau suivant fait correspondre les rôles d’objet de Microsoft Active Accessibility aux types de contrôle UI Automation.
États et propriétés
Les éléments Microsoft Active Accessibility prennent en charge un ensemble commun de propriétés. Certaines propriétés, telles qu’accState, doivent décrire différentes conditions, en fonction du rôle de l’élément. Les serveurs doivent implémenter toutes les méthodes de IAccessible qui renvoient une propriété, même les propriétés qui ne sont pas pertinentes pour l’élément.
UI Automation définit des propriétés supplémentaires, dont certaines correspondent à des états dans Microsoft Active Accessibility. Certaines propriétés sont communes à tous les éléments, mais d’autres sont spécifiques aux types de contrôle et aux modèles de contrôle. Un fournisseur UI Automation n’est pas obligé d’implémenter des propriétés non pertinentes, mais peut renvoyer une valeur nulle pour toutes les propriétés qu’il ne prend pas en charge. Le service central UI Automation peut obtenir certaines propriétés du fournisseur de fenêtres par défaut, et celles-ci sont fusionnées avec les propriétés explicitement implémentées par le fournisseur.
En plus de prendre en charge beaucoup plus de propriétés, UI Automation permet de meilleures performances en permettant la mise en cache des propriétés.
Le tableau suivant montre la correspondance entre certaines propriétés des deux modèles. Pour des descriptions des ID de propriété UI Automation, veuillez consulter la section Identifiants de propriétés d’élément d’automatisation.
| Accesseur de propriété Active Accessibility | ID de propriété UI Automation | Notes |
|---|---|---|
| get_accKeyboardShortcut | UIA_AccessKeyPropertyId ou UIA_AcceleratorKeyPropertyId | UIA_AccessKeyPropertyId a la priorité si les deux sont présents. |
| get_accName | UIA_NamePropertyId | |
| get_accRole | UIA_ControlTypePropertyId | Veuillez consulter le tableau précédent pour mapper les rôles aux types de contrôle. |
| get_accValue | UIA_ValueValuePropertyId ou UIA_RangeValueValuePropertyId | Valide uniquement pour les types de contrôle prenant en charge IUIAutomationValuePattern ou IUIAutomationRangeValuePattern. Les valeurs des plages sont normalisées entre 0 et 100, pour être cohérentes avec le comportement de Microsoft Active Accessibility. Les valeurs sont représentées sous forme de chaînes. |
| get_accHelp | UIA_HelpTextPropertyId | |
| accLocation | UIA_BoundingRectanglePropertyId | |
| get_accDescription | Non pris en charge. | accDescription n’avait pas de spécification claire dans Microsoft Active Accessibility, ce qui a entraîné des serveurs plaçant différentes informations dans cette propriété. |
| get_accHelpTopic | Non pris en charge. |
Le tableau suivant montre les ID de propriété UI Automation qui correspondent aux constantes d’état d’objet de Microsoft Active Accessibility.
Pour une liste complète des ID de propriété, veuillez consulter la section Identifiants de propriétés.
Événements
Contrairement à Microsoft Active Accessibility, le mécanisme d’événement dans UI Automation ne repose pas sur le routage d’événements Windows, qui est étroitement lié aux handles de fenêtres, et ne nécessite pas que l’application cliente configure des hooks. Les abonnements aux événements peuvent être affinés à des parties particulières de l’arborescence, et non seulement à des événements particuliers. Les fournisseurs peuvent également affiner la génération d’événements en tenant compte des événements écoutés.
Il est également plus facile pour les clients de récupérer les éléments qui déclenchent des événements car ceux-ci sont directement transmis au rappel d’événement. Les propriétés de l’élément sont préchargées automatiquement, si une requête de cache a été fournie lorsque le client s’est abonné à l’événement.
Le tableau suivant montre la correspondance des constantes d’événements de Microsoft Active Accessibility et des ID d’événements UI Automation.
Accéder aux propriétés et objets d’Active Accessibility à partir de UI Automation
Une caractéristique clé de UI Automation qui n’est pas disponible dans Microsoft Active Accessibility est la possibilité de récupérer plusieurs propriétés avec une seule opération inter-processus.
Les clients existants de Microsoft Active Accessibility peuvent tirer parti de cette capacité en utilisant l’interface IUIAutomationLegacyIAccessiblePattern. Cette interface représente un modèle de contrôle qui expose les propriétés et méthodes Microsoft Active Accessibility sur les éléments UI. Lors de la récupération d’éléments, une application peut demander que ce modèle de contrôle et ses propriétés soient mis en cache.
IUIAutomationLegacyIAccessiblePattern permet également aux clients d’obtenir les propriétés Microsoft Active Accessibility d’éléments qui n’ont pas de support natif pour IAccessible.
Les modifications des propriétés d’un IUIAutomationLegacyIAccessiblePattern ne déclenchent pas d’événements UI Automation.