Une courte checklist engagée pour des boutons web accessibles

Le problème des conseils sur l’accessibilité des boutons

La plupart des recommandations sur l’accessibilité des boutons se répartissent en deux camps : soit il s’agit d’une interprétation des WCAG en 40 pages que personne ne lit, soit d’une suggestion vague consistant à "rendre les boutons accessibles", sans étapes concrètes. Aucune des deux n’aide quand vous devez livrer une fonctionnalité jeudi.

Cette checklist couvre les cinq échecs d’accessibilité des boutons les plus courants que nous voyons en production. Elle ne fera pas de vous un expert WCAG, mais elle permettra de repérer les problèmes qui affectent réellement les utilisateurs.

1. Utiliser l’élément button pour les boutons

Si cela se comporte comme un bouton, ce doit être un élément <button>. Pas un <div> avec onclick, pas un <span> avec role="button", pas un <a> avec href="#" et preventDefault.

L’élément <button> vous donne gratuitement la navigation au clavier, la gestion du focus et les annonces par lecteur d’écran. Lorsque vous utilisez un <div>, vous reconstruisez tout cela à partir de zéro — et vous vous tromperez.

La seule exception : si l’action mène vers une nouvelle page ou modifie l’URL, utilisez un élément <a>. Les liens et les boutons sont sémantiquement différents. Les utilisateurs de lecteurs d’écran naviguent par type d’élément, et ils s’attendent à ce que les boutons exécutent des actions et que les liens permettent de naviguer.

2. Prévoir une cible d’interaction d’au moins 44×44 pixels

WCAG 2.5.5 (Level AAA) exige que les éléments interactifs aient une taille de cible minimale de 44×44 pixels CSS. Il ne s’agit pas de la taille visuelle — il s’agit de la zone cliquable.

Vous pouvez avoir un petit bouton visuel avec un padding suffisant, ou vous pouvez étendre la cible d’interaction avec un pseudo-élément. Ce qui compte, c’est que l’utilisateur n’ait pas à viser précisément.

Les utilisateurs mobiles, les personnes ayant des troubles moteurs et toute personne utilisant un appareil en mouvement manqueront les petites cibles. Un bouton icône de 24×24 pixels peut sembler épuré, mais c’est un échec d’utilisabilité.

3. Fournir des états de focus visibles qui ne se limitent pas aux valeurs par défaut du navigateur

L’anneau de focus par défaut du navigateur vaut mieux que rien, mais il est incohérent selon les navigateurs et souvent invisible sur certains arrière-plans. Vous avez besoin d’un état de focus personnalisé qui fonctionne dans votre design system.

Un bon indicateur de focus a trois qualités :

• Contraste élevé : au moins 3:1 par rapport aux couleurs adjacentes
• Décalage visible : non masqué par la bordure ou l’arrière-plan du bouton lui-même
• Forme cohérente : les utilisateurs doivent le reconnaître comme un indicateur de focus dans toute votre interface

Ne supprimez pas outline: none sans le remplacer par quelque chose de mieux. Et ne rendez pas les états de focus si subtils que vous seul pouvez les voir dans des conditions d’éclairage parfaites.

4. Rédiger des libellés de boutons qui ont du sens hors contexte

Les utilisateurs de lecteurs d’écran naviguent souvent en passant d’un bouton à l’autre. Lorsqu’ils le font, ils entendent une liste de libellés de boutons sans contexte environnant.

Un bouton libellé "En savoir plus" est inutile dans cette liste. Il en va de même pour "Cliquez ici" ou "Envoyer". Le libellé doit décrire l’action : "Télécharger la checklist d’accessibilité", "S’abonner aux mises à jour", "Supprimer ce commentaire".

Si votre design exige un libellé visuel court, utilisez aria-label pour fournir une alternative descriptive. Mais la meilleure solution consiste à écrire des libellés qui fonctionnent pour tout le monde.

Pour les boutons composés uniquement d’une icône, aria-label est obligatoire. Un bouton avec seulement une icône de loupe a besoin de aria-label="Search" ou d’un texte équivalent. L’icône n’est pas accessible aux lecteurs d’écran.

5. Garantir un contraste de couleur suffisant

WCAG 2.1 exige un rapport de contraste d’au moins 4.5:1 pour le texte normal et 3:1 pour le grand texte (18pt ou 14pt en gras). Les libellés de boutons sont généralement du texte normal.

Du texte gris clair sur un bouton blanc échoue. Du bleu pâle sur un arrière-plan bleu clair échoue. Ces combinaisons peuvent sembler sophistiquées, mais elles excluent les utilisateurs ayant une basse vision, un daltonisme, ou toute personne qui regarde l’écran en plein soleil.

Utilisez un vérificateur de contraste pendant la conception, pas après le lancement. Corriger des problèmes de contraste en production coûte cher, car cela nécessite souvent des changements dans le design system.

Si vous travaillez avec des outils de traitement d’images, le traitement côté client peut aider à préserver la confidentialité tout en générant des ressources visuelles accessibles — en particulier lors du test de combinaisons de couleurs ou de la génération d’états d’aperçu.

Ce que cette checklist ne couvre pas

Cette liste est volontairement incomplète. Elle ne couvre pas la sémantique des états désactivés, les états de chargement, la gestion des erreurs, ni les modèles de boutons complexes comme les split buttons ou les déclencheurs de menus déroulants. Ces modèles nécessitent leurs propres recommandations.

Elle ne couvre pas non plus la question plus large de savoir quand utiliser un bouton plutôt que d’autres éléments interactifs. Pour cela, vous devez comprendre le HTML sémantique et l’arbre d’accessibilité — des sujets qui méritent leurs propres articles.

