Partager via

Exposer les informations d’accessibilité de base

Les principes fondamentaux de l’accessibilité correspondent au nom, au rôle et à la valeur. Cette rubrique montre comment exposer ces propriétés dans votre application afin que les technologies d’assistance puissent interpréter correctement votre interface utilisateur.

Nom accessible

Un nom accessible est l’étiquette qu’un lecteur d’écran annonce pour un élément d’interface utilisateur. Définissez-le sur des éléments qui transmettent une signification ou prennent en charge l’interaction, notamment les images, les champs d’entrée, les boutons, les contrôles et les régions.

Le tableau suivant décrit comment définir ou obtenir un nom accessible pour différents types d’éléments dans une interface utilisateur XAML.

Type d’élément Descriptif
Texte statique Pour les éléments TextBlock et RichTextBlock, un nom accessible est automatiquement déterminé à partir du texte visible (interne). Tout le texte de cet élément est utilisé comme nom. Voir Nom dans le texte interne.
Images L'élément Image de XAML n'a pas d'analogue direct à l'attribut alt de HTML des img et des éléments similaires. Utilisez AutomationProperties.Name pour fournir un nom ou utiliser la technique de sous-titrage. Consultez les noms accessibles pour les images.
Éléments du formulaire Le nom accessible d’un élément de formulaire doit être identique à l’étiquette affichée pour cet élément. Consultez étiquettes et labeledBy.
Boutons et liens Par défaut, le nom accessible d’un bouton ou d’un lien est basé sur le texte visible, en utilisant les mêmes règles que celles décrites dans Nom à partir du texte interne. Dans les cas où un bouton contient uniquement une image, utilisez AutomationProperties.Name pour fournir un équivalent texte uniquement de l’action prévue du bouton.

La plupart des éléments de conteneur (tels que les panneaux) n’exposent pas de nom accessible. Dans l'automatisation d'interface utilisateur, les éléments enfants significatifs doivent fournir le nom et le rôle, tandis que le conteneur expose principalement la structure de parcours.

Rôle et valeur

Les contrôles XAML exposent le rôle (et, le cas échéant, la valeur) via leur prise en charge intégrée d’UI Automation. Inspectez ces propriétés avec les outils UI Automation ou dans la documentation AutomationPeer de chaque contrôle. Les rôles sont mappés à AutomationControlType et sont exposés aux technologies d’assistance via AutomationPeer du contrôle.

Seuls les contrôles avec sémantique de valeur exposent une valeur UI Automation. Par exemple, TextBox prend en charge IValueProvider via TextBoxAutomationPeer, afin que les technologies d’assistance puissent détecter et lire sa valeur actuelle.

Remarque

Si vous définissez AutomationProperties.Name explicitement, ne répétez pas les termes de rôle/type tels que « button » ou « list » dans le nom. Role/type provient de LocalizedControlType, et de nombreuses technologies d’assistance l’ajoutent au nom. Le texte de rôle répétitif peut produire une sortie telle que « bouton bouton ». Validez ce comportement avec le Narrateur.

Influer sur les vues d’arborescence de l’UI Automation

UI Automation représente les relations d’élément dans trois arborescences : raw, control et content. Chaque vue a un but différent. La vue brute comprend presque tous les éléments d’automatisation, la vue de contrôle met l’accent sur les contrôles interactifs et les points de navigation structurels, et la vue de contenu se concentre sur les éléments qui communiquent du contenu accessible à l’utilisateur. En pratique, les technologies d’assistance et les outils d’inspection de l’accessibilité s’appuient le plus souvent sur la vue de contrôle, car elles fournissent l’équilibre le plus utile entre l’exhaustivité et la facilité d’utilisation.

