Recommandations en matière de conception d’applications accessibles

Applies to Windows and Windows Phone

Lorsque vous concevez votre application, n’oubliez jamais le grand nombre de possibilités, de limites ou de préférences de vos utilisateurs. Suivez ces principes de conception pour vous assurer que votre application est accessible au plus grand nombre d’utilisateurs et pour attirer le plus grand nombre de clients dans le Windows Store.

Pourquoi planifier l’accessibilité ?

Concevoir votre application sans perdre de vue la question de l’accessibilité assure son fonctionnement dans les scénarios suivants.

  • Lecture d’écran : les personnes aveugles ou malvoyantes se font aider de lecteurs d’écran pour créer et conserver un modèle mental de l’interface utilisateur de votre application. Entendre les informations concernant l’interface, notamment le nom des éléments qui la composent, leur permet de comprendre le contenu de l’interface et d’interagir avec votre application.

    Pour prendre en charge la lecture d’écran, votre application doit fournir des informations correctes et en quantité suffisante sur ses éléments d’interface utilisateur, dont le nom, le rôle, la description, l’état et la valeur. Découvrez tout ce qu’il faut savoir sur l’exposition d’informations de base sur les éléments d’interface utilisateur pour HTML ou pour XAML.

    Vous devez également fournir des informations d’accessibilité supplémentaires pour les éléments de l’interface utilisateur présentant du contenu dynamique, par exemple une zone dynamique d’une application Windows Runtime en JavaScript avec HTML. Les informations d’accessibilité supplémentaires permettent aux lecteurs d’écran d’annoncer les modifications du contenu. Pour fournir des informations d’accessibilité pour une zone dynamique en HTML, définissez l’attribut aria-live sur les éléments qui contiennent du contenu dynamique. Pour plus d’informations, voir Rendre les zones dynamiques accessibles. Pour fournir des informations d’accessibilité pour une zone dynamique à l’aide des métaphores ARIA pour du contenu actif en XAML, utilisez la propriété attachée AutomationProperties.LiveSetting.

  • Accessibilité du clavier : le clavier est un complément indispensable de l’utilisation d’un lecteur d’écran. Il est également important pour les utilisateurs qui privilégient le clavier pour interagir avec une application. Une application accessible permet aux utilisateurs d’accéder à tous les éléments interactifs de l’interface uniquement par le biais du clavier, et d’effectuer les actions suivantes :

    • naviguer dans l’application à l’aide des touches de tabulation et de direction ;
    • activer des éléments de l’interface grâce à la barre d’espace et la touche Entrée ;
    • accéder aux commandes et aux contrôles via les raccourcis clavier.

    Le Clavier visuel est disponible sur les systèmes sans clavier physique ou pour les utilisateurs à mobilité réduite qui ne peuvent pas utiliser les terminaux de saisie physique traditionnels.

    Découvrez tout ce qu’il faut savoir sur l’implémentation de l’accessibilité du clavier pour HTML ou pour XAML.

  • Expérience visuelle accessible : pour les utilisateurs malvoyants, le texte doit être affiché avec un contraste très élevé. Ils ont également besoin d’une interface attrayante en mode de contraste élevé, conçue pour passer correctement à l’échelle après modification des paramètres dans le Panneau de configuration Options d’ergonomie. Lorsque des informations sont transmises au moyen de couleurs, les utilisateurs qui ne voient pas les couleurs ont besoin d’alternatives telles que du texte, des formes et des icônes. Découvrez tout ce qu’il faut savoir sur la prise en charge de thèmes à contraste élevé pour HTML ou pour XAML. Ou encore découvrez tout ce qu’il faut savoir sur le respect des exigences permettant de fournir un texte accessible pour HTML ou pour XAML.

