Philippe Beraud, Consultant Architecte chez Microsoft France et Julien Chable de Wygwam.
L'accessibilité est bien comprise dans le Web, aujourd'hui, mais la question se pose pour les applications RIA/Web 2.0 et les clients lourds/RDA. La question est notamment posée aujourd'hui par les grandes entreprises.
Définition: les dispositifs d'assistance permettent à une personne d'utiliser une personne malgré une gène. Par exemple, pour une personne non voyante l'ordinateur portable est un outil indispensable de communication avec le monde, et elle peut utiliser un clavier braille dynamique et/ou un logiciel de lecture à l'écran.
Concrètement, une application a besoin de s'exposer aux dispositifs d'assistance afin que le dispositif puisse communiquer et naviguer avec la machine. C'est une médiation à double sens: donner connaissance à l'utilisateur de l'application, mais aussi permettre à l'utilisateur d'agir sur l'application.
Historique des technologies:
User Interface Automation (UI Automation), arrivé avec .NET 3.0, a permis de décrire les applications de manière plus uniforme et complète, par exemple en prenant en charge les apparitions/disparitions d'éléments.
UI Automation ne se limite pas à l'accessibilité. Il permet aussi d'automatiser l'interface, par exemple pour conduire des tests d'interface automatisés.
Avec UI Automation, un développeur WPF ou Silverlight va pouvoir simplement donner des informations sur ce à quoi servent les contrôles. Il n'y a plus besoin de prendre de framework d'un éditeur tiers pour cela, ce qui permet des réductions de coûts d'apprentissage.
UI Automation permet de
- collecter des informatios sur l'IHM;
- naviguer entre et intéragir avec les éléments de l'IHM;
- être notifié des changements d'IHM.
Il ne permet pas de déplacer la souris et simuler la frappe sur le clavier, il va directement récupérer les contrôles pour leur passer des valeurs et réagir à leurs événements. Il ne s'applique bien entendu pas aux éléments non graphiques (Timers, ...).
Concepts d'UI Automation:
- arbre d'automatisation: arbre partant du bureau Windows et allant en profondeur jusque dans les applications;
- vues de l'arbre: permet de filtrer l'arbre, par exemple juste sur un certain type de contrôles;
- élément d'automatisation: l'atome, c'est le cas de tous les éléments d'IHM;
- sur chaque élémnt, il y a des propriétés, par exemple son rectangle d'occupation (permettant notamment de récupérer un contrôle par sa position);
- modèles de contrôles: donnent les capacités comportementales d'un élément, c'est un concept très important;
- événements: permet aux contrôles de notifier d'une action/changement.
Pour obtenir un élément AutomationElement, on peut le faire par:
- coordonnées;
- focus;
- handle HWND;
- parcours de l'IHM (arbre).
Les 3 propriétés essentielles:
- AutomationIdProperty: identifiant unique au sein de l'application;
- ControlTypeProperty: type primaire de contrôle;
- NameProperty: utilisée notamment pour la localisation (traduction).
Démo: UI Spy est un outil du SDK Windows qui permet de voir l'arbre des contrôles. On peut filtrer l'arbre par des conditions sur les propriétés.
Les fournisseurs doivent référencer l'assembly UIAutomationProvider et implémenter les interfaces UI.Automation.Provider
Côté client, on utilise les Patterns correspondant aux Providers.
Démo: en WPF, dans le fournisseur, on ajoute des propriétés AutomationProperties (exemple: <TextBox AutomationProperties.Name=''NomUtilisateur"/>. Côté client, on récupère l'élément AutomationElement et l'on peut agir dessus. Comble du bonheur, en Silverlight 2 ça fonctionne et c'est la même chose que les applications WPF. C'est un avantage sur Flash, car avec Flash on ne voit que l'application Flash et on ne peut pas creuser dedans pour voir ses contrôles.
Comments