Exigences de texte accessible

  • Article

Cette rubrique décrit les meilleures pratiques relatives à l’accessibilité du texte dans une application, en garantissant que les couleurs et de l’arrière-plan respectent le coefficient de contraste nécessaire. Elle traite également des rôles Microsoft UI Automation que peuvent avoir les éléments de texte dans une application UWP et des meilleures pratiques relatives au texte des graphiques.

Coefficients de contraste

Bien que les utilisateurs aient toujours la possibilité de basculer en mode de contraste élevé, la conception de votre application en ce qui concerne le texte doit considérer cette option comme un dernier recours. L’idéal consiste à s’assurer que le texte de votre application remplit certains critères établis quant au niveau de contraste entre le texte et son arrière-plan. L’évaluation du niveau de contraste est basée sur des techniques déterministes qui ne prennent pas en compte la teinte. Par exemple, si vous avez du texte rouge sur fond vert, ce texte risque de ne pas être lisible pour quelqu’un souffrant de daltonisme. La vérification et la correction du coefficient de contraste peuvent éliminer ce genre de problème d’accessibilité.

Les recommandations en matière de contraste du texte documentées ici sont basées sur une norme d’accessibilité Web intitulée G18: Ensuring that a contrast ratio of at least 4.5:1 exists between text (and images of text) and background behind the text. Ces conseils se trouvent dans la spécification Techniques W3C pour WCAG 2.0.

Pour être considéré comme accessible, le texte visible doit présenter un coefficient de contraste de luminosité minimal de 4,5 pour 1 par rapport à l’arrière-plan. Les exceptions comprennent les logos et le texte accessoire tel que le texte qui fait partie d’un composant d’interface utilisateur inactif.

Le texte décoratif et qui ne véhicule aucune information est exclu. Par exemple, si des mots aléatoires sont utilisés pour créer un arrière-plan, et que ces mots peuvent être réorganisés ou remplacés sans changer le sens, ils sont considérés comme étant décoratifs et n’ont pas besoin de répondre à ce critère.

Utilisez des outils de contraste des couleurs pour vérifier que le coefficient de contraste du texte visible est acceptable. Pour connaître les outils permettant de tester les coefficients de contraste, voir la spécification Techniques for WCAG 2.0 G18 (section Resources).

Notes

Certains outils répertoriés par la spécification Techniques for WCAG 2.0 G18 ne peuvent pas être utilisés de manière interactive avec une application UWP. Vous pouvez être amené à saisir manuellement des valeurs de couleur de premier plan et d’arrière-plan dans l’outil, ou à effectuer des captures d’écran de l’interface utilisateur de l’application, puis à exécuter l’outil de coefficient de contraste sur l’image de capture d’écran.

Rôles d’éléments de texte

Une application UWP peut utiliser les éléments par défaut suivants (couramment appelés éléments de texte ou contrôles d’édition de texte) :

Lorsqu’un contrôle signale un rôle d’édition, les technologies d’assistance supposent qu’il existe des moyens pour les utilisateurs de modifier les valeurs. Ainsi, si vous placez du texte statique dans un TextBox, vous ne déclarez pas correctement le rôle et, par conséquent, vous ne rapportez pas la structure de votre application à l’utilisateur d’accessibilité.

Dans les modèles de texte pour XAML, deux éléments sont principalement utilisés pour le texte statique : TextBlock et RichTextBlock. Aucune d’entre elles n’est une sous-classe Control et, par conséquent, ni l’une ni l’autre ne sont focus sur le clavier ou peuvent apparaître dans l’ordre de tabulation. Toutefois, cela ne signifie pas que les technologies d’assistance ne peuvent pas ou ne veulent pas les lire. Les lecteurs d’écran sont généralement conçus pour prendre en charge plusieurs modes de lecture du contenu dans une application, notamment un mode de lecture dédié ou des modèles de navigation qui vont au-delà du focus et de l’ordre de tabulation, comme un « curseur virtuel ». Par conséquent, ne placez pas votre texte statique dans des conteneurs pouvant être actifs simplement pour que l’ordre de tabulation y amène l’utilisateur. Les utilisateurs des technologies d’assistance s’attendent à ce que tous les éléments inclus dans l’ordre de tabulation soient interactifs. Par conséquent, le fait d’y rencontrer du texte statique peut s’avérer plus déroutant qu’utile. Nous vous recommandons de tester cette fonction vous-même, via le Narrateur, afin de vous faire une idée de l’expérience utilisateur liée à votre application lorsque vous utilisez le lecteur d’écran pour examiner le texte statique de cette dernière.