Pratiques conseillées et déconseillées

  • Prenez en charge la lecture d’écran en fournissant des informations sur les éléments d’interface utilisateur de votre application, notamment le nom, le rôle, la description, l’état et la valeur.
  • Faites en sorte que les utilisateurs puissent naviguer dans votre application avec les touches de direction et la touche Tab.
  • activer des éléments de l’interface grâce à la barre d’espace et la touche Entrée ;
  • accéder aux commandes et aux contrôles via les raccourcis clavier.
  • Concevez le texte et l’interface utilisateur pour prendre en charge les thèmes à contraste élevé.
  • Assurez-vous que le texte et l’interface utilisateur sont mis à l’échelle correctement quand les paramètres des Options d’ergonomie sont changés.
  • N’utilisez pas la couleur comme seule façon de transmettre des informations. Les utilisateurs qui ne distinguent pas les couleurs ne peuvent pas recevoir des informations qui sont transmises uniquement via la couleur, comme sur un indicateur d’état en couleur. Incluez d’autres signaux visuels, de préférence du texte, pour garantir l’accessibilité des informations.
  • N’utilisez pas d’éléments d’interface utilisateur qui clignotent plus de trois fois par seconde. Les éléments qui clignotent peuvent provoquer des crises chez certaines personnes. Il est conseillé d’éviter d’utiliser des éléments d’interface utilisateur qui clignotent.
  • Ne modifiez pas le contexte utilisateur ou n’activez pas des fonctionnalités automatiquement. Les modifications de contexte ou d’activation doivent se produire uniquement lorsque l’utilisateur entreprend une action directe sur un élément d’interface utilisateur qui a le focus. Les modifications apportées au contexte utilisateur comprennent le changement de focus, l’affichage d’un nouveau contenu et la navigation jusqu’à une autre page. Le fait d’apporter des changements de contexte sans impliquer l’utilisateur peut être désorientant pour les utilisateurs souffrant de handicaps. Les exceptions à cette exigence sont notamment l’affichage de sous-menus, la validation de formulaires, l’affichage de texte d’aide dans un autre contrôle et la modification du contexte en réponse à un événement asynchrone.
  • Évitez de créer des éléments d’interface utilisateur personnalisés si vous pouvez utiliser les contrôles par défaut fournis avec le Windows Runtime ou des contrôles qui ont déjà implémenté la prise en charge de Microsoft UI Automation. Les contrôles Windows Runtime standard sont accessibles par défaut et ne nécessitent généralement que l’ajout de quelques attributs d’accessibilité propres à l’application. L’implémentation de la prise en charge d’AutomationPeer pour un vrai contrôle personnalisé nécessite quant à elle une charge de travail plus importante (voir Homologues d’automation personnalisés).
  • Ne placez pas de texte statique ou d’autres éléments non interactifs dans l’ordre de tabulation (par exemple, en définissant la propriété TabIndex pour un élément non interactif). La présence d’éléments non interactifs dans l’ordre de tabulation est contraire aux consignes d’accessibilité du clavier, car elle diminue l’efficacité de la navigation au clavier pour les utilisateurs. De nombreuses technologies d’assistance utilisent l’ordre de tabulation et la possibilité de mettre le focus sur un élément dans le cadre de leur logique pour présenter l’interface d’une application à l’utilisateur de technologie d’assistance. Les éléments de texte uniquement dans l’ordre de tabulation peuvent dérouter les utilisateurs qui s’attendent à rencontrer uniquement des éléments interactifs dans l’ordre de tabulation (boutons, cases à cocher, champs de saisie de texte, zones de liste déroulante, listes, etc.).
  • Évitez d’utiliser un positionnement absolu pour les éléments d’interface utilisateur (comme dans un élément Canvas), car l’ordre de présentation diffère souvent de l’ordre de déclaration des éléments enfants (qui est l’ordre logique de fait). Dans la mesure du possible, organisez les éléments d’interface utilisateur dans l’ordre du document ou dans l’ordre logique pour vous assurer que les lecteurs d’écran peuvent lire ces éléments dans l’ordre correct. Si l’ordre visible des éléments d’interface utilisateur peut diverger de l’ordre du document ou de l’ordre logique, utilisez des valeurs d’index de tabulation explicites (définissez TabIndex) pour définir l’ordre de lecture correct.
  • N’actualisez pas automatiquement un canevas d’application entier, à moins que cela ne soit absolument nécessaire pour la fonctionnalité de l’application. Si vous devez actualiser automatiquement le contenu d’une page, mettez à jour uniquement certaines zones de la page. Les technologies d’assistance doivent généralement supposer qu’un canevas d’application actualisé est une structure entièrement nouvelle, même si les modifications effectives sont minimes. Le coût pour l’utilisateur de technologie d’assistance est que tout affichage de document ou description de l’application actualisée doit maintenant être recréé et représenté à l’utilisateur.

    Remarque  Si vous actualisez le contenu au sein d’une région, envisagez d’attribuer à la propriété d’accessibilité AccessibilityProperties.LiveSetting de cet élément un paramètre autre que ceux par défaut (Polite ou Assertive). Certaines technologies d’assistance peuvent mapper ce paramètre au concept ARIA (Accessible Rich Internet Applications) des zones dynamiques et ainsi indiquer à l’utilisateur qu’une région de contenu a été modifiée.

    Remarque  Une navigation de page délibérée initiée par l’utilisateur constitue un cas légitime pour l’actualisation de la structure d’application. Mais vous devez vous assurer que l’élément d’interface utilisateur qui initie la navigation est identifié ou nommé correctement afin de bien signaler que son appel aura pour conséquence un changement de contexte et un rechargement de page.

Indications d’utilisation supplémentaires

Rendre vos contrôles HTML personnalisés accessibles