Par défaut, la plupart des éléments dérivés de Control apparaissent dans la vue de contrôle lorsque votre application est exposée via l'automatisation de l'interface utilisateur. Dans les interfaces utilisateur composées, cela peut introduire des nœuds dupliqués ou à faible valeur qui ajoutent du bruit pour les utilisateurs de technologies d’assistance. Utilisez AutomationProperties.AccessibilityView pour contrôler la façon dont des éléments spécifiques sont exposés dans les vues d’arborescence. Par exemple, le placement d’un élément dans Raw le maintient généralement disponible pour les scénarios de diagnostic et de traversée tout en l’excluant des vues principales utilisées par de nombreuses technologies d’assistance. Pour passer en revue les modèles réels, inspectez les modèles de contrôle dans generic.xaml et recherchez AutomationProperties.AccessibilityView.

Nom extrait du texte interne

De nombreux contrôles XAML peuvent dériver un nom accessible par défaut à partir du texte déjà visible dans l’interface utilisateur. Ce comportement réduit la nécessité de définir AutomationProperties.Name explicitement pour les modèles textuels courants et permet de garder ce que les utilisateurs entendent alignés sur ce qu’ils voient.

  • TextBlock, RichTextBlock et TextBox favorisent généralement leur contenu texte comme nom accessible par défaut.
  • Les sous-classes ContentControl évaluent leur valeur de contenu et utilisent une stratégie itérative « ToString » pour extraire le contenu de chaîne pour le nom accessible par défaut.

Remarque

UI Automation applique un maximum de 2048 caractères pour le nom accessible. Si la génération automatique de noms produit une chaîne plus longue, la valeur est tronquée.

Noms accessibles pour les images

Pour le contenu non texte tel que les images et les graphiques, fournissez une alternative de texte pour permettre aux lecteurs d’écran d’identifier et d’annoncer correctement l’élément. Étant donné que ces éléments n’exposent généralement pas de texte interne, UI Automation ne peut pas dériver automatiquement un nom accessible par défaut. (Les visuels purement décoratifs ou structurels sont une exception et ne doivent généralement pas être nommés.) Lorsqu’une image significative doit être annoncée, définissez AutomationProperties.Name explicitement, comme illustré dans l’exemple suivant.

<Image
    Source="Assets/product.png"
    AutomationProperties.Name="Customer using the product" />

En guise d’alternative, exposez une légende visible et associez-la à l’image via AutomationProperties.LabeledBy. Ainsi, l'étiquette vocale est alignée sur le texte affiché à l'écran et évite de dupliquer des chaînes dans le code. L’exemple WinUI suivant montre ce modèle :

<StackPanel Spacing="8">
    <Image
        x:Name="heroImage"
        Width="480"
        Source="Assets/snoqualmie-NF.jpg"
        AutomationProperties.LabeledBy="{Binding ElementName=heroCaption}" />
    <TextBlock x:Name="heroCaption" Text="Mount Snoqualmie Skiing" />
</StackPanel>

Étiquettes et LabeledBy

Pour les champs de formulaire, le modèle d’étiquetage préféré consiste à définir du texte d’étiquette visible dans un TextBlock et à référencer cet élément du contrôle d’entrée via AutomationProperties.LabeledBy. Cela crée une association entre l’étiquette de l’interface utilisateur et le contrôle dans l’arborescence d’automatisation, afin que les technologies d’assistance puissent annoncer un nom de champ qui correspond à ce qui s’affiche à l’écran. Ce modèle est généralement plus facile à gérer que de dupliquer le texte d’étiquette dans plusieurs propriétés, car la même chaîne source alimente à la fois l'étiquetage visuel et l'étiquetage accessible.

<StackPanel x:Name="LayoutRoot" Spacing="12">
    <StackPanel Orientation="Horizontal" Spacing="8">
        <TextBlock x:Name="firstNameLabel" Text="First name" />
        <TextBox
            x:Name="firstNameTextBox"
            Width="180"
            AutomationProperties.LabeledBy="{Binding ElementName=firstNameLabel}" />
    </StackPanel>

    <StackPanel Orientation="Horizontal" Spacing="8">
        <TextBlock x:Name="lastNameLabel" Text="Last name" />
        <TextBox
            x:Name="lastNameTextBox"
            Width="180"
            AutomationProperties.LabeledBy="{Binding ElementName=lastNameLabel}" />
    </StackPanel>
