Étiquette en tête
Découvrez comment nous utilisons l'intelligence artificielle pour cette règle !
Ce que nous vérifions
Si un élément interactif possède une étiquette visible, celle-ci doit apparaître au début du nom annoncé par les technologies d'assistance (TA), avant toute information supplémentaire.
Exemple d'échec ❌
Le bouton name est "Connexion au compte"
TalkBack annonce "Connexion au compte, bouton" —-l'étiquette visible "Se connecter" n'est pas en début
Voice Access - L'utilisateur dit "Se connecter"
Cela peut ne pas activer le bouton car le nom commence par "Compte", et non "Se connecter"
Exemple réussi ✅
Le bouton name est "Se connecter au compte"
TalkBack annonce "Se connecter au compte, bouton" - l'étiquette visible "Se connecter" vient en premier
Voice Access - L'utilisateur dit "Se connecter"
Cela active le bouton car le nom commence par l'étiquette visible
Résumé
- Cette règle a un impact mineur pour les utilisateurs, appliquant une meilleure pratique WCAG
- Texte visible en premier : Commencez toujours le nom d'un élément par ce que les utilisateurs voyants perçoivent à l'écran
- Contexte en second : Ajoutez des informations utiles au nom de l'élément après le texte visible
Impact pour les utilisateurs
Les personnes utilisant des technologies d'assistance doivent rapidement comprendre ce qu'un élément fait et pouvoir interagir facilement avec lui. Quand des mots supplémentaires précèdent le nom accessible, cela ralentit la navigation et rend votre application moins efficace pour les utilisateurs de TA.
- Talkback - Certains utilisateurs basculent entre les modalités — utilisant à la fois un lecteur d'écran et une entrée vocale. La cohérence de placer le texte visible au début du nom réduit la confusion lorsqu'il s'agit de comparer ce qu'un utilisateur voyant peut percevoir par rapport à ce qui est annoncé par Talkback.
- Accès vocal - Les moteurs de reconnaissance vocale se fient souvent au début d'un nom accessible pour déterminer quel élément l'utilisateur cible. Mettre l'étiquette visible au début du nom accessible rend la correspondance sans ambiguïté et réduit la possibilité qu'un utilisateur ne puisse pas activer un élément. Une meilleure pratique que nous recommandons est d'avoir uniquement le texte visible de l'élément dans le nom, et de mettre les informations secondaires dans la valeur accessible, l'indice ou le rôle.
Remarque : Selon le langage de programmation, la propriété 'nom' d'un élément peut être appelée différemment. Pour XML ou Compose, elle est appelée description de contenu. Pour React Native, elle est appelée étiquette d'accessibilité.
Confirmer le problème de l'étiquette en tête
- Activez TalkBack
- Concentrez-vous sur l'élément
- L'un des cas suivants se produira :
- Inaccessible : Le texte d'abord annoncé par TalkBack est différent du texte visible de l'élément
- Accessible : TalkBack annoncera d'abord le texte visible de l'élément
Corriger les problèmes
Pour résoudre les problèmes d'étiquette en tête, faites correspondre exactement le contenu textuel et le nom accessible autant que possible. Évitez l'utilisation de mots superflus tels que "Cliquez ici pour..." ou "Appuyez pour...", et nommez l'élément d'une manière qui indique explicitement à l'utilisateur son action.
Parfois, il est nécessaire d'étendre le nom accessible d'un élément pour inclure plus de contexte. Par exemple :
- Étiquette visible : « Boîte de réception, 5 », Nom : « Boîte de réception, 5 messages non lus »
- Étiquette visible : « Supprimer », Nom : « Supprimer le profil utilisateur »
Pour éviter les problèmes d'étiquette en tête dans des cas comme ceux-ci, assurez-vous que le texte visible de l'élément apparaît premier dans son nom accessible.
XML
Pour un bouton avec un texte visible qui dit "Envoyer" :
<Button
android:id="@+id/email_button"
android:layout_width="wrap_content"
android:layout_height="wrap_content"
android:layout_marginTop="@dimen/xlg"
android:text="Send"
app:layout_constraintStart_toStartOf="parent"
app:layout_constraintEnd_toEndOf="parent"
app:layout_constraintTop_toBottomOf="@id/divider2" />Le texte visible pour le bouton vient en premier dans sa description de contenu, et des informations supplémentaires suivent.
val button = findViewById<Button>(R.id.email_button)
button.contentDescription = "Send Email"Compose
Pour un élément de texte cliquable avec un texte visible qui dit "Envoyer", le texte visible pour le bouton vient en premier dans son contentDescription, et des informations supplémentaires suivent.
Text(modifier = Modifier.semantics { contentDescription = "Send Email" }, text = "Send")React Native
La propriété accessibilityLabel doit commencer par le texte visible de l'élément.
Par défaut, un bouton utilisera son titre comme accessibilityLabel, et cela passera donc cette règle.
<Button
title={'Menu'}
mode='contained'
accessibilityLabel='Menu'
/>Si vous choisissez de personnaliser le accessibilityLabel pour un bouton, assurez-vous qu'il commence par le texte de title.
<Button
title={'Log In'}
mode='contained'
accessibilityLabel='Log In to Transfer Money'
/>Lorsque vous définissez le accessibilityLabel explicitement, assurez-vous que le accessibilityLabel commence par le texte visible de l'élément.
<View style={styles.container}>
<Button title='Menu' accessibilityLabel='Menu: Tap to expand/collapse'>
</View>Puis-je ignorer cette règle ?
La règle de l’étiquette au début impose une bonne pratique notée par WCAG dans le cadre de WCAG 2.1 2.5.3 A. Cette règle a un impact mineur et peut être ignorée si vous souhaitez prioriser des problèmes plus sérieux. Vous pouvez désactiver les règles catégorisées comme « Bonnes pratiques » depuis le tableau de bord mobile, ou bien en ignorer la règle dans les tests écrits pour Android.
Questions fréquemment posées
Y a-t-il des limitations connues avec cette règle ?
Oui. Une défaillance de la règle peut survenir lorsque le texte visible d'un élément interactif contient une abréviation (par exemple, « Go », « km ») ou un identifiant obscurci / tronqué, et que l'annonce d'accessibilité consiste en les mots représentés (par exemple, « gigaoctets », « kilomètres »), même si c'est le modèle recommandé pour rendre le contenu abrégé ou tronqué accessible aux lecteurs d'écran.
Ressources
- Règles pour l'accessibilité des contenus Web (WCAG) 2.1, Recommandation W3C
- Documents de compréhension de WCAG 2.1