Accéder au contenu principalAccéder à la navigationAccéder au pied de page
Page d'accueil IncluddyPage d'accueil Includdy
  • FAQ
  • Blog
  • Contact
Includdy

Rendons le web accessible à tous

Produit

  • Scan automatique
  • Correction guidée
  • Collaboration

Ressources

  • FAQ
  • Blog
  • Glossaire
  • RGAA
  • Plan du site

Légal

  • CGU
  • CGV
  • Mentions légales
  • Politique de confidentialité

© 2026 Includdy. Tous droits réservés.

  1. Accueil
  2. RGAA 4.1.2
  3. Formulaires
  4. 11.9 Intitulé de bouton

Dans chaque formulaire, l’intitulé de chaque bouton est-il pertinent (hors cas particuliers) ?

Un utilisateur de lecteur d’écran navigue entre les champs d’un formulaire en appuyant sur Tab. Quand il arrive sur un bouton dont le nom accessible est « OK » ou « Envoyer » sans contexte, il ne sait pas ce que ce bouton va déclencher. Soumettre quelle commande ? Envoyer quoi à qui ? Un intitulé ambigu, c’est une décision impossible.

Le critère 11.9 impose que chaque bouton de formulaire porte un intitulé pertinent, c’est-à-dire un texte qui décrit sa fonction de manière explicite. Sont concernés : <input type="submit">, <input type="reset">, <input type="image">, <button type="submit">, <button type="reset">, ainsi que tout élément avec role="button". L’intitulé peut venir du contenu textuel de la balise, de l’attribut value, d’un aria-label ou d’un aria-labelledby.

Le test 11.9.2 ajoute une contrainte issue de WCAG 2.5.3 : quand un bouton affiche un texte visible, son nom accessible doit contenir ce texte exact. Si le bouton affiche « Envoyer » mais que son aria-label vaut « Soumettre le formulaire », le nom accessible est pertinent — mais il ne contient pas le mot « Envoyer ». Un utilisateur de commande vocale qui dit « cliquer Envoyer » ne trouve pas le bouton.

Règle simple : si vous enrichissez un intitulé visible avec aria-label, commencez par le texte visible, puis ajoutez le contexte. aria-label="Envoyer le message de contact" sur un bouton qui affiche « Envoyer » est la forme correcte.

2 tests pour vérifier que chaque bouton possède un intitulé explicite

1️⃣ Pertinence de l'intitulé visible et du nom accessible du bouton

  1. Repérez tous les boutons présents dans les formulaires du document : <input type="submit">, <input type="reset">, <input type="image">, <button> (tous types), <input type="button">, éléments avec role="button".
  2. Pour chaque bouton, identifiez son intitulé visible (le texte affiché à l’écran) et son nom accessible (calculé depuis aria-labelledby, aria-label, contenu textuel, attribut value ou title en dernier recours).
  3. Vérifiez que les deux sont pertinents : ils doivent permettre de comprendre la fonction du bouton sans dépendre du contexte visuel environnant.
  4. Un intitulé générique comme « OK », « Valider » seul, ou « Cliquez ici » échoue ce test.
  5. Si tous les boutons ont un intitulé visible et un nom accessible pertinents, le test est validé.

2️⃣ Nom accessible du bouton contenant l'intitulé visible

  1. Repérez tous les boutons présents dans les formulaires du document.
  2. Pour chaque bouton ayant un intitulé visible (texte affiché à l’écran), calculez son nom accessible.
  3. Vérifiez que le nom accessible contient l’intitulé visible en entier — pas un synonyme, le texte exact.
  4. Exemple : bouton affichant « Envoyer » avec aria-label="Envoyer le message" → conforme (contient « Envoyer »). Avec aria-label="Soumettre le formulaire" → non conforme (ne contient pas « Envoyer »).
  5. Si tous les boutons respectent cette condition, le test est validé.

Exemples

❌ Non conforme : Bouton avec intitulé générique

<form action="/inscription">
  <label for="email">Adresse email</label>
  <input type="email" id="email" name="email">
  <button type="submit">OK</button>
</form>

« OK » ne décrit pas la fonction du bouton. Un utilisateur de lecteur d’écran entend « OK, bouton » et doit deviner si cela valide une inscription, envoie un message ou confirme une suppression. Sur une page avec plusieurs formulaires, la confusion est totale.

✅ Conforme : Bouton avec intitulé explicite

<form action="/inscription">
  <label for="email">Adresse email</label>
  <input type="email" id="email" name="email">
  <button type="submit">S’inscrire à la newsletter</button>
</form>

L’intitulé décrit précisément l’action déclenchée. Même hors contexte — par exemple dans la liste des boutons de la page parcourue par un lecteur d’écran — l’utilisateur comprend ce que ce bouton fait. Conforme aux tests 11.9.1 et 11.9.2.

❌ Non conforme : aria-label qui remplace l’intitulé visible par un synonyme

<!-- Intitulé visible : "Envoyer"
     Nom accessible : "Soumettre le formulaire de contact"
     Ne contient pas "Envoyer" → échec test 11.9.2 -->
<button type="submit" aria-label="Soumettre le formulaire de contact">Envoyer</button>

Le nom accessible est pertinent (test 11.9.1 passe), mais « Soumettre le formulaire de contact » ne contient pas le mot « Envoyer ». Un utilisateur de Dragon NaturallySpeaking qui dit « cliquer Envoyer » ne peut pas activer ce bouton — la commande vocale cherche le nom accessible, pas le texte visible.

✅ Conforme : aria-label qui enrichit l’intitulé visible

<!-- Nom accessible : "Envoyer le formulaire de contact"
     Contient l'intitulé visible "Envoyer" → conforme -->
<button type="submit" aria-label="Envoyer le formulaire de contact">Envoyer</button>

