UI Automation et accessibilité active
Microsoft Active Accessibility est l’API héritée qui a été introduite dans Windows 95 et a été conçue pour rendre les applications Windows accessibles. Microsoft UI Automation est le nouveau modèle d’accessibilité pour Windows et est destiné à 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 à 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ès aux propriétés et objets d’accessibilité active à partir de UI Automation
- Rubriques connexes
Langages de programmation
Microsoft Active Accessibility est basé sur le modèle d’objet de composant (COM) avec prise en charge des interfaces doubles et est donc programmable en C/C++ et dans les langages de script.
Lorsque UI Automation a été introduit, l’API cliente était limitée au code managé, tandis que l’API du fournisseur incluait à la fois des implémentations managées et non managées. Avec Windows 7, une nouvelle API cliente 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 de base se trouve entre le serveur (fournisseur) et le client. Le service principal effectue des appels aux 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 d’interface utilisateur. Les applications clientes accèdent à ce service principal en créant un objet CUIAutomation . Cet objet prend en charge un ensemble d’interfaces clientes distinctes des interfaces du fournisseur. Pour plus d’informations, consultez Création de l’objet CUIAutomation.
UI Automation fournisseurs peuvent fournir des informations aux clients Microsoft Active Accessibility, et les serveurs Microsoft Active Accessibility peuvent fournir des informations à UI Automation applications clientes. Toutefois, étant donné que 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 la forme d’une interface IAccessible associée à un identificateur enfant. Il est difficile de comparer deux pointeurs IAccessibles pour déterminer s’ils font référence au même élément.
Dans UI Automation, chaque élément est représenté sous la forme d’un objet qui expose l’interface IUIAutomationElement aux clients. Les éléments peuvent être comparés par leurs identificateurs d’exécution, qui sont récupérés à l’aide de IUIAutomationElement::GetRuntimeId.
Arborescences et navigation
Les éléments d’interface utilisateur à l’écran peuvent être vus comme une arborescence avec le bureau comme racine, les fenêtres d’application comme enfants immédiats et les éléments dans les applications comme descendants supplémentaires.
Dans Microsoft Active Accessibility, de nombreux éléments d’interface utilisateur qui ne sont pas pertinents pour les utilisateurs finaux sont exposés dans l’arborescence. Les applications clientes doivent examiner tous les éléments de l’arborescence pour déterminer quels éléments sont significatifs.
Les applications clientes UI Automation voient l’interface utilisateur via une vue filtrée. La vue contient uniquement des éléments qui fournissent des informations à l’utilisateur ou avec lesquels l’utilisateur peut interagir. Les vues prédéfinies qui incluent uniquement des éléments de contrôle et uniquement des éléments de contenu sont disponibles, et les applications clientes peuvent définir des vues personnalisées. UI Automation permet de décrire plus facilement l’interface utilisateur à l’utilisateur et d’aider l’utilisateur à interagir avec les applications.
Dans Microsoft Active Accessibility, la navigation entre les éléments est spatiale, par exemple, le déplacement vers l’élément qui se trouve à gauche sur l’écran, logique, par exemple, le passage à l’élément de menu suivant ou à l’élément suivant dans l’ordre de tabulation dans une boîte de dialogue, ou hiérarchique, par exemple, le déplacement vers le premier élément enfant d’un conteneur ou d’un élément enfant vers 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 d’interface utilisateur 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 d’IRawElementProviderSimple. La navigation est principalement hiérarchique ; c’est-à-dire des parents aux enfants et d’un frère à l’autre. Toutefois, la navigation entre frères a un élément logique, car elle peut suivre l’ordre de tabulation. Un client peut naviguer à partir de n’importe quel point de départ, à l’aide d’une vue filtrée de l’arborescence, à l’aide de IUIAutomationTreeWalker. Un client peut également accéder à des enfants ou des descendants particuliers à l’aide de IUIAutomationElement::FindFirst et IUIAutomationElement::FindAll. Par exemple, il est facile 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 Microsoft Active Accessibility. Certains éléments, tels que les listes déroulantes et les fenêtres contextuelles, apparaissent deux fois dans l’arborescence Microsoft Active Accessibility, et la navigation à partir de ces éléments peut avoir des résultats inattendus. Il est difficile d’implémenter correctement Microsoft Active Accessibility pour un contrôle de barre d’armature. UI Automation permet la réparentation et le repositionnement, afin qu’un élément puisse ê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 d’élément dans l’interface utilisateur, telle 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 est obtenue à 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 dissocie le type de contrôle de l’élément, qui est décrit par la propriété IUIAutomationElement::CurrentControlType (ou IUIAutomationElement::CachedControlType) 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 complet des fonctionnalités prises en charge par un élément d’interface utilisateur particulier. Certains fournisseurs sont nécessaires pour prendre en charge un modèle de contrôle particulier. Par exemple, le fournisseur d’une zone de case activée doit prendre en charge le modèle de contrôle Bascule. D’autres fournisseurs sont nécessaires pour prendre en charge un ou plusieurs des modèles de contrôle. Par exemple, un bouton doit prendre en charge le bouton bascule ou le modèle de contrôle Invoke . D’autres encore ne prennent pas en charge les modèles 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 mappeles rôles d’objet Microsoft Active Accessibility à UI Automation types de contrôle.
É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 que accState, doivent décrire différentes conditions, selon le rôle de l’élément. Les serveurs doivent implémenter toutes les méthodes d’IAccessible qui retournent une propriété, même celles 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 de UI Automation n’a pas besoin d’implémenter des propriétés non pertinentes, mais peut retourner une valeur Null pour toutes les propriétés qu’il ne prend pas en charge. Le service principal UI Automation peut obtenir certaines propriétés du fournisseur de fenêtres par défaut, qui sont fusionnées avec des propriétés explicitement implémentées par le fournisseur.
En plus de prendre en charge de nombreuses autres propriétés, UI Automation permet de meilleures performances en autorisant la mise en cache des propriétés.
Le tableau suivant montre la correspondance entre certaines propriétés dans les deux modèles. Pour obtenir une description des ID de propriété UI Automation, consultez Identificateurs de propriété d’élément Automation.
| Accesseur de propriété Active Accessibility | ID de propriété UI Automation | Notes |
|---|---|---|
| get_accKeyboardShortcut | UIA_AccessKeyPropertyId ou UIA_AcceleratorKeyPropertyId | UIA_AccessKeyPropertyId est prioritaire si les deux sont présents. |
| get_accName | UIA_NamePropertyId | |
| get_accRole | UIA_ControlTypePropertyId | Consultez le tableau précédent pour le mappage des rôles aux types de contrôle. |
| get_accValue | UIA_ValueValuePropertyId ou UIA_RangeValueValuePropertyId | Valide uniquement pour les types de contrôles qui prennent en charge IUIAutomationValuePattern ou IUIAutomationRangeValuePattern. Les valeurs de plage sont normalisées à 0-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 conduit les serveurs à placer 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 de l’objet Microsoft Active Accessibility.
Pour obtenir la liste complète des ID de propriété, consultez Identificateurs 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 des événements Windows, qui est étroitement lié aux handles de fenêtre et ne nécessite pas que l’application cliente configure des connexions. Les abonnements aux événements peuvent être ajustés à des parties particulières de l’arborescence, pas seulement à des événements particuliers. Les fournisseurs peuvent également affiner les événements d’élévation en effectuant 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 ceux-ci sont passés directement au rappel d’événement. Les propriétés de l’élément sont automatiquement prédéfinies, si une demande de cache a été fournie lorsque le client s’est abonné à l’événement.
Le tableau suivant montre la correspondance des constantes d’événement Microsoft Active Accessibility et des ID d’événement UI Automation.
Accès aux propriétés et objets d’accessibilité active à partir de UI Automation
Une fonctionnalité clé de UI Automation qui n’est pas disponible dans Microsoft Active Accessibility est la possibilité d’extraire plusieurs propriétés avec une seule opération inter-processus.
Les clients Microsoft Active Accessibility existants peuvent tirer parti de cette fonctionnalité à l’aide de 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 d’interface utilisateur. 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 des propriétés Microsoft Active Accessibility à partir d’éléments qui n’ont pas de prise en charge native pour IAccessible.
Les modifications apportées aux propriétés d’un IUIAutomationLegacyIAccessiblePattern ne déclenchent pas d’événements UI Automation.
Rubriques connexes
Commentaires
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultez https://aka.ms/ContentUserFeedback.
Envoyer et afficher des commentaires pour