Ce qu’elle couvre, ce sont les gains faciles : les erreurs qui apparaissent dans presque chaque revue de code, qui affectent le plus d’utilisateurs et qui sont les plus faciles à corriger pendant le développement.

Comment intégrer cela à votre workflow

Les checklists d’accessibilité ne fonctionnent que si elles font partie du processus de développement, et non si elles sont ajoutées après coup. Voici comment y parvenir :

En design : ajoutez les états de focus et les annotations de cible d’interaction à vos fichiers de design. Ne laissez pas les développeurs les deviner.

En revue de code : vérifiez la présence d’éléments <button>, de aria-label sur les boutons icônes et du CSS des états de focus. Ces éléments se repèrent rapidement.

En test : parcourez votre interface au clavier avec Tab. Si vous ne pouvez pas atteindre un bouton ou voir où se trouve le focus, vos utilisateurs ne le pourront pas non plus.

En documentation : incluez les exigences d’accessibilité des boutons dans votre bibliothèque de composants. Rendez le bon choix plus facile que le mauvais.

Si vous déboguez des problèmes en production, les outils d’inspection des en-têtes HTTP et des redirections peuvent vous aider à comprendre comment les technologies d’assistance interprètent votre balisage — en particulier lors du dépannage de la gestion du focus après une navigation.

Le coût de l’impasse sur ce travail

Les boutons inaccessibles ne font pas seulement échouer la conformité WCAG — ils cassent des parcours. Un utilisateur qui ne peut pas cliquer sur un bouton d’envoi ne peut pas terminer un formulaire. Un utilisateur qui ne peut pas voir les états de focus ne peut pas naviguer au clavier. Un utilisateur qui ne peut pas distinguer le texte du bouton de l’arrière-plan ne peut pas lire le libellé.

Ce ne sont pas des cas limites. Environ 15 % de la population mondiale présente une forme de handicap, et les limitations temporaires (souris cassée, soleil intense, bébé dans les bras) finissent par concerner tout le monde.

La bonne nouvelle, c’est que l’accessibilité des boutons repose surtout sur des problèmes déjà résolus. Vous n’avez pas besoin d’inventer de nouveaux modèles ni d’attendre le support des navigateurs. Vous devez simplement utiliser correctement la plateforme et tester votre travail.

Points clés

• Utilisez des éléments <button> pour les boutons et des éléments <a> pour la navigation — la différence sémantique compte pour les technologies d’assistance
• Assurez-vous que les cibles d’interaction mesurent au moins 44×44 pixels CSS afin de tenir compte des troubles moteurs et des utilisateurs mobiles
• Fournissez des états de focus visibles, à fort contraste, qui fonctionnent dans tout votre design system
• Rédigez des libellés de boutons qui ont du sens lorsqu’ils sont lus isolément, et utilisez aria-label pour les boutons composés uniquement d’une icône
• Vérifiez le contraste des couleurs pendant la conception, pas après le lancement, afin d’éviter des corrections coûteuses

FAQ

Q: Puis-je utiliser role="button" sur un <div> si j’ajoute des gestionnaires clavier ?

A: Vous le pouvez, mais vous ne devriez pas. Vous devrez gérer manuellement Enter, Space, la gestion du focus et les états désactivés — et vous finirez inévitablement par oublier quelque chose. L’élément <button> fait tout cela correctement par défaut. Utilisez-le.

Q: Qu’en est-il des boutons qui changent d’état, comme un bouton lecture/pause ?

A: Utilisez aria-pressed="true" ou aria-pressed="false" pour indiquer l’état actuel. Le libellé du bouton doit aussi refléter l’action qui se produira au clic ("Pause" pendant la lecture, "Play" en pause), et non l’état actuel. Les utilisateurs de lecteurs d’écran doivent savoir ce que fera le bouton, pas l’état dans lequel se trouve le système.

Q: Les boutons désactivés doivent-ils respecter les exigences de contraste ?

A: WCAG 2.1 exempte les contrôles désactivés des exigences de contraste (1.4.3), mais cela fait débat. Les boutons désactivés à faible contraste sont difficiles à percevoir pour tout le monde. Si vous affichez un bouton désactivé, rendez-le lisible. Mieux encore, masquez-le ou expliquez pourquoi il est désactivé.

Q: Comment tester l’accessibilité des boutons sans lecteur d’écran ?

A: Utilisez votre clavier. Parcourez l’interface avec Tab et vérifiez que vous pouvez atteindre chaque bouton, voir où se trouve le focus et activer les boutons avec Enter ou Space. Cela repère la plupart des problèmes. Pour des tests plus approfondis, utilisez l’inspecteur d’accessibilité dans Chrome ou Firefox DevTools afin de vérifier le rôle et le libellé calculés.

Q: Quelle est la différence entre aria-label et aria-labelledby ?

A: aria-label fournit directement une chaîne de texte. aria-labelledby référence l’ID d’un autre élément dont le contenu textuel devient le libellé. Utilisez aria-labelledby lorsque le texte du libellé existe déjà ailleurs dans le DOM. Utilisez aria-label lorsque vous devez fournir un libellé qui n’est pas visible à l’écran.

Sources

• Web Content Accessibility Guidelines (WCAG) 2.1 — W3C
• Inclusive Components: Toggle Buttons — Heydon Pickering
• The ARIA Button Pattern — W3C ARIA Authoring Practices Guide
• WebAIM: Keyboard Accessibility — WebAIM