Liens et boutons accessibles : libellés explicites et boutons icône
En bref — un bouton qui dit ce qu'il fait
Les liens et les boutons sont les commandes de votre boutique : « Ajouter au panier », « Voir le produit », l'icône panier, l'icône recherche, la croix de fermeture. Une personne qui navigue au clavier ou au lecteur d'écran doit pouvoir comprendre ce que chaque commande fait sans le contexte visuel. L'European Accessibility Act (norme EN 301 549 / WCAG 2.1 AA) l'exige depuis le 28 juin 2025. Les points clés :
- Des libellés explicites — jamais « Cliquez ici » ou « En savoir plus » seul (critère 2.4.4) ;
- Le bon élément —
<a>pour naviguer,<button>pour agir, jamais une<div>cliquable (critère 4.1.2) ; - Un nom accessible pour les boutons icône (panier, recherche, fermer) (critères 4.1.2 et 1.1.1) ;
- Le texte visible fait partie du nom — indispensable pour la commande vocale (critère 2.5.3) ;
- Des états et un focus visibles — sélectionné, déplié, désactivé (critères 4.1.2 et 2.4.7) ;
- Des liens repérables sans la couleur seule dans le texte (critère 1.4.1).
Bonne nouvelle : tout se joue dans le HTML et quelques attributs. Aucune refonte graphique n'est nécessaire.
« Ajouter au panier », « Cliquez ici », une loupe sans texte, une croix pour fermer la fenêtre : les liens et boutons sont les points d'action d'un site marchand, et aussi l'un des endroits où l'accessibilité déraille le plus souvent. Un libellé vague, une <div> bricolée en bouton ou une icône sans nom rendent l'achat impossible pour qui n'utilise pas la souris. Voici les six règles WCAG que l'EAA impose pour vos liens et boutons, illustrées sur des cas e-commerce concrets, et comment les vérifier.
Pourquoi les liens et boutons sont si critiques
Une personne aveugle peut demander à son lecteur d'écran la liste de tous les liens ou de tous les boutons d'une page pour se déplacer vite. Si dix liens s'appellent tous « En savoir plus » et trois boutons « Cliquez ici », cette liste est inutilisable : rien ne distingue « En savoir plus » sur un tee-shirt de « En savoir plus » sur la politique de retour. De même, un bouton qui n'est en réalité qu'une <div> stylée n'apparaît ni dans cette liste, ni au clavier : il n'existe tout simplement pas pour la technologie d'assistance.
L'EAA ne crée pas de règle « bouton » distincte : la référence reste l'EN 301 549, fondée sur les WCAG 2.1 niveau AA, applicables au commerce électronique depuis le 28 juin 2025. Les liens et boutons relèvent surtout des critères 2.4.4 (Fonction du lien) et 4.1.2 (Nom, rôle, valeur) : chaque commande doit avoir un nom compréhensible, un rôle correct, et exposer son état.
Les 6 règles des liens et boutons accessibles
Le texte du lien dit où il mène — seul
Le libellé d'un lien ou d'un bouton doit indiquer sa destination ou son action hors de tout contexte visuel. « Cliquez ici », « En savoir plus », « Lire la suite » ou « >> » seuls ne disent rien quand on les écoute en liste. Préférez « Voir la fiche du sac en cuir », « Ajouter au panier », « Lire la politique de retour ». Si le design impose un libellé court et répété, complétez-le pour les technologies d'assistance avec un texte masqué visuellement ou un aria-label qui contient le texte visible.
<a> pour naviguer, <button> pour agir
Un lien (<a href>) mène vers une autre page ou un ancrage ; un bouton (<button>) déclenche une action (ajouter au panier, ouvrir un menu, soumettre). N'utilisez jamais une <div> ou un <span> rendu cliquable en JavaScript : ces éléments n'ont ni rôle, ni focus clavier, ni activation à la touche Entrée/Espace par défaut. Le bon élément natif apporte gratuitement le rôle, le focus et le clavier ; le recréer à la main avec role et tabindex est fragile et souvent incomplet.
<button>Ajouter au panier</button> pour l'action ; <a href="/panier">Voir le panier</a> pour la navigation.<div class="btn" onclick="..."> sans rôle ni focus ; un <a> sans href servant de bouton.La loupe, le panier, la croix : donnez-leur un nom
Les boutons réduits à une icône — loupe de recherche, panier, cœur de favori, croix de fermeture, hamburger du menu — sont partout en e-commerce et très souvent sans nom accessible. Un lecteur d'écran annonce alors « bouton » sans plus, ou pire le nom du fichier de l'image. Donnez-leur un nom : un texte masqué visuellement à l'intérieur, ou un aria-label (ex. aria-label="Rechercher"), et marquez l'icône décorative aria-hidden="true" (ou alt="" si c'est une image).
<button aria-label="Ouvrir le panier"> avec l'icône en aria-hidden="true".aria-label ; une icône en image avec alt="cart.svg".Ce qui est écrit doit faire partie du nom accessible
Quand un bouton porte un texte visible, ce texte doit être contenu dans son nom accessible. C'est crucial pour les personnes qui pilotent leur appareil à la voix : elles disent « cliquer sur Ajouter au panier » en lisant le bouton à l'écran. Si un aria-label="Ajouter cet article" remplace le texte « Ajouter au panier », la commande vocale échoue car le nom ne correspond plus à ce qui est écrit. Règle simple : si vous utilisez aria-label sur un élément qui a déjà un texte visible, ce label doit commencer par (ou inclure) ce texte.
aria-label="Article 1234" : la commande vocale ne trouve plus le bouton.Sélectionné, déplié, désactivé : ça doit s'entendre et se voir
Un bouton qui change d'état doit l'exposer, pas seulement par un style visuel. Un menu qui s'ouvre : aria-expanded="true/false". Un onglet ou un filtre actif : aria-current ou aria-pressed, pas seulement une couleur. Un bouton désactivé : l'attribut disabled (ou aria-disabled) plutôt qu'un gris décoratif. Et dans tous les cas, le focus clavier doit rester visible (critère 2.4.7) : ne supprimez jamais le contour de focus sans le remplacer par un indicateur net.
aria-expanded ; le filtre actif a aria-pressed="true" ; le focus est entouré d'un contour visible.outline:none sans remplacement ; un bouton grisé en CSS mais toujours activable.Un lien dans un paragraphe ne se distingue pas que par la couleur
Dans un bloc de texte (description produit, CGV, blog), un lien ne doit pas être identifiable uniquement par sa couleur : une personne daltonienne ne le verra pas. Le critère 1.4.1 demande un second indice — le plus simple et le plus attendu étant le soulignement. Vous pouvez aussi distinguer le lien au survol et au focus, mais l'indice doit exister aussi à l'état de repos. Pour les liens isolés et les boutons (hors texte), assurez en plus un contraste suffisant de leurs bords/texte (critère 1.4.11 pour les composants).
Récapitulatif des critères pour les liens et boutons
| Point à vérifier | Niveau | Critère WCAG |
|---|---|---|
| Libellé explicite (pas de « Cliquez ici ») | A | 2.4.4 |
| Bon élément : <a> / <button>, pas de <div> cliquable | A | 4.1.2 |
| Nom accessible des boutons icône | A | 4.1.2 · 1.1.1 |
| Le texte visible fait partie du nom (commande vocale) | A | 2.5.3 |
| États exposés (déplié, actif, désactivé) | A | 4.1.2 |
| Focus clavier visible | AA | 2.4.7 |
| Lien repérable sans la couleur seule | A | 1.4.1 |
<div>. Pour styliser librement un « Ajouter au panier », on le code parfois comme une <div> rendue cliquable en JavaScript. Visuellement, c'est un bouton ; pour le clavier et le lecteur d'écran, ce n'est rien : pas de focus, pas d'activation à Entrée, pas de rôle annoncé. Résultat : l'action d'achat la plus importante du site est inaccessible. Le <button> natif se style tout aussi librement et règle le problème.
<div> en vrai <button>, ne devine pas le libellé qu'aurait dû porter un lien « Cliquez ici » et ne nomme pas correctement vos boutons icône : ce sont des choix de code. Rappel : la FTC américaine a sanctionné un éditeur d'overlay d'un million de dollars pour des allégations de conformité trompeuses. Voir pourquoi les overlays ne suffisent pas.Comment vérifier vos liens et boutons
Plusieurs vérifications rapides, du plus automatique au plus parlant :
- Un scan automatique détecte bien plusieurs cas : bouton ou lien sans nom accessible, lien vide, image-lien sans texte alternatif, contraste insuffisant. C'est un bon premier filtre.
- La navigation au clavier (touche Tab) révèle les faux boutons : une
<div>cliquable ne reçoit jamais le focus. Vérifiez aussi que le focus reste visible sur chaque commande. - La liste des liens / boutons d'un lecteur d'écran (NVDA, VoiceOver) montre tout de suite si des libellés sont vagues ou dupliqués : c'est le test le plus représentatif pour le critère 2.4.4.
→ Méthode complète : comment tester l'accessibilité de son site. Voir aussi la navigation au clavier et le tunnel de commande, étroitement liés.
Vérifiez l'accessibilité de votre boutique gratuitement
DeclareAccess analyse une page de votre site avec le moteur axe-core selon les WCAG 2.1 AA, repère les manquements (liens et boutons sans nom, structure, contraste, formulaires…) et génère la déclaration d'accessibilité prête à publier — modèle français (RGAA), allemand (BFSG), italien ou espagnol. Gratuit, sans carte bancaire.
Rapport WCAG par e-mail sous 24 h ouvrées.
C'est noté. Votre client e-mail va s'ouvrir avec la demande pré-remplie — il vous suffit de l'envoyer.
Questions fréquentes
« En savoir plus » est-il vraiment un problème ?
Oui, dès qu'il est répété. Un lecteur d'écran peut lister tous les liens d'une page hors contexte : dix « En savoir plus » identiques deviennent impossibles à distinguer. Vous pouvez garder le texte visible court si vous complétez le nom accessible pour qu'il soit unique (par exemple « En savoir plus sur la livraison ») via un texte masqué visuellement ou un aria-label qui inclut le texte visible.
Quand utiliser un lien plutôt qu'un bouton ?
Règle simple : un lien (<a href>) change de page ou va vers un ancrage ; un bouton (<button>) déclenche une action sur la page (ajouter au panier, ouvrir un menu, soumettre un formulaire). « Voir le panier » qui mène à la page panier est un lien ; « Ajouter au panier » qui modifie le panier est un bouton. Le bon élément apporte le rôle et le clavier sans code supplémentaire.
Comment rendre accessible un bouton qui n'a qu'une icône ?
Donnez-lui un nom accessible : soit un texte masqué visuellement à l'intérieur du <button>, soit un aria-label décrivant l'action (ex. aria-label="Rechercher", aria-label="Fermer"). Marquez l'icône elle-même comme décorative (aria-hidden="true" pour une icône en police/SVG, ou alt="" si c'est une image). Ainsi le lecteur d'écran annonce « bouton Rechercher » et non « bouton » ou un nom de fichier.
Peut-on styliser un <button> comme on veut ?
Oui. Un <button> se met en forme librement en CSS : couleur, taille, bordure, icône, animation. Il n'y a donc aucune raison de le remplacer par une <div> cliquable. En partant du <button> natif, vous gagnez gratuitement le focus clavier, l'activation à Entrée/Espace et le rôle annoncé par le lecteur d'écran — des choses fastidieuses et fragiles à reconstruire à la main.
Un scan automatique détecte-t-il les problèmes de liens et boutons ?
En partie. Un scan repère bien les liens et boutons sans nom accessible, les liens vides, les images-liens sans alternative et un contraste insuffisant. Il ne peut pas juger si un libellé est pertinent (un « Cliquez ici » a bien un nom, juste mauvais) ni détecter tous les faux boutons en <div> : un test au clavier et au lecteur d'écran reste utile. Le scan est néanmoins un excellent premier filtre.