Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
L’API Windows Automation se compose de deux technologies : Microsoft Active Accessibility et Microsoft UI Automation. Microsoft Active Accessibility est la technologie d’accessibilité héritée qui a été introduite en tant que complément de plateforme pour Windows 95, tandis que UI Automation est une technologie plus récente et plus capable qui dépasse les limitations inhérentes à l’accessibilité Active Microsoft.
Cette rubrique récapitule les principales différences entre Microsoft Active Accessibility et UI Automation. Il 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 de MSAA
- Choix de 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, les principes de conception de base sont similaires. L’objectif des deux technologies est d’exposer des informations enrichies sur les éléments d’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 rendent les applications exécutées sur Windows plus accessibles aux personnes atteintes d’une vision, d’une audition ou d’un handicap de mouvement.
Microsoft Active Accessibility et UI Automation exposent le modèle objet de l’interface utilisateur en tant qu’arborescence hiérarchique, enracinée sur le bureau. Microsoft Active Accessibility représente des éléments d’interface utilisateur individuels en tant qu’objets accessibles, et UI Automation les représente en tant qu’éléments Automation. Les deux font référence à l’outil d’accessibilité ou au programme d’automatisation logicielle en tant que client. Toutefois, Microsoft Active Accessibility fait référence à l’application ou au contrôle offrant l’interface utilisateur pour l’accessibilité en tant que serveur, tandis que UI Automation fait référence à ceci en tant que 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 fixe de propriétés. UI Automation offre un ensemble plus riche de propriétés, ainsi qu’un ensemble d’interfaces étendues appelées modèles de contrôle pour manipuler des objets accessibles de manière à ce que Microsoft Active Accessibility ne puisse pas.
Pour plus d’informations, consultez Vue d’ensemble des propriétés UI Automation et Vue d’ensemble des modèles de contrôle UI Automation.
Rôles MSAA et modèles de contrôle UI Automation
Microsoft a conçu le modèle objet Microsoft Active Accessibility en même temps que Windows 95 a été publié. Le modèle est basé sur des « rôles » définis il y a dix ans, et vous ne pouvez pas prendre en charge de nouveaux comportements d’interface utilisateur ou fusionner deux rôles ou plus ensemble. Il n’existe aucun modèle objet texte, par exemple, pour aider les technologies d’assistance à traiter le contenu web complexe. UI Automation résout ces limitations en introduisant des modèles de contrôle qui permettent aux objets de prendre en charge plusieurs rôles, et le modèle de contrôle texte UI Automation offre un modèle objet de texte à part entière.
Navigation dans le modèle objet
Une autre limitation de Microsoft Active Accessibility implique de naviguer dans le modèle objet. Microsoft Active Accessibility représente l’interface utilisateur sous la forme d’une hiérarchie d’objets accessibles. Les clients naviguent d’un objet accessible vers un autre à l’aide d’interfaces et de méthodes disponibles à partir de 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 COM IEnumVARIANT standard. Toutefois, les clients doivent être en mesure de traiter les deux approches pour n’importe quel serveur. Cette ambiguïté signifie un travail supplémentaire pour les implémenteurs clients et des modèles objet accessibles rompus pour les implémenteurs de serveur.
UI Automation représente l’interface utilisateur en tant qu’arborescence hiérarchique d’éléments Automation et fournit une interface unique pour naviguer dans l’arborescence. Les clients peuvent personnaliser l’affichage des éléments dans l’arborescence en définissant et en filtrant.
Extensibilité du modèle objet
Les propriétés et fonctions Microsoft Active Accessibility ne peuvent pas être étendues sans rupture ni modification de la spécification de l’interface COM IAccessible . Le résultat est que le nouveau comportement de contrôle ne peut pas être exposé par le biais du modèle objet ; il a tendance à être statique.
Avec UI Automation, à mesure que 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 plus d’informations, consultez Propriétés personnalisées, événements et modèles de contrôle.
Transition de MSAA
L’infrastructure de l’API Windows Automation prend en charge la transition des serveurs Microsoft Active Accessibility vers des fournisseurs UI Automation. L’interface IAccessibleEx permet la prise en charge des propriétés et des modèles de contrôle UI Automation spécifiques à ajouter aux serveurs d’accessibilité Microsoft Active Accessibilité hérités sans avoir à réécrire l’ensemble de l’implémentation. L’interface IAccessibleEx permet également aux clients Microsoft Active Accessibility in-process d’accéder directement aux interfaces du fournisseur UI Automation, plutôt que via les interfaces clientes UI Automation. Pour plus d’informations, consultez l’interface IAccessibleEx.
Choix de Microsoft Active Accessibility, UI Automation ou IAccessibleEx
Cette section vous aide à déterminer la solution d’API Windows Automation à utiliser pour implémenter un produit de technologie d’assistance ou pour rendre votre application accessible aux produits technologiques d’assistance.
Nouvelles applications et contrôles
Si vous développez une nouvelle application ou un contrôle, Microsoft recommande d’utiliser UI Automation. Bien que Microsoft Active Accessibility puisse être plus facile à implémenter à court terme, les limitations inhérentes à cette technologie, telles que son modèle objet vieillissant et son incapacité à prendre en charge les nouveaux comportements d’interface utilisateur ou les rôles de fusion, rendent plus difficile et coûteux à long terme. Ces limitations deviennent particulièrement évidentes lors de l’introduction de nouveaux contrôles.
Le modèle objet UI Automation est plus facile à utiliser et est plus flexible que celui de Microsoft Active Accessibility. Les éléments UI Automation reflètent l’évolution des interfaces utilisateur, et les développeurs peuvent définir des modèles de contrôle UI Automation personnalisés, des propriétés et des événements.
Microsoft Active Accessibility tend à s’exécuter lentement pour les clients qui n’ont plus de processus. Pour améliorer les performances, les développeurs de programmes d’outils d’accessibilité choisissent souvent de se connecter et d’exécuter leurs programmes dans le processus d’application cible : une approche extrêmement difficile et risquée. UI Automation est beaucoup plus facile à implémenter pour les clients hors processus et offre beaucoup plus de performances et de fiabilité.
Implémentations d’accessibilité active Microsoft existantes
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 référence 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 d’objets accessibles existantes.
- Votre implémentation IAccessibleEx doit se conformer à la spécification Microsoft Active Accessibility et à la spécification UI Automation. Microsoft fournit un ensemble d’outils pour valider la conformité avec les deux spécifications. Pour plus d’informations, consultez Test pour 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 héritées du serveur Microsoft Active Accessibility pour la compatibilité descendante si nécessaire. Du point de vue du client UI Automation, il n’existe aucune différence entre les fournisseurs UI Automation et les serveurs Microsoft Active Accessibility qui implémentent IAccessibleEx correctement.
Pour plus d’informations, consultez l’interface IAccessibleEx.
Rubriques connexes