Accessibilité pour les applications Windows Runtime en C#/VB/C++ et XAML

Applies to Windows and Windows Phone

Nous décrivons certains des concepts et technologies en rapport avec les scénarios d’accessibilité dans une application du Windows Runtime qui utilise C#, Visual Basic ou des extensions de composant Visual C++ (C++/CX) pour son code d’application, et XAML pour sa définition d’interface utilisateur.

Vous cherchez la version JavaScript de cette rubrique ? Voir Accessibilité des applications Windows Runtime en JavaScript et HTML.

Feuille de route : comment cette rubrique s’articule-t-elle par rapport aux autres ? Voir :

Prérequis

Nous partons du principe que vous savez créer une application élémentaire du Windows Runtime. Pour obtenir des instructions sur la création de votre première application Windows Runtime en C++, C# ou Visual Basic, voir Créer votre première application Windows Runtime en C# ou Visual Basic ou Créer votre première application du Windows Store en C++.

Accessibilité et votre application

L’accessibilité consiste à rendre vos applications utilisables par des personnes ayant des limites qui empêchent ou entravent l’utilisation d’interfaces utilisateur conventionnelles. Pour certaines situations, les exigences en matière d’accessibilité sont imposées par la loi. Il est toutefois préférable de gérer les aspects liés à l’accessibilité quelles que soient les exigences juridiques, afin que votre application ait l’audience la plus étendue possible. Il existe également une déclaration du Windows Store concernant l’accessibilité de votre application.

  • Applies to Windows Phone

Déclarer l’application comme accessible n’est pertinent que par rapport au Windows Store.

Il existe de nombreuses invalidités et handicaps, notamment des limitations relatives à la mobilité, la vision, la perception des couleurs, l’audition, la parole, la cognition et l’alphabétisation. Toutefois, vous pouvez répondre à la plupart des besoins en suivant les recommandations fournies dans cette rubrique. Vous devez notamment offrir :

  • la prise en charge d’interactions au clavier et de lecteurs d’écran ;
  • la prise en charge de la personnalisation utilisateur, y compris les paramètres de police, de zoom (loupe), de couleur et de contraste élevé ;
  • des alternatives ou suppléments pour des parties de votre interface utilisateur.

Les contrôles du Windows Runtime pour XAML fournissent une prise en charge intégrée du clavier. Ils prennent aussi en charge les technologies d’assistance comme les lecteurs d’écran, lesquelles tirent parti d’infrastructures d’accessibilité qui prennent déjà en charge les applications Windows Runtime, HTML et d’autres technologies d’interface utilisateur. Cette prise en charge intégrée offre un niveau d’accessibilité de base que vous pouvez personnaliser avec très peu de travail, en définissant quelques propriétés. Si vous créez vos propres contrôles et composants XAML personnalisés, vous pouvez également ajouter une prise en charge similaire à ces contrôles en faisant appel au concept d’homologue d’automation.

De plus, les fonctionnalités de liaison de données, de style et de modèle simplifient l’implémentation de la prise en charge de modifications dynamiques des paramètres d’affichage et du texte pour d’autres interfaces utilisateur.

UI Automation

La prise en charge de l’accessibilité des applications Windows Runtime en C++, C# ou Visual Basic provient principalement de la prise en charge intégrée de l’infrastructure Microsoft UI Automation. Cette prise en charge est fournie via des classes de base et le comportement intégré de l’implémentation de classe pour les types de contrôle, ainsi que via une représentation d’interface Windows Runtime de l’API du fournisseur UI Automation. Chaque classe de contrôle utilise les concepts UI Automation des homologues d’automation et des modèles d’automation pour signaler le rôle et le contenu des contrôles aux clients UI Automation. L’application du Windows Runtime est traitée en tant que fenêtre de niveau supérieur par UI Automation ; par l’intermédiaire de l’infrastructure UI Automation, tout le contenu relatif à l’accessibilité présent dans cette fenêtre d’application est disponible pour un client UI Automation. Pour plus d’informations sur UI Automation, voir Vue d’ensemble d’UI Automation.

Technologie d’assistance

De nombreux besoins d’accessibilité des utilisateurs sont satisfaits par des produits de technologies d’assistance installés par l’utilisateur ou par des outils et paramètres fournis par le système d’exploitation. Parmi les fonctionnalités proposées, citons les lecteurs d’écran, le grossissement de l’écran et les paramètres de contraste élevé.

