Intitulé de bouton explicite

Le , par Eric Gateau - Accessibilité

Résumé

Pour déterminer si un intitulé de bouton est explicite lors d’un audit WCAG ou RGAA, Temesis utilise un arbre de décision afin de déterminer la conformité vis à vis des critères concernés.

Contexte : la conformité des intitulés d’éléments interactifs

Pour permettre l’accessibilité des interfaces, il est primordial de fournir des intitulés de boutons explicites aux utilisatrices et aux utilisateurs. En effet, l’objectif est de leur permettre de prévoir ce qu’il va se passer lorsque le bouton en question sera activé.

Pour cela, le bouton possède 2 moyens principaux :

  • un aspect visuel : ce qui est visible sur le bouton lui-même (texte, pictogramme, autres caractéristiques visibles) et son contexte (position à l’écran, etc.)
  • un intitulé accessible (ou nom accessible) : le texte qui est fourni aux technologies d’assistance via le code HTML (texte à l’intérieur du bouton, attributs aria, etc.)

C’est ce second aspect que nous abordons ici et pour lequel nous proposons un arbre de décision.

Problématique : tenir compte du contexte HTML ?

En matière d’intitulé explicite pour les éléments interactifs, il est intéressant de constater que dans WCAG, le contexte HTML d’un lien permet de l’expliciter.

C’est à dire que WCAG, et donc RGAA, autorisent et considèrent comme conforme un lien dont l’intitulé est explicité par son contexte HTML. Voir à ce sujet https://www.w3.org/TR/WCAG21/#link-purpose-in-context (en anglais) et https://accessibilite.numerique.gouv.fr/methode/criteres-et-tests/#6.1

Mais cette possibilité n’existe pas pour les boutons. Par conséquent, il n’est pas possible de s’appuyer sur cela pour l’intitulé d’un bouton.

Ainsi et par exemple l’intitulé du lien dans le code suivant est conforme selon les critères WCAG 2.4.4 et RGAA 6.1 :

<h2>L’accessibilité numérique</h2>
<a href="url-cible.html">En savoir plus</a>

Alors que l’intitulé du bouton (si par exemple il ouvre une fenêtre modale) dans le code suivant n’est pas conforme selon les critères WCAG 2.4.6 et RGAA 7.1 :

<h2>L’accessibilité numérique</h2>
<button type="button">En savoir plus</button>

Ceci étant établi, nous avons remarqué qu’au cours de nos audits, certains intitulés de boutons pourtant un peu “génériques” (exemples : “fermer” ou “suivant”) pouvaient être considérés comme explicites. Ces cas font appel à une notion qui n’est pas décrite dans RGAA ou WCAG : la notion de contexte utilisateur. Cette situation nous a amené à nous interroger et à formaliser la méthodologie pour permettre à un auditeur de prendre une décision.

En pratique : un contexte utilisateur et un arbre de décision

En fait, une personne qui interagit avec un contenu numérique n’est jamais face à un bouton avec comme seule information l’intitulé du bouton. Elle est forcément dans une situation de navigation et d’interaction qui constitue son contexte propre. Ce contexte est défini par l’interaction entre les objectifs de cette personne et par le service proposé par le propriétaire du site ou de l’application. Si bien entendu, nous ne pouvons pas connaître précisément les premiers, le service numérique est quant à lui connu.

Par conséquent, nous définissons et évaluons les intitulés de bouton de la manière suivante :

  1. Bouton explicite : l’intitulé d’un bouton est explicite si je suis dans un contexte utilisateur où je comprend l’action associée au bouton
  2. Bouton non explicite : l’intitulé d’un bouton n’est pas explicite dans les autres cas

Ces affirmations peuvent sembler évidentes, elles n’en constituent pas moins un outil de décision puisqu’à partir de là nous pouvons établir de manière pratique les différents cas.

Dans le cas 1 (intitulé de bouton explicite) nous avons :

  1. les intitulés directement explicites. Exemples : “s’inscrire à la newsletter” ou “afficher la diapositive 2 des actualités”

  2. les intitulés explicités par un contexte utilisateur. Exemples :

    • “Fermer” pour un bouton de fermeture d’une fenêtre modale ouverte par l’utilisateur (puisqu’à l’ouverture de cette fenêtre l’utilisateur est informé du contexte)
    • “S’inscrire” pour une page de formulaire d’inscription (l’utilisateur a, volontairement, entamé un processus d’inscription qu’il a choisi)
    • “Lire la vidéo” si je viens de faire mon choix parmi plusieurs programmes et que j’arrive sur une page dédiée à cette vidéo

Inversement, dans le cas 2 (intitulé de bouton non explicite) nous trouvons :

  1. les cas où il y a doublon d’un même intitulé. Alors il est donc forcément nécessaire de pouvoir distinguer ces intitulés (sauf dans le cas où les actions associées sont identiques)

  2. tous les libellés qui sont dans un contexte inattendu pour l’utilisateur. Exemples :

    • “suivant” et “précédent” sur les boutons de contrôle d’un carrousel car ce composant n’est pas attendu ni identifié avec le seul texte de ces boutons
    • “accepter” dans une bannière de gestion des cookies présentée par défaut car je ne suis pas arrivé sur cette page pour accepter ou refuser quoi que ce soit

En appliquant cette méthode, il est amusant de remarquer par exemple que :

  • suivant/précédent dans un processus de devis est explicite
  • suivant/précédent dans un carrousel n’est pas explicite

Cela renforce également ce que nous savons, à savoir que l’intervention humaine est toujours indispensable dans une démarche d’accessibilité (audit, accompagnement ou formation) puisque l’évaluation du contexte, sur le sujet de cet article mais également sur bien d’autres, est nécessaire.

Voilà donc ce que nous utilisons comme grille d’appréciation d’un libellé de bouton. Cette méthode n’empêche pas de préconiser, au-delà de la conformité à WCAG ou RGAA, des intitulés parfois plus précis. En revanche, elle permet d’aider l’expert accessibilité dans son évaluation.