Exigences de texte accessible

Cette rubrique décrit les bonnes pratiques d’accessibilité du texte dans une application, en vérifiant que les couleurs et les arrière-plans répondent au rapport de contraste nécessaire. Cette rubrique décrit également les rôles Microsoft UI Automation que les éléments texte d’une application plateforme Windows universelle (UWP) peuvent avoir et les meilleures pratiques pour le texte dans les graphiques.

Ratios de contraste

Bien que les utilisateurs aient toujours la possibilité de basculer vers un mode à contraste élevé, la conception de votre application pour le texte doit considérer cette option comme un dernier recours. Une bonne pratique consiste à s’assurer que le texte de votre application répond à certaines instructions établies pour le 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 tiennent pas compte de la teinte des couleurs. Par exemple, si vous avez du texte rouge sur un arrière-plan vert, ce texte peut ne pas être lisible pour quelqu’un présentant une déficience de la daltonie. La vérification et la correction du rapport de contraste peuvent empêcher ces types de problèmes d’accessibilité.

Les recommandations relatives au contraste de texte documenté ici sont basées sur une norme d’accessibilité web, G18 : s’assurer qu’un rapport de contraste d’au moins 4,5:1 existe entre le texte (et les images de texte) et l’arrière-plan derrière le texte. Cette aide existe dans la spécification W3C Techniques for WCAG 2.0 .

Pour être considéré comme accessible, le texte visible doit avoir un rapport de contraste de luminosité minimal de 4,5:1 par rapport à l’arrière-plan. Les exceptions incluent des logos et du texte accessoire, tels que du texte qui fait partie d’un composant d’interface utilisateur inactif.

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

Utilisez des outils de contraste de couleur pour vérifier que le rapport de contraste de texte visible est acceptable. Consultez techniques pour WCAG 2.0 G18 (section Ressources) pour les outils qui peuvent tester les ratios de contraste.

Rôles d’élément de texte

Une application UWP peut utiliser ces éléments par défaut (communément appelés éléments de texte ou contrôles textedit) :

• TextBlock : le rôle est Text
• Zone de texte : le rôle est Edit
• RichTextBlock (et classe de dépassement de capacité RichTextBlockOverflow) : le rôle est Text
• RichEditBox : le rôle est Edit

Lorsqu’un contrôle signale un rôle de modification, les technologies d’assistance supposent qu’il existe des moyens pour les utilisateurs de modifier les valeurs. Par conséquent, si vous placez du texte statique dans une zone de texte, vous ne faites pas état du rôle et si vous ne faites donc pas état de la structure de votre application à l’utilisateur d’accessibilité.

Dans les modèles de texte pour XAML, il existe deux éléments principalement utilisés pour le texte statique, TextBlock et RichTextBlock. Aucun de ces éléments n’est une sous-classe Control , et, par conséquent, aucun d’entre eux n’est focusable au clavier ou peut apparaître dans l’ordre de tabulation. Mais cela ne signifie pas que les technologies d’assistance ne peuvent pas ou ne les lisent pas. Les lecteurs d’écran sont généralement conçus pour prendre en charge plusieurs modes de lecture du contenu dans une application, y compris 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 focusables afin que l’ordre de tabulation obtienne l’utilisateur là-bas. Les utilisateurs de la technologie d’assistance s’attendent à ce que tout élément dans l’ordre de tabulation soit interactif, et s’ils rencontrent du texte statique là-bas, c’est plus déroutant que utile. Vous devez tester cela vous-même avec le Narrateur pour avoir un sens de l’expérience utilisateur avec votre application lors de l’utilisation d’un lecteur d’écran pour examiner le texte statique de votre application.

Suggestion automatique de l’accessibilité

Lorsqu’un utilisateur tape dans un champ d’entrée et qu’une liste de suggestions potentielles s’affiche, ce type de scénario est appelé suggestion automatique. Cela est courant dans la ligne À : d’un champ de messagerie, de la zone de recherche Cortana dans Windows, du champ d’entrée d’URL dans Microsoft Edge, du champ d’entrée d’emplacement dans l’application Météo, et ainsi de suite. Si vous utilisez une suggestion automatique XAML ou les contrôles intrinsèques HTML, cette expérience est déjà connectée pour vous par défaut. Pour rendre cette expérience accessible, le champ d’entrée et la liste doit être associée. Cela est expliqué dans la section Implémentation de la suggestion automatique.

Le Narrateur a été mis à jour pour rendre ce type d’expérience accessible avec un mode de suggestions spécial. À un niveau élevé, lorsque le champ de modification et la liste sont correctement connectés à l’utilisateur final :