Si vous utilisez un contrôle HTML personnalisé, vous devez fournir toutes les informations d’accessibilité élémentaires pour le contrôle, dont le nom d’accessibilité, le rôle, l’état, la valeur, etc. Vous devez également vous assurer que le contrôle est entièrement accessible via le clavier et que l’interface répond aux exigences de l’accessibilité visuelle.

Supposons que vous incluiez un élément div qui représente un élément interactif personnalisé, c’est-à-dire qui gère l’événement onclick. Vous devez dans ce cas :

  • définir un nom d’accessibilité pour l’élément div ;
  • définir l’attribut role sur le rôle ARIA interactif correspondant, par exemple « button » ;
  • définir l’attribut tabindex de sorte à inclure l’élément dans l’ordre de tabulation ;
  • ajouter les gestionnaires d’événements liés au clavier pour prendre en charge l’activation du clavier, c’est-à-dire l’équivalent d’un gestionnaire d’événements onclick.

Pour en savoir plus sur l’exposition d’éléments d’interface utilisateur HTML personnalisés en matière d’accessibilité, voir Accessible Rich Internet Applications (ARIA).

Remarque  

L’élément HTML5 canvas ne prend pas en charge l’accessibilité. Comme cet élément ne fournit aucun moyen d’exposer les informations d’accessibilité pour son contenu, évitez d’utiliser une canvas, sauf nécessité absolue. Si vous utilisez tout de même une canvas, traitez-la comme un élément d’interface personnalisé.

Rendre vos contrôles XAML personnalisés accessibles

Si vous utilisez un contrôle XAML personnalisé, vous devrez peut-être ajuster certaines informations d’accessibilité élémentaires pour le contrôle, dont le nom d’accessibilité, le rôle, l’état, la valeur, etc. Vous devez également vérifier que le contrôle est entièrement accessible via le clavier et que l’interface utilisateur répond aux exigences de l’accessibilité visuelle. Lorsque vous créez des contrôles personnalisés pour XAML, vous héritez de la prise en charge de UI Automation qui était disponible pour tous les contrôles que vous utilisiez en tant que classe de base pour votre contrôle personnalisé. Cela est parfois suffisant. Selon le degré de personnalisation de votre contrôle, vous souhaitez peut-être créer une classe homologue UI Automation personnalisée qui modifie ou accroît la prise en charge UI Automation par défaut. Cela est rendu possible grâce aux API dans les espaces de noms Windows.UI.Xaml.Automation et Windows.UI.Xaml.Automation.Peers. Pour plus d’informations, voir Homologues d’automation personnalisés.

Prise en charge de l’accessibilité sur la plateforme de développement

La plateforme de développement Windows Runtime prend en charge l’accessibilité à toutes les étapes du cycle du développement :

  • Création : le code généré à partir des modèles d’application Microsoft Visual Studio inclut des informations d’accessibilité.
  • Codage : la plateforme de développement prend en charge l’accessibilité suivante lors du codage.
    • Microsoft IntelliSense dans Visual Studio propose des informations d’accessibilité.
    • Les contrôles de la plateforme Windows 8 intègrent la prise en charge de l’accessibilité. Grâce aux contrôles HTML et de plateforme standard, l’accessibilité peut être prise en charge presque intégralement dans le comportement de plateforme par défaut. Par exemple, le contrôle d’évaluation est entièrement accessible sans autre action, tandis que les contrôles ListView demandent uniquement un nom accessible pour l’élément de liste principal. Tous les autres éléments de prise en charge de l’accessibilité sont intégrés. Pour obtenir la liste des contrôles de plateforme, voir Liste des contrôles (HTML) ou Liste des contrôles (XAML).
    • La documentation du Centre de développement Windows inclut des recommandations d’accessibilité et des exemples d’applications.
  • Test : le Kit de développement logiciel (SDK) Windows inclut des outils de test de l’accessibilité. Découvrez tout ce qu’il faut savoir sur le test de votre application en matière d’accessibilité pour HTML ou pour XAML.
  • Vente : vous pouvez marquer votre application comme étant accessible lorsque vous la publiez dans le Windows Store, ce qui permet aux utilisateurs de découvrir votre application en utilisant le filtre Accessibilité lorsqu’ils parcourent le Windows Store. Découvrez tout ce qu’il faut savoir sur la déclaration de votre application comme étant accessible dans le Windows Store pour HTML ou pour XAML.

Rubriques associées

Pour les développeurs (HTML)
Accessibilité pour les applications Windows Runtime en JavaScript
Test de votre application en matière d’accessibilité
Accessible Rich Internet Applications (ARIA)
Exemple ARIA
Pour les développeurs (XAML)
Accessibilité dans les applications Windows Runtime en C++, C# ou Visual Basic
Test de votre application en matière d’accessibilité
Windows.UI.Xaml.Automation
Exemple d’accessibilité XAML

 

 

Afficher:
© 2014 Microsoft