Accessibilité de suggestion automatique

Lorsqu’un utilisateur effectue une saisie dans un champ d’entrée et qu’une liste de suggestions potentielles apparaît, il s’agit d’une suggestion automatique. Ce scénario est courant dans le champ À : d’un message, dans la zone de recherche Cortana de Windows, dans le champ d’entrée d’URL de Microsoft Edge, dans le champ d’entrée de situation géographique de l’application Météo, etc. Si vous utilisez la fonction XAML AutosuggestBox ou les commandes intrinsèques HTML, cette expérience est d’ores et déjà raccordée par défaut. Pour la rendre accessible, le champ d’entrée et la liste doivent être associés. Cette procédure est expliquée dans la section Implémentation de la suggestion automatique.

La Narrateur a été mis à jour pour rendre cette expérience accessible avec un mode spécial de suggestions. À un niveau élevé, quand le champ d’entrée et la liste sont associés de manière appropriée, l’utilisateur final :

  • Aura connaissance de la liste et du moment de clôture de cette dernière
  • Aura connaissance du nombre de suggestions disponibles
  • Aura connaissance de l’élément sélectionné, le cas échéant
  • Sera en mesure de déplacer le focus du Narrateur de la liste
  • Sera en mesure de parcourir une suggestion avec l’ensemble des autres modes de lecture

Liste de suggestions
Exemple de liste de suggestions

Implémentation de la suggestion automatique

Pour rendre cette expérience accessible, le champ d’entrée et la liste doivent être associés dans l’arborescence UIA. Cette association est effectuée avec la propriété UIA_ControllerForPropertyId des applications de bureau ou la propriété ControlledPeers des applications UWP.

À un niveau élevé, il existe 2 types d’expériences de suggestion automatique.

Sélection par défaut
Si une sélection par défaut est effectuée dans la liste, le Narrateur recherche un événement UIA_SelectionItem_ElementSelectedEventId dans l’application de bureau, ou l’événement AutomationEvents.SelectionItemPatternOnElementSelected à déclencher dans une application UWP. Chaque fois que la sélection est modifiée, quand un utilisateur saisit une autre lettre et que les suggestions ont été mises à jour et quand un utilisateur parcourt la liste, l’événement ElementSelected doit être déclenché.

Liste avec une sélection par défaut
Exemple avec une sélection par défaut

Aucune sélection par défaut
S’il n’existe aucune sélection par défaut, par exemple dans la zone emplacement de l’application Météo, le Narrateur recherche l’événement de UIA_LayoutInvalidatedEventId bureau ou l’événement UWP LayoutInvalidated à déclencher dans la liste chaque fois que la liste est mise à jour.

Liste sans sélection par défaut
Exemple sans sélection par défaut

Implémentation XAML

Si vous utilisez la fonction XAML par défaut AutosuggestBox, l’ensemble des connexions sont déjà effectuées. Si vous développez votre propre expérience de suggestion automatique à l’aide d’un élément TextBox et d’une liste, vous devrez définir la liste en tant que AutomationProperties.ControlledPeers sur l’élément TextBox. Vous devez déclencher l’événement AutomationPropertyChanged de la propriété ControlledPeers chaque fois que vous ajoutez ou supprimez cette propriété, mais également déclencher vos propres événements SelectionItemPatternOnElementSelected ou LayoutInvalidated en fonction de votre type de scénario, tel qu’expliqué plus haut dans cet article.

Implémentation HTML

Si vous utilisez les contrôles intrinsèques du format HTML, l’implémentation UIA a d’ores et déjà été mappée. Vous trouverez ci-dessous un exemple d’une implémentation déjà connectée :

<label>Sites <input id="input1" type="text" list="datalist1" /></label>
<datalist id="datalist1">
        <option value="http://www.google.com/" label="Google"></option>
        <option value="http://www.reddit.com/" label="Reddit"></option>
</datalist>

Si vous créez vos propres contrôles, vous devez définir vos propres contrôles ARIA, décrits dans les normes W3C.

Texte dans les graphiques

Dans la mesure du possible, évitez d’inclure du texte dans un graphique. Par exemple, tout texte que vous placez dans le fichier source d’image et qui est affiché dans l’application en tant qu’élément Image n’est pas automatiquement accessible ou lisible par les technologies d’assistance. Si vous devez utiliser du texte dans des graphiques, assurez-vous que la valeur AutomationProperties.Name que vous fournissez en tant qu’équivalent de « texte de remplacement » inclut ce texte ou un résumé de la signification du texte. Des considérations semblables s’appliquent si vous créez des caractères texte à partir de vecteurs dans le cadre d’un objet Path ou à l’aide de Glyphs.

