Comment vérifier qu’un bouton possède un nom accessible clair ?

Par l’équipe Limpi. Les faits externes sont distingués des méthodes Limpi et aucune visibilité, position ou citation automatique n’est garantie.

Comprendre nom accessible des boutons

Un bouton doit annoncer une action compréhensible aux personnes qui utilisent un lecteur d’écran ou une autre technologie d’assistance. Le texte visible peut fournir ce nom, mais une icône seule, un contrôle vide ou un assemblage ARIA incohérent peut laisser une action sans intitulé exploitable.

Inspecter le comportement réellement servi

Inventoriez les éléments button, les contrôles ayant un rôle de bouton et les liens qui se comportent réellement comme des actions. Comparez le texte visible, le nom calculé par l’accessibility tree et la fonction déclenchée. Testez aussi les boutons uniquement représentés par une icône.

Distinguer les notions qui se ressemblent

Ne confondez pas le nom accessible avec le rôle ou l’état. « Fermer » décrit l’action, button décrit le type de contrôle, et aria-pressed ou aria-expanded peut communiquer un état. Ajouter aria-label partout n’est pas une règle : un texte natif correct est souvent plus simple.

Identifier les causes les plus probables

Les anomalies viennent souvent d’icônes SVG non accompagnées, de composants dont le texte est masqué de manière incorrecte, de bibliothèques qui écrasent un label, ou d’un aria-label générique réutilisé sur plusieurs actions différentes.

Décider ce qui mérite d’être corrigé en premier

Commencez par les contrôles indispensables : navigation, ouverture de menu, validation, suppression, lecture média, recherche et fermeture de fenêtres. Un bouton dont le nom ne permet pas de prévoir l’action doit être corrigé avant les détails purement visuels.

Corriger à la bonne couche

Privilégiez un libellé visible quand il est utile à tout le monde. Pour une icône dont le sens visuel est évident mais sans texte, fournissez un nom accessible adapté au contexte. Vérifiez que ce nom ne contredit pas le texte visible et ne répète pas inutilement le rôle.

Traiter les cas limites sans automatisme

Un même pictogramme peut changer de sens selon l’écran : une croix peut fermer, retirer ou annuler. Les boutons répétés « Plus » ou « Modifier » doivent parfois intégrer le contexte de l’élément concerné afin que leur liste reste intelligible hors de la mise en page.

Valider la correction sur des cas réels

Parcourez les contrôles au clavier puis inspectez leur nom dans les outils d’accessibilité du navigateur. Confirmez que chaque action importante expose un nom stable, que l’activation reste possible et qu’aucun correctif n’a rendu le texte visible incohérent.

Prévenir la régression dans le temps

Ajoutez au design system des composants bouton avec variantes textuelles et iconiques déjà testées. Lors des revues, contrôlez le nom accessible en même temps que l’événement de clic afin qu’un nouveau style ne réintroduise pas un bouton anonyme.

Clôturer le contrôle sur nom accessible des boutons

Pour clôturer le contrôle « Comment vérifier qu’un bouton possède un nom accessible clair ? », conservez une preuve avant/après : URL ou composant testé, constat initial, origine technique, correction appliquée et résultat de la vérification. Contrôlez aussi les pages liées /site/accessibilite, /site/liens-nom-accessible, /site/verifier-navigation-clavier afin de vérifier que la correction reste cohérente avec le reste du corpus. Le périmètre documentaire reste volontairement borné : Présenter le nom accessible comme l’information exposée aux technologies d’assistance pour identifier l’action. Distinguer texte visible, nom accessible et rôle sans imposer aria-label lorsque le HTML natif suffit. Si le comportement dépend d’un gabarit, d’un CDN, d’un navigateur ou d’un outil tiers, testez au moins un second cas représentatif. Une anomalie ambiguë doit rester en revue plutôt que d’être fermée sur une hypothèse. Attribuez enfin la règle à une source précise — composant, template, serveur, CMS ou configuration — pour pouvoir la retester après une refonte.

Conserver une preuve exploitable dans l’audit

Un contrôle sur nom accessible des boutons est utile seulement si une autre personne peut reproduire le constat. Enregistrez la réponse ou l’état observé, l’outil utilisé, le contexte de test et l’élément exact qui justifie la conclusion. Évitez les captures isolées sans URL, statut ou propriété mesurée. Pour les anomalies répétées, comptez les occurrences par gabarit avant et après correction. Cette trace permet de distinguer une résolution globale d’un exemple corrigé manuellement et évite de rouvrir le même diagnostic sans information nouvelle. Lorsque la documentation officielle est la borne du contrôle, notez également la source utilisée afin de pouvoir réévaluer la règle si elle évolue.

Tester un scénario représentatif

Prenez une barre d’outils qui contient une loupe, une corbeille, un cœur et une croix. Inspectez chaque contrôle dans l’arbre d’accessibilité : la loupe doit annoncer une recherche, la corbeille une suppression, le cœur l’ajout ou le retrait d’un favori selon l’état, et la croix la fermeture du panneau concerné. Vérifiez ensuite la même barre dans une carte répétée vingt fois. Un libellé générique comme « modifier » peut devenir ambigu si le contexte de la carte n’est pas exposé. Comparez le texte visible, le nom calculé, le rôle button et les états aria-pressed ou aria-expanded lorsqu’ils existent. Cette série de tests met en évidence les différences entre une icône décorative, un bouton iconique correctement nommé et un composant dont l’ARIA masque accidentellement un texte déjà suffisant. Gardez un exemple de chaque cas dans le rapport pour que le design system puisse être corrigé à la source. Dans le journal technique, relevez élément button, role=button, aria-label, aria-labelledby, contenu textuel, SVG décoratif, disabled, aria-pressed, aria-expanded, type=submit et événement déclenché. Pour une icône répétée dans une liste, conservez aussi l’identifiant de la carte ou du produit afin de vérifier que le nom calculé reste spécifique hors contexte visuel. Ces détails permettent de différencier un défaut de composant d’un simple choix de rédaction. Ajoutez deux contre-exemples au rapport : un input submit dont la value fournit déjà le libellé, et un bouton avec texte visible correctement exposé qu’un aria-label inutile remplacerait par une formulation moins claire. Cette comparaison montre quand le HTML natif suffit et quand une alternative textuelle est réellement nécessaire. Pour les composants personnalisés, comparez aussi nameFromContent, tabindex=0, Space, Enter, click, keydown, pointerup et état disabled. Une div cliquable sans sémantique, un lien transformé en commande ou un bouton imbriquant une image informative produisent des arbres différents. Le test doit confirmer à la fois nom, rôle, activation et état, pas uniquement la présence d’un attribut ARIA.

Sources officielles

Les règles des moteurs et des fournisseurs de crawlers peuvent évoluer. Les affirmations techniques de cette page sont bornées par les documentations officielles ci-dessous.

• w3c button