Les produits de technologie d’assistance englobent une large gamme de logiciels et de matériel. Ces produits fonctionnent par le biais des infrastructures d’accessibilité et d’interface de clavier standard qui signalent les informations relatives au contenu et à la structure d’une interface utilisateur aux lecteurs d’écran et autres technologies d’assistance. Voici quelques exemples de produits de technologie d’assistance :

  • Clavier visuel pour la saisie d’un texte à l’aide d’un pointeur au lieu d’un clavier ;
  • logiciels de reconnaissance vocale, qui convertissent la parole en texte tapé ;
  • lecteurs d’écran, qui convertissent le texte en parole ou autres formes telles que le Braille ;
  • lecteur d’écran du Narrateur, qui fait spécifiquement partie de Windows (le Narrateur dispose d’un mode tactile, qui permet de lire sur l’écran en exécutant des mouvements tactiles quand aucun clavier n’est disponible) ;
  • programmes ou paramètres qui ajustent l’affichage ou certaines de ses zones, par exemple les thèmes à contraste élevé, les valeurs points par pouce (ppp) de l’affichage ou l’outil Loupe.

Les applications qui disposent d’une bonne prise en charge des claviers et des lecteurs d’écran fonctionnent généralement bien avec différents produits de technologies d’assistance. Dans de nombreux cas, une application Windows Runtime fonctionne avec ces produits sans modification supplémentaire d’informations ou de structure. Toutefois, vous souhaiterez peut-être modifier certains paramètres pour obtenir une expérience d’accessibilité optimale ou mettre en œuvre une prise en charge supplémentaire.

Certaines des options à votre disposition pour tester des scénarios d’accessibilité de base avec les technologies d’assistance sont répertoriées dans Test de votre application en matière d’accessibilité.

Prise en charge de lecteur d’écran et informations d’accessibilité de base

Les lecteurs d’écran permettent d’accéder au texte d’une application en effectuant un rendu de celui-ci sous une autre forme, telle qu’une sortie en langue parlée ou en Braille. Le comportement exact d’un lecteur d’écran dépend du logiciel et de la façon dont l’utilisateur l’a configuré.

Par exemple, certains lecteurs d’écran lisent la totalité de l’interface utilisateur de l’application lorsque l’utilisateur démarre ou bascule vers l’application affichée. L’utilisateur peut ainsi recevoir tout le contenu d’information disponible avant de commencer la navigation. Certains lecteurs d’écran lisent aussi le texte associé à un contrôle individuel lorsqu’il reçoit le focus pendant la navigation par tabulation. Cela permet aux utilisateurs de s’orienter à mesure qu’ils naviguent parmi les contrôles d’entrée d’une application. Le Narrateur est un exemple de lecteur d’écran qui fournit ces deux comportements, en fonction du choix de l’utilisateur.

L’information la plus importante dont un lecteur d’écran ou autre technologie d’assistance a besoin pour aider les utilisateurs à comprendre ou à naviguer dans une application est un nom accessible pour les parties d’élément de l’application. Dans de nombreux cas, un contrôle ou élément possède déjà un nom accessible calculé à partir d’autres valeurs de propriétés que vous avez fournies par un autre moyen. Le cas le plus courant dans lequel vous pouvez utiliser un nom déjà calculé concerne un élément qui prend en charge et affiche du texte interne. Pour les autres éléments, vous devez parfois prendre en compte d’autres manières de fournir un nom accessible en appliquant les meilleures pratiques en matière de structure d’élément. Parfois, vous devez fournir un nom spécifié de manière explicite comme nom accessible à des fins d’accessibilité de l’application. Pour obtenir une liste des valeurs calculées qui fonctionnent dans les éléments d’interface utilisateur courants et pour plus d’informations sur les noms accessibles en général, voir Exposition d’informations d’accessibilité de base concernant les éléments d’interface utilisateur.

Plusieurs autres propriétés d’automation sont disponibles (notamment les propriétés de clavier décrites dans la section suivante). Toutefois, tous les lecteurs d’écran ne prennent pas en charge toutes les propriétés d’automation. En général, vous devez définir toutes les propriétés d’automatisation appropriées et les tester pour fournir la prise en charge la plus large possible pour les lecteurs d’écran.

Prise en charge du clavier

