Comparaison entre Microsoft Active Accessibility et UI Automation
Windows Automation API comprend deux technologies : Microsoft Active Accessibility et Microsoft UI Automation. Microsoft Active Accessibility est la technologie d'accessibilité héritée qui a été introduite sous forme de complément de plateforme pour Windows 95. Par ailleurs, UI Automation est une technologie plus récente et plus performante qui surmonte les limites inhérentes à Microsoft Active Accessibility.
Cette rubrique résume les différences majeures entre Microsoft Active Accessibility et UI Automation. Elle comprend les sections suivantes :
- Principes de conception de base
- Propriétés et modèles de contrôle
- Rôles MSAA et modèles de contrôle UI Automation
- Navigation dans le modèle objet
- Extensibilité du modèle objet
- Transition depuis MSAA
- Choisir entre Microsoft Active Accessibility, UI Automation ou IAccessibleEx
- Rubriques connexes
Principes de conception de base
Bien que Microsoft Active Accessibility et UI Automation soient deux technologies différentes, leurs principes de conception de base sont similaires. L'objectif de ces deux technologies est d'exposer des informations enrichies sur les éléments de l'interface utilisateur utilisés dans les applications Windows. Les développeurs d'outils d'accessibilité peuvent utiliser ces informations pour créer des logiciels qui facilitent l'accès aux applications Windows pour les personnes souffrant de troubles de la vue, de l'audition ou du mouvement.
Microsoft Active Accessibility et UI Automation exposent tous deux le modèle objet de l'interface utilisateur sous la forme d'arborescence hiérarchique, enracinée sur le bureau. Microsoft Active Accessibility représente les éléments individuels de l'interface utilisateur comme des objets accessibles, et UI Automation les représente comme des éléments d'automatisation. Tous deux désignent l'outil d'accessibilité ou le programme d'automatisation du logiciel par le terme client. Toutefois, Microsoft Active Accessibility désigne l'application ou le contrôle qui offre l'interface utilisateur à des fins d'accessibilité par le terme serveur, tandis que UI Automation le désigne par le terme fournisseur.
Propriétés et modèles de contrôle
Microsoft Active Accessibility offre une interface COM (Component Object Model) unique avec un petit ensemble de propriétés fixes. UI Automation offre un ensemble plus enrichi de propriétés, ainsi qu'un ensemble d'interfaces étendues appelées modèles de contrôle pour manipuler les objets accessibles d'une manière à laquelle Microsoft Active Accessibility ne peut procéder.
Pour en savoir plus, reportez-vous à Vue d'ensemble des propriétés d'UI Automation et Vue d'ensemble des modèles de contrôle d'UI Automation.
Rôles MSAA et modèles de contrôle d'UI Automation
Microsoft a conçu le modèle d'objet Microsoft Active Accessibility à peu près au même moment où Windows 95 a été mis en production. Le modèle est basé sur des « rôles » définis il y a dix ans. Il n'est pas possible de prendre en charge de nouveaux comportements de l'interface utilisateur ou de fusionner deux rôles ou plus. Ainsi, le modèle d'objet texte n'existe pas pour aider les technologies d'assistance à traiter les contenus web complexes. UI Automation supprime ces limitations en introduisant des modèles de contrôle qui permettent aux objets de prendre en charge plus d'un rôle, et le modèle de contrôle d'UI Automation Texte offre un modèle objet texte complet.
Navigation dans le modèle objet
Une autre limitation de Microsoft Active Accessibility concerne la navigation dans le modèle objet. Microsoft Active Accessibility représente l'interface utilisateur comme une hiérarchie d'objets accessibles. Les clients naviguent d'un objet accessible à un autre en utilisant les interfaces et les méthodes disponibles dans l'objet accessible. Les serveurs peuvent exposer les enfants d'un objet accessible avec les propriétés de l'interface IAccessible ou avec l'interface standard IEnumVARIANT COM. Les clients doivent toutefois être en mesure de gérer les deux approches pour tout serveur. Cette ambiguïté se traduit par un surplus de travail pour les responsables de l'implémentation des clients et par des modèles d'objets accessibles non conformes pour les responsables de l'implémentation des serveurs.
UI Automation représente l'interface utilisateur sous la forme d'arborescence hiérarchique d'éléments d'automatisation et fournit une interface unique pour naviguer dans l'arborescence. Les clients peuvent personnaliser l'affichage des éléments dans l'arborescence en procédant à un cadrage et à un filtrage.
Extensibilité du modèle objet
Les propriétés et fonctions de Microsoft Active Accessibility ne peuvent être étendues sans rompre ou modifier la spécification de l'interface IAccessible COM. En conséquence, le modèle objet ne permet pas d'exposer un nouveau comportement de contrôle, qui a tendance à être statique.
En revanche, avec UI Automation, lorsque de nouveaux éléments d'interface utilisateur sont créés, les développeurs d'applications peuvent introduire des propriétés personnalisées, des modèles de contrôle et des événements pour décrire les nouveaux éléments. Pour en savoir plus, reportez-vous à Propriétés personnalisées, événements et modèles de contrôle.
Transition depuis MSAA
L'infrastructure Windows Automation API prend en charge la transition des serveurs Microsoft Active Accessibility vers les fournisseurs UI Automation. L'interface IAccessibleEx permet de prendre en charge des propriétés et des modèles de contrôle UI Automation spécifiques qui peuvent être ajoutés aux serveurs Microsoft Active Accessibility hérités sans qu'il soit nécessaire de réécrire l'ensemble de l'implémentation. L'interface IAccessibleEx autorise également les clients de Microsoft Active Accessibility in-process à accéder directement aux interfaces des fournisseurs UI Automation, plutôt que de passer par les interfaces des clients UI Automation. Pour en savoir plus, reportez-vous à L'interface IAccessibleEx.
Choisir Microsoft Active Accessibility, UI Automation ou IAccessibleEx
Cette section vous permet de déterminer quelle solution Windows Automation API utiliser pour implémenter un produit de technologie d'assistance ou pour rendre votre application accessible aux produits de technologie d'assistance.
Nouvelles applications et contrôles
Si vous développez une nouvelle application ou un nouveau contrôle, Microsoft recommande d'utiliser UI Automation. Bien que Microsoft Active Accessibility puisse être plus facile à mettre en œuvre à court terme, les limitations inhérentes à cette technologie, notamment son modèle objet vieillissant et son incapacité à prendre en charge de nouveaux comportements d'interface utilisateur ou à fusionner les rôles, représentent une difficulté et un coût supplémentaires à long terme. Ces limitations deviennent particulièrement évidentes lors de l'introduction de nouveaux contrôles.
Le modèle objet d'UI Automation est plus facile à utiliser et est plus flexible que celui de Microsoft Active Accessibility. Les éléments d'UI Automation reflètent l'évolution des interfaces utilisateur et les développeurs peuvent définir des modèles, des propriétés et des événements de contrôle d'UI Automation personnalisés.
Microsoft Active Accessibility a tendance à s'exécuter lentement pour les clients dont le processus s'arrête. Pour améliorer les performances, les développeurs de programmes d'outils d'accessibilité choisissent souvent de se connecter au processus de l'application cible et de l'exécuter, une approche extrêmement difficile et risquée. UI Automation est beaucoup plus facile à implémenter pour les clients hors processus et offre de bien meilleures performances et une plus grande fiabilité.
Implémentations existantes de Microsoft Active Accessibility
Si vous mettez à jour une application ou un contrôle existant basé sur Microsoft Active Accessibility, envisagez d'ajouter la prise en charge d'UI Automation en implémentant l'interface IAccessibleEx. Tout d'abord, vérifiez que votre application ou contrôle répond aux exigences suivantes :
- la hiérarchie du serveur Microsoft Active Accessibility de ligne de base des objets accessibles doit être bien organisée et sans erreur. IAccessibleEx ne peut pas résoudre les problèmes liés aux hiérarchies des objets accessibles existantes.
- Votre implémentation d'IAccessibleEx doit être conforme à la fois à la spécification de Microsoft Active Accessibility et à la spécification d'UI Automation. Microsoft fournit un ensemble d'outils permettant de valider la conformité aux deux spécifications. Pour en savoir plus, reportez-vous à Tester l'accessibilité.
Si l'une de ces exigences n'est pas remplie, envisagez d'implémenter UI Automation en mode natif. Vous pouvez conserver les implémentations du serveur Microsoft Active Accessibility héritées à des fins de rétrocompatibilité au besoin. Du point de vue du client UI Automation, il n'y a pas de différence entre les fournisseurs UI Automation et les serveurs Microsoft Active Accessibility qui implémentent bien IAccessibleEx.
Pour en savoir plus, reportez-vous à L'interface IAccessibleEx.
Rubriques connexes