• Connaître la liste est présente et quand la liste se ferme
• Savoir combien de suggestions sont disponibles
• Connaître l’élément sélectionné, le cas échéant
• Être en mesure de déplacer le focus du Narrateur vers la liste
• Être en mesure de parcourir une suggestion avec tous les autres modes de lecture

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 doit être associée dans l’arborescence UIA. Cette association est effectuée avec la propriété UIA_ControllerForPropertyId dans les applications de bureau ou la propriété ControlledPeers dans les 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 une application de bureau ou l’événement AutomationEvents.SelectionItemPatternOnElementSelected à déclencher dans une application UWP. Chaque fois que la sélection change, lorsque l’utilisateur tape une autre lettre et que les suggestions ont été mises à jour ou lorsqu’un utilisateur navigue dans la liste, l’événement ElementSelected doit être déclenché.

Exemple où il existe 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 d’emplacement de l’application Météo, le Narrateur recherche l’événement de bureau UIA_LayoutInvalidatedEventId ou l’événement LayoutInvalidated UWP à déclencher sur la liste chaque fois que la liste est mise à jour.

Exemple où il n’existe aucune sélection par défaut

Implémentation XAML

Si vous utilisez le code XAML AutosuggestBox par défaut, tout est déjà connecté pour vous. Si vous créez votre propre expérience de suggestion automatique à l’aide d’une zone de texte et d’une liste, vous devez définir la liste en tant qu’AutomationProperties.ControlledPeers sur la zone de texte. Vous devez déclencher l’événement AutomationPropertyChanged pour la propriété ControlledPeers chaque fois que vous ajoutez ou supprimez cette propriété et déclenchez également vos propres événements SelectionItemPatternOnElementSelected ou LayoutInvalidated en fonction de votre type de scénario, qui a été expliqué précédemment dans cet article.

Implémentation HTML

Si vous utilisez les contrôles intrinsèques en HTML, l’implémentation UIA a déjà été mappée pour vous. Voici un exemple d’implémentation déjà connectée pour vous :

<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 configurer vos propres contrôles ARIA, qui sont expliqués 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 incluez dans le fichier source d’image 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 comme équivalent de « texte de remplacement » inclut ce texte ou un résumé de la signification du texte. Des considérations similaires s’appliquent si vous créez des caractères de texte à partir de vecteurs dans le cadre d’un chemin d’accès ou à l’aide de Glyphes.

Taille et échelle de police de texte

Les utilisateurs peuvent avoir des difficultés à lire du texte dans une application lorsque les polices sont simplement trop petites, donc assurez-vous que tout texte de votre application est une taille raisonnable dans la première place.

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

• L’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 rend pas difficile l’utilisation de la loupe pour la lecture.
• Paramètres globaux de mise à l’échelle et de résolution dans Settings-System-Display-Scale>>> et layout. 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 Settings-Ease> of access-Display>. Ajustez le paramètre Rendre le texte plus grand pour spécifier uniquement la taille du texte dans les contrôles de prise en charge de toutes les applications et écrans (tous les contrôles de texte UWP prennent en charge l’expérience de mise à l’échelle du texte sans personnalisation ni création de modèles).

Différents éléments de texte et contrôles ont une propriété IsTextScaleFactorEnabled. Cette propriété a la valeur true par défaut. Lorsque la valeur est true, la taille du texte dans cet élément peut être mise à l’échelle. La mise à l’échelle affecte le texte qui a une petite PoliceSize à un degré supérieur à celui qui a un grand 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 De taille de texte et voyez ce qui se passe pour 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 en tant que texte d’interface utilisateur de mise à l’échelle universelle pour 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 en savoir plus sur les modifications apportées au paramètre De taille de 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 plus petit texte est mis à l’échelle de cette quantité. Vous pouvez peut-être utiliser la valeur pour mettre à l’échelle des graphiques pour qu’ils correspondent au texte. Mais n’oubliez pas que tout le texte n’est pas mis à l’échelle par le même facteur. En règle générale, le texte plus grand doit commencer, moins il est affecté par la mise à l’échelle.

Ces types ont une propriété IsTextScaleFactorEnabled :

• ContentPresenter
• Classes de contrôle et dérivées
• FontIcon
• RichTextBlock
• TextBlock
• TextElement et classes dérivées

Exemples

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.

Rubriques connexes

• Mise à l’échelle du texte
• Accessibilité
• Informations d’accessibilité de base
• Exemple d’affichage de texte XAML
• Exemple de modification de texte XAML
• Exemple d’accessibilité XAML