Pour fournir une bonne prise en charge du clavier, vous devez vous assurer que chaque partie de votre application peut être utilisée avec un clavier. Si votre application utilise principalement les contrôles standard et n’utilise aucun contrôle personnalisé, vous n’aurez pas beaucoup de tâches supplémentaires à effectuer. Le modèle de contrôle de base du XAML Windows Runtime fournit une prise en charge intégrée du clavier incluant la navigation par tabulation, la saisie de texte et la prise en charge spécifique aux contrôles. Les éléments qui servent de conteneurs de disposition (tels que les panneaux) utilisent l’ordre de disposition pour établir un ordre de tabulation par défaut. Cet ordre est souvent l’ordre de tabulation correct à utiliser pour une représentation accessible de l’interface utilisateur. Si vous utilisez les contrôles ListBox et GridView pour afficher des données, ils fournissent une navigation avec les touches de direction intégrée. Si vous utilisez un contrôle Button, il gère déjà les touches Espace ou Entrée pour l’activation du bouton.

Pour plus d’informations sur tous les aspects de la prise en charge du clavier dans une application Windows Runtime, y compris sur l’ordre de tabulation et la navigation ou l’activation basée sur les touches, voir Implémentation de l’accessibilité du clavier.

Média et sous-titrage

Pour une application Windows Runtime en C++, C# ou Visual Basic, vous affichez généralement du contenu audiovisuel par le biais d’un objetMediaElement. Vous pouvez utiliser les API MediaElement pour contrôler la lecture multimédia. À des fins d’accessibilité, fournissez des contrôles qui permettent aux utilisateurs de lire, de mettre en pause et d’arrêter le contenu multimédia selon leurs besoins. Le contenu multimédia inclut parfois des composants supplémentaires destinés à l’accessibilité, tels que les sous-titres ou les pistes audio de substitution qui comportent des descriptions narratives. Pour plus d’informations sur les concepts liés au contenu multimédia, à MediaElement et à l’accessibilité, voir Rendre le contenu multimédia accessible.

Texte accessible

Trois principaux aspects du texte sont pertinents en ce qui concerne l’accessibilité :

  • Des outils doivent déterminer si le texte doit être lu dans le cadre d’une traversée de séquence de tabulation ou uniquement dans le cadre d’une représentation de document globale. Vous pouvez aider à contrôler cette détermination en choisissant l’élément approprié pour l’affichage du texte ou en ajustant les propriétés de ces éléments de texte. Chaque élément de texte disponible dans une application Windows Runtime remplit une fonction donnée, souvent associée à un rôle UI Automation particulier. L’utilisation de l’élément incorrect peut entraîner le signalement du rôle incorrect à UI Automation et la création d’une expérience confuse pour un utilisateur de technologie d’assistance.
  • De nombreux utilisateurs souffrent de limitations visuelles qui font que le texte est difficile à lire en cas d’insuffisance du contraste par rapport à l’arrière-plan. L’impact sur l’utilisateur est délicat à évaluer pour un concepteur d’application qui ne souffre pas de la même limitation visuelle. Par exemple, un choix des couleurs inapproprié lors de la conception peut empêcher certains utilisateurs daltoniens de pouvoir lire le texte. Les recommandations en matière d’accessibilité effectuées initialement pour le contenu Web définissent des normes de contraste qui peuvent éviter ces problèmes également dans les applications. Pour plus d’informations, voir Respect des exigences pour fournir un texte accessible.
  • De nombreux utilisateurs éprouvent des difficultés à lire du texte trop petit. Vous pouvez éviter que ce problème ne se produise en faisant en sorte que le texte de l’interface utilisateur de votre application soit suffisamment grand en premier lieu. Toutefois, ceci est difficile avec les applications qui affichent une grande quantité de texte ou du texte combiné à d’autres éléments visuels. Dans les cas de ce type, assurez-vous que l’application interagit correctement avec les fonctionnalités système qui peuvent agrandir l’affichage ainsi que le texte qu’elle contient. (Certains utilisateurs modifient les valeurs ppp comme option d’accessibilité. Cette option est disponible depuis Agrandir les éléments affichés à l’écran dans les Options d’ergonomie, qui redirige vers une interface utilisateur du Panneau de configuration pour Apparence et personnalisation / Affichage.)

Prise en charge des thèmes à contraste élevé