Le aria-label commence par « Envoyer » (l’intitulé visible), puis ajoute le contexte nécessaire. L’utilisateur de commande vocale trouve le bouton en disant « Envoyer ». L’utilisateur de lecteur d’écran reçoit le contexte complet. Conforme aux deux tests.

Astuces et pièges

⚠️ « Valider » ou « Envoyer » seul : l’erreur la plus fréquente en audit

Un bouton « Envoyer » peut être accepté sur une page avec un seul formulaire. Mais dès qu’il en existe deux — un formulaire de recherche et un formulaire de contact — deux boutons « Envoyer » rendent la navigation au lecteur d’écran confuse. Préférez « Envoyer le message » et « Lancer la recherche ». C’est légal dans le premier cas, robuste dans les deux.

⚠️ 11.9.1 passe, 11.9.2 échoue : les deux tests sont indépendants

Le test 11.9.2 n’est pas un sous-ensemble de 11.9.1 — c’est une vérification distincte. Un bouton peut avoir un nom accessible pertinent et quand même échouer 11.9.2 si ce nom ne contient pas l’intitulé visible. Piège classique : le développeur ajoute aria-label="Soumettre" sur un bouton qui affiche « Envoyer ». Synonymes acceptables pour un humain, non conformes au RGAA.

💡 Bouton icône seule : le test 11.9.2 ne s’applique pas

Un bouton contenant uniquement un SVG sans texte visible n’a pas d’intitulé visible. Le test 11.9.2 est sans objet. Seul le test 11.9.1 s’applique : le nom accessible doit être pertinent. Ajoutez aria-label sur le bouton et aria-hidden="true" sur le SVG pour que le lecteur d’écran n’essaie pas de vocaliser l’icône. Exemple : <button aria-label="Rechercher dans le catalogue"><svg aria-hidden="true" focusable="false">…</svg></button>.

⚠️ <input type="image"> : c’est l’attribut alt qui fait l’intitulé

Pour <input type="image">, l’attribut alt constitue le nom accessible et joue le rôle d’intitulé visible. Vérifiez que ce alt décrit la fonction du bouton, pas l’image. alt="logo" sur un bouton de validation est non conforme ; alt="Valider la commande" est conforme.

⚠️ « Hors cas particuliers » : quand le contexte suffit

La mention « hors cas particuliers » du critère couvre les situations où le contexte immédiat rend le bouton pertinent — par exemple un bouton « Supprimer » dans un tableau où chaque ligne a son libellé associé via aria-labelledby. Le RGAA accepte cette technique à condition que le nom accessible final soit pertinent. C’est l’exception, pas la règle.

Questions fréquentes

Quels éléments HTML sont concernés par le critère RGAA 11.9 sur les intitulés de bouton ?

Tous les boutons présents dans un formulaire : <input type="submit">, <input type="reset">, <input type="image">, <input type="button">, <button> quel que soit son type, et tout élément portant role="button". Les boutons hors formulaire (actions JavaScript pures) relèvent du critère 7.1.

Quelle différence entre les tests 11.9.1 et 11.9.2 pour vérifier l'intitulé d'un bouton RGAA ?

Le test 11.9.1 vérifie que l’intitulé et le nom accessible sont compréhensibles et non génériques. Le test 11.9.2 vérifie que le nom accessible contient le texte visible, conformément au critère WCAG 2.5.3 « Label in Name ». Un bouton peut réussir 11.9.1 et échouer 11.9.2 : par exemple, un aria-label="Lancer la recherche" est pertinent mais ne contient pas le texte visible « Rechercher ».

Comment vérifier le nom accessible d'un bouton lors d'un audit RGAA ?

Dans les DevTools Chrome ou Firefox, sélectionnez l’élément bouton, ouvrez l’onglet Accessibilité et lisez le champ « Nom ». Vous obtenez le nom accessible calculé par le navigateur sans remonter manuellement la cascade aria-labelledby → aria-label → contenu textuel → value → title. Pour le test 11.9.2, comparez ensuite ce nom avec le texte visible affiché à l’écran.

Comment évaluer la conformité RGAA d'un bouton « Continuer » dans un formulaire multi-étapes ?

C’est discutable. Contrairement aux liens, le RGAA ne définit pas de contexte accepté pour les boutons dans son glossaire, ce qui tend à exiger un intitulé explicite indépendamment du contexte. Une approche pragmatique, détaillée dans l’article Temesis d’Éric Gateau, accepte « Continuer » quand le formulaire multi-étapes fournit un contexte immédiat non ambigu (titre de section, <legend> explicite). En audit strict, préférez « Continuer vers l’étape suivante ».

Comment déterminer si <button type="reset">Réinitialiser</button> respecte le critère RGAA 11.9 ?

Sur le plan de l’intitulé, oui : « Réinitialiser » décrit clairement la fonction. Mais les boutons type="reset" sont une mauvaise pratique UX reconnue depuis des années, car un clic accidentel efface toutes les saisies sans confirmation. Accessibilité et ergonomie s’accordent sur ce point : évitez-les, ou ajoutez une confirmation avant exécution.

Références

RGAA 4.1.2 : Critère 11.9
WCAG 2.1 :2.5.3 (A)4.1.2 (A)H36H91ARIA6ARIA9ARIA14ARIA162.5.3 (A)4.1.2 (A)
Critère suivant11.10 : Contrôle de saisieCritère précédent11.8 : Liste de choix
1.Images
2.Cadres
3.Couleurs
4.Multimédia
5.Tableaux
6.Liens
7.Scripts
8.Éléments obligatoires
9.Structuration de l’information
10.Présentation de l’information
11.Formulaires
11.111.211.311.411.511.611.711.811.911.1011.1111.1211.13
12.Navigation
13.Consultation