Pratiques à éviter pour des applications accessibles (HTML)

Applies to Windows and Windows Phone

Vous cherchez la version C#/VB/C++/XAML de cette rubrique ? Voir Pratiques à éviter pour des applications accessibles (XAML).

Évitez les pratiques suivantes si vous voulez que votre application Windows Runtime en JavaScript soit accessible.

  • Évitez de créer des éléments d’interface utilisateur personnalisés si vous pouvez utiliser les balises HTML standard ou les contrôles inclus avec l’infrastructure Windows Runtime. La création d’un élément d’interface utilisateur personnalisé, généralement à l’aide de la balise div, requiert du travail supplémentaire pour l’accessibilité. Les balises HTML et les contrôles Windows Runtime sont accessibles par défaut, et il vous suffit peut-être de définir le nom accessible d’un contrôle pour le rendre totalement accessible.
  • Ne placez pas de texte statique ou d’autres éléments non interactifs dans l’ordre de tabulation (par exemple, en affectant une valeur supérieure à 0 à l’attribut 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. 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.).
  • N’affectez pas à l’attribut role une valeur arbitraire, car vous ne pourrez pas tirer parti de la prise en charge de l’accessibilité qui est intégrée à la plateforme Windows Runtime. L’affectation d’une valeur de rôle WAI-ARIA (Web Accessibility Initiative - Accessible Rich Internet Applications) valide (non abstraite) à l’attribut role d’un élément est la meilleure façon de permettre à la plateforme de représenter correctement l’élément à des lecteurs d’écran et d’autres outils de technologies d’assistance.
  • Évitez d’utiliser le positionnement absolu CSS (Cascading Style Sheets) personnalisé des éléments d’interface utilisateur. Disposez, autant que possible, les éléments d’interface utilisateur dans l’ordre du document ou dans l’ordre logique pour garantir que les lecteurs d’écran peuvent lire les éléments d’interface utilisateur dans l’ordre approprié. Si l’ordre visible des éléments d’interface utilisateur peut diverger de l’ordre du document ou de l’ordre logique, utilisez les attributs aria-flowto et x-ms-aria-flowfrom pour définir l’ordre de lecture qui convient.
  • N’utilisez pas la couleur comme seule façon de transmettre les informations. Les utilisateurs qui ne distinguent pas les couleurs ne peuvent pas recevoir des informations qui sont transmises uniquement via la couleur, comme un indicateur d’état en couleur. Incluez d’autres signaux visuels, de préférence du texte, pour garantir que les informations sont accessibles.
  • N’actualisez pas automatiquement la totalité d’une page. Si vous n’avez pas besoin d’actualiser automatiquement le contenu d’une page, mettez à jour uniquement certaines zones de la page, et marquez ces zones comme des zones dynamiques.
  • N’utilisez pas des é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.

Rubriques associées

Accessibilité des applications Windows Runtime en JavaScript et HTML

 

 

Afficher:
© 2014 Microsoft