Taille et mise à l’échelle de la police du texte

Les utilisateurs peuvent avoir des difficultés à lire du texte dans une application lorsque les polices sont tout simplement trop petites. Assurez-vous donc que tout texte de votre application est d’une taille raisonnable.

Une fois que vous avez fait l’évidence, Windows inclut divers outils et paramètres d’accessibilité dont les utilisateurs peuvent tirer parti et s’adapter à leurs propres besoins et préférences de lecture de texte. Il s’agit notamment des paramètres suivants :

  • Outil Loupe, qui agrandit une zone sélectionnée de l’interface utilisateur. Vous devez vous assurer que la disposition du texte dans votre application ne complique pas l’utilisation de la Loupe pour la lecture.
  • Paramètres de mise à l’échelle et de résolution globaux dans Paramètres-Système-Affichage-Échelle>>> et disposition. Les options de dimensionnement disponibles peuvent varier, car cela dépend des fonctionnalités de l’appareil d’affichage.
  • Paramètres de taille de texte dans Paramètres-Options> d’ergonomie-Affichage>. Ajustez le paramètre Agrandir le texte pour spécifier uniquement la taille du texte dans les contrôles de prise en charge sur l’ensemble des applications et des écrans (tous les contrôles de texte UWP prennent en charge l’expérience de mise à l’échelle du texte sans aucune personnalisation ni création de modèles).

Notes

Le paramètre Tout agrandir permet à un utilisateur de spécifier sa taille préférée pour le texte et les applications en général sur son écran principal uniquement.

Les différents contrôles et éléments de texte ont une propriété IsTextScaleFactorEnabled. La valeur par défaut de cette propriété est true. Lorsque la valeur est true, la taille du texte de cet élément peut être mise à l’échelle. La mise à l’échelle affecte le texte qui a une petite FontSize à un degré supérieur à celui du texte qui a une grande FontSize. Vous pouvez désactiver le redimensionnement automatique en définissant la propriété IsTextScaleFactorEnabled d’un élément sur false.

Pour plus d’informations, consultez Mise à l’échelle du texte .

Ajoutez le balisage suivant à une application et exécutez-la. Ajustez le paramètre Taille du texte et voyez ce qu’il advient de chaque TextBlock.

XAML

<TextBlock Text="In this case, IsTextScaleFactorEnabled has been left set to its default value of true."
    Style="{StaticResource BodyTextBlockStyle}"/>

<TextBlock Text="In this case, IsTextScaleFactorEnabled has been set to false."
    Style="{StaticResource BodyTextBlockStyle}" IsTextScaleFactorEnabled="False"/>

Nous vous déconseillons de désactiver la mise à l’échelle du texte, car la mise à l’échelle universelle du texte de l’interface utilisateur sur toutes les applications est une expérience d’accessibilité importante pour les utilisateurs.

Vous pouvez également utiliser l’événement TextScaleFactorChanged et la propriété TextScaleFactor pour évaluer les incidences sur le paramètre Taille du texte sur le téléphone. Voici comment procéder :

C#

{
    ...
    var uiSettings = new Windows.UI.ViewManagement.UISettings();
    uiSettings.TextScaleFactorChanged += UISettings_TextScaleFactorChanged;
    ...
}

private async void UISettings_TextScaleFactorChanged(Windows.UI.ViewManagement.UISettings sender, object args)
{
    var messageDialog = new Windows.UI.Popups.MessageDialog(string.Format("It's now {0}", sender.TextScaleFactor), "The text scale factor has changed");
    await messageDialog.ShowAsync();
}

La valeur de TextScaleFactor est un double dans la plage [1,2.25]. Le texte le plus petit subit un agrandissement de cette ampleur. Vous pouvez par exemple utiliser la valeur pour adapter des éléments graphiques au texte. Gardez toutefois à l’esprit que tout le texte n’est pas mis à l’échelle selon le même facteur. En règle générale, plus la taille du texte initial est élevée, moins le texte est affecté par la mise à l’échelle.

Les types suivants possèdent une propriété IsTextScaleFactorEnabled :

Exemples

Conseil

Ouvrez l’application Galerie WinUI 3 et consultez la prise en charge de l’accessibilité du texte en action.

L’application WinUI 3 Gallery comprend des exemples interactifs de la plupart des contrôles et des fonctionnalités WinUI 3. Procurez-vous l’application sur le Microsoft Store ou le code source sur GitHub.