Les contrôles d’interface utilisateur fournis pour les applications Windows Runtime en C++, C# ou Visual Basic utilisent une représentation visuelle définie dans le cadre d’un dictionnaire de ressources XAML de thèmes. Un ou plusieurs de ces thèmes sont spécifiquement utilisés lorsque le système est configuré en mode de contraste élevé. Lorsque l’utilisateur passe en mode de contraste élevé en recherchant dynamiquement le thème approprié dans un dictionnaire de ressources, tous vos contrôles d’interface utilisateur utilisent aussi un thème à contraste élevé approprié. Assurez-vous simplement de ne pas avoir désactivé les thèmes en spécifiant un style explicite ou en utilisant une autre technique de style qui empêche les thèmes à contraste élevé de se charger et de remplacer vos modifications de style. Pour plus d’informations, voir Prise en charge des thèmes à contraste élevé.

Conception d’une interface utilisateur alternative

Quand vous concevez vos applications, demandez-vous comment elles peuvent être utilisées par les personnes à mobilité réduite, malvoyantes ou malentendantes. Étant donné que les produits de technologies d’assistance utilisent fréquemment les interfaces utilisateur standard, il est particulièrement important de fournir une bonne prise en charge du clavier et des lecteurs d’écran, même si vous n’effectuez aucun autre réglage relatif à l’accessibilité.

Dans de nombreux cas, plusieurs techniques permettent de transmettre les informations essentielles afin d’élargir votre audience. Par exemple, vous pouvez mettre en surbrillance des informations à l’aide d’informations sur les icônes et sur les couleurs pour aider les utilisateurs qui ne distinguent pas les couleurs, et vous pouvez afficher des alertes visuelles avec des effets sonores pour aider les utilisateurs qui sont malentendants.

Si nécessaire, vous pouvez fournir d’autres éléments d’interface utilisateur accessibles qui suppriment totalement les éléments et les animations non essentiels, et fournir d’autres simplifications pour rationaliser l’expérience utilisateur. L’exemple de code suivant montre comment afficher une instance de l’élément UserControl à la place d’une autre en fonction d’un paramètre utilisateur.


<StackPanel x:Name="LayoutRoot" Background="White">

  <CheckBox x:Name="ShowAccessibleUICheckBox" Click="ShowAccessibleUICheckBox_Click">
    Show Accessible UI
  </CheckBox>

  <UserControl x:Name="ContentBlock">
    <local:ContentPage/>
  </UserControl>

</StackPanel>


private void ShowAccessibleUICheckBox_Click(object sender, RoutedEventArgs e)
{
    if ((sender as CheckBox).IsChecked.Value)
    {
        ContentBlock.Content = new AccessibleContentPage();
    }
    else
    {
        ContentBlock.Content = new ContentPage();
    }
}

Vérification et publication

Pour plus d’informations sur les déclarations d’accessibilité et la publication de votre application, voir Déclaration de votre application comme accessible dans le Windows Store.

  • Applies to Windows Phone

Déclarer l’application comme accessible n’est pertinent que par rapport au Windows Store.

Prise en charge de la technologie d’assistance dans des contrôles personnalisés

Lorsque vous créez un contrôle personnalisé, nous vous recommandons de mettre en œuvre ou de développer également une ou plusieurs sous-classes AutomationPeer pour fournir une prise en charge de l’accessibilité. Dans certains cas, tant que vous utilisez la même classe homologue que celle utilisée par la classe de contrôle de base, la prise en charge de l’automation pour votre classe dérivée est adéquate à un niveau de base. Cependant, nous vous conseillons de tester cette configuration. L’implémentation d’un homologue est toujours recommandée comme meilleure pratique, l’homologue pouvant correctement signaler le nom de la classe de votre nouveau contrôle. Plusieurs étapes sont nécessaires pour implémenter un homologue d’automation personnalisé. Pour plus d’informations, voir Homologues d’automation personnalisés.

prise en charge de la technologie d’assistance dans les applications qui gèrent l’interopérabilité entre XAML et Microsoft DirectX

Par défaut, le contenu DirectX hébergé dans une interface utilisateur XAML (à l’aide de la classe SwapChainPanel ou SurfaceImageSource) n’est pas accessible. L’exemple XAML SwapChainPanel DirectX interop montre comment créer des homologues UI Automation pour le contenu DirectX hébergé. Cette technique permet de rendre le contenu hébergé accessible via UI Automation.

Rubriques associées

Windows.UI.Xaml.Automation
Concevoir des applications pour l’accessibilité
Accessibilité des applications Windows Runtime en JavaScript et HTML
Exemple d’accessibilité XAML

 

 

Afficher:
© 2014 Microsoft