</StackPanel>

Description accessible (facultatif)

Une description accessible fournit des informations supplémentaires sur un élément d’interface utilisateur lorsque le nom accessible seul n’est pas suffisant. Utilisez-le pour ajouter un contexte de clarification, tel que l’intention, les indicateurs d’utilisation ou des détails de comportement importants qui aident les utilisateurs de la technologie d’assistance à comprendre comment utiliser le contrôle.

Dans le Narrateur, la description est généralement lue à la demande plutôt que dans le cadre de l’annonce par défaut. Les utilisateurs peuvent demander ce détail supplémentaire en appuyant sur CapsLock+F.

Traitez le nom accessible comme identificateur principal du contrôle et conservez-le concis. Lorsque d’autres explications sont requises, fournissez ces détails supplémentaires via AutomationProperties.HelpText en plus de AutomationProperties.Name.

Tester l’accessibilité tôt et souvent

La méthode la plus fiable pour valider la prise en charge du lecteur d’écran consiste à tester votre application directement avec un lecteur d’écran pendant le développement, non seulement au moment de la publication. Les tests précoces et répétés vous permettent d’identifier les noms accessibles manquants ou trompeurs, l’exposition incorrecte aux contrôles et les problèmes de navigation, tandis que les modifications sont toujours peu coûteuses à corriger. Après chaque passage, affinez votre structure d’interface utilisateur et vos propriétés UI Automation en fonction de ce que les utilisateurs entendent et comment ils passent par l’interface. Pour plus d’informations, consultez Tests d’accessibilité.

AccScope est un outil utile pour ce flux de travail, car il visualise votre interface utilisateur en tant qu’arborescence d’automatisation, ce qui facilite l’inspection des technologies d’assistance qui peuvent être découvertes. Sa vue centrée sur le Narrateur vous permet de vérifier la source du texte et la façon dont les éléments sont regroupés et ordonnés pour la sortie parlée. Utilisez-le tout au long du cycle de vie du produit, y compris la conception anticipée et la validation de modèle de contrôle, pour détecter les problèmes d’accessibilité structurelle avant qu’ils apparaissent dans les tests utilisateur. Pour plus d’informations, consultez AccScope.

Noms accessibles à partir de données dynamiques

De nombreux contrôles Windows restituent du contenu via la liaison de données, ce qui signifie que les noms accessibles sont souvent déterminés à partir des données d’exécution plutôt que du code XAML statique. Lorsque les modèles de liste ou d’élément sont renseignés dynamiquement, vérifiez que chaque élément généré expose un nom accessible explicite une fois la liaison terminée. Selon la composition du contrôle et du modèle, vous devrez peut-être définir ou mettre à jour les propriétés d’accessibilité par programmation afin que l’arborescence Automation reflète l’état rendu final. Pour obtenir un exemple de bout en bout, consultez « Scénario 4 » dans l’exemple d’accessibilité XAML (exemple hérité archivé).

Noms et localisation accessibles

Les noms accessibles doivent être localisés avec la même rigueur que le texte visible de l’interface utilisateur. Stockez les chaînes d’étiquettes dans les ressources de localisation et connectez-les via des mappages de directive x :Uid afin que la sortie parlée corresponde à la langue de l’utilisateur. Si vous définissez AutomationProperties.Name explicitement, assurez-vous que cette valeur provient également des ressources localisées plutôt que du texte codé en dur.

Les propriétés jointes dans AutomationProperties utilisent une syntaxe de clé de ressource qualifiée afin que la localisation puisse cibler la propriété jointe sur un élément spécifique. Par exemple, si l’élément est nommé MediumButton, la clé de ressource pour AutomationProperties.Name est MediumButton.[using:Microsoft.UI.Xaml.Automation]AutomationProperties.Name.

  • Last updated on