Panier et mini-panier accessibles : modifier, supprimer, total
En bref — la dernière page avant le paiement doit être pilotable par tous
Le panier est l'avant-dernière étape de l'achat : on y ajuste les quantités, on retire un article, on saisit un code promo, on vérifie le total, puis on passe commande. C'est aussi un composant très « dynamique » — tout y change sans recharger la page — ce qui en fait un point d'abandon fréquent quand les changements ne sont pas perçus par une personne aveugle ou ne sont pas atteignables au clavier. L'European Accessibility Act (norme EN 301 549 / WCAG 2.1 AA), applicable au commerce électronique depuis le 28 juin 2025, impose notamment :
- Des contrôles de quantité réels et nommés — un champ étiqueté ou des boutons « plus / moins » explicites, utilisables au clavier (4.1.2, niveau A · 2.1.1, niveau A) ;
- Une suppression d'article par un bouton au libellé clair — « Supprimer [produit] du panier », pas une icône poubelle muette (2.4.4, niveau A · 1.1.1, niveau A) ;
- Un total recalculé annoncé au lecteur d'écran via une région live quand une quantité change ou qu'un article part (4.1.3, niveau AA) ;
- Un code promo et un mini-panier accessibles — champ étiqueté avec message d'erreur relié, panier déroulant utilisable au clavier et son ouverture annoncée (3.3.1 / 4.1.2, niveaux A).
Comme pour la fiche produit, tout relève ici du socle de niveau A et AA : aucun critère AAA « de confort » en jeu. Ces règles sont exigées — et chaque obstacle au panier se paie directement en commandes perdues.
Le panier est le sas de la conversion : on y revient pour vérifier, ajuster, hésiter, puis valider. Or c'est l'un des écrans les plus interactifs d'une boutique — les quantités s'incrémentent, les lignes disparaissent, le sous-total se met à jour, un code promo s'applique — et tout cela arrive sans rechargement. Pour une personne au clavier ou au lecteur d'écran, un panier mal conçu devient un labyrinthe silencieux : on ne sait pas si l'article a été retiré, ni quel est le nouveau total. Voici les six familles de règles WCAG à appliquer sur la page panier et le mini-panier, ce que l'EAA exige précisément, et comment le vérifier.
Pourquoi le panier perd des clients en silence
Le panier concentre des interactions « riches » qui modifient la page en direct : un sélecteur de quantité avec des boutons « + » et « – », une croix ou une poubelle pour retirer une ligne, un champ de code promo, et un récapitulatif (sous-total, livraison, total) qui se recalcule à chaque geste. Ce sont précisément les éléments souvent recodés « sur mesure » en <div> stylés et mis à jour en JavaScript, ce qui fait perdre au passage le rôle, le nom, l'état et — surtout — l'annonce des changements.
Pour une personne qui utilise un lecteur d'écran, un total qui passe de 89 € à 59 € sans être annoncé n'existe pas : elle ignore que son action a eu un effet. Une poubelle sans nom accessible se lit « bouton », sans dire ce qu'elle supprime ni de quel article il s'agit. Pour une personne en navigation clavier, des boutons « + »/« – » qui ne réagissent qu'à la souris, ou un mini-panier qui ne s'ouvre qu'au survol, rendent le panier inutilisable. L'EAA s'appuie sur l'EN 301 549, fondée sur les WCAG 2.1 niveau AA ; les critères mobilisés sur un panier sont des fondations : 1.1.1 (contenu non textuel), 1.3.1 (information et relations), 1.4.1 (utilisation de la couleur), 2.1.1 (clavier), 2.4.4 (fonction des liens), 3.3.1 (erreurs identifiées), 4.1.2 (nom, rôle, valeur) et 4.1.3 (messages d'état).
Les 6 règles pour un panier accessible
Chaque article forme un ensemble clair : nom, variante, prix, quantité, sous-total
Le récapitulatif du panier doit avoir une structure explicite pour qu'une personne au lecteur d'écran comprenne quelle information appartient à quel article. Un panier présenté en tableau s'appuie sur de vrais <th> d'en-tête (Produit, Prix, Quantité, Sous-total) ; un panier en « cartes » relie chaque prix et chaque contrôle au nom du produit. Le nom de l'article est idéalement un lien vers sa fiche, au libellé explicite. L'objectif : que « 39 € », « Quantité 2 » et « Supprimer » soient sans ambiguïté rattachés au bon produit (critère 1.3.1).
<th scope="col"> ; chaque ligne porte le nom du produit en lien, et ses contrôles le nomment (« Supprimer Sac à dos toile »).<div> où prix, quantité et bouton flottent sans rattachement : au lecteur d'écran, impossible de savoir à quel article se rapporte « 59 € ».→ Voir aussi les tableaux de données accessibles.
Un champ étiqueté ou des boutons « plus / moins » explicites
Le réglage de la quantité doit reposer sur de vrais composants de formulaire : soit un <input> numérique avec une étiquette reliée (« Quantité, Sac à dos toile »), soit des boutons « + » et « – » portant un nom accessible — pas un simple symbole. Ces boutons doivent être atteignables et activables au clavier, avec un focus visible. Un « + » seul, sans libellé, s'annonce « bouton plus » sans dire ce qu'il augmente. Quand la quantité change, le sous-total de la ligne est recalculé : ce changement doit être perceptible (voir règle 4).
<button aria-label="Augmenter la quantité, Sac à dos toile">+</button> ; ou un <input type="number"> avec <label> relié.<span> « + » et « – » cliquables uniquement à la souris, sans nom ni focus : inatteignables au clavier, muets au lecteur d'écran.→ Voir aussi les libellés de liens et boutons et les composants interactifs.
« Supprimer [produit] » plutôt qu'une poubelle muette
Le bouton de retrait d'une ligne est l'un des plus souvent inaccessibles : c'est une icône (croix, poubelle) sans texte. Or une icône seule n'a pas de nom accessible : au lecteur d'écran, elle s'annonce « bouton », sans dire qu'elle supprime, ni quoi. Donnez-lui un nom explicite par un texte visible, un aria-label (« Supprimer Sac à dos toile du panier ») ou un texte masqué visuellement ; l'icône elle-même est décorative (aria-hidden). Le bouton doit être atteignable au clavier (2.1.1), et la suppression effective annoncée (voir règle 4) pour confirmer l'action.
<button aria-label="Supprimer Sac à dos toile du panier"><svg aria-hidden="true">…</svg></button>.<div> avec une icône poubelle, sans nom ni focus : on ne sait ni que c'est un bouton, ni quel article il retire.→ Voir aussi boutons icône et nom accessible.
Le sous-total et le total changent sans rechargement : il faut le dire
C'est la règle clé du panier. Dès qu'une quantité change ou qu'un article est supprimé, le sous-total de ligne, le total et le nombre d'articles sont recalculés côté client. Une personne aveugle ne voit pas ce changement : il faut l'annoncer via une région live (role="status" ou aria-live="polite") — par exemple « Article supprimé, nouveau total : 59 €, 2 articles ». Sans cela, l'utilisateur agit dans le vide : a-t-il bien retiré l'article ? combien doit-il ? C'est le critère 4.1.3 (Messages d'état). Veillez aussi à ce que la mise à jour ne déplace pas le focus de façon inattendue : après suppression, le focus doit rester à un endroit logique (la ligne suivante, ou un message).
<div role="status"> reçoit « Quantité mise à jour, sous-total 78 €, total du panier 96 € » à chaque changement.→ Voir aussi les messages d'état et régions live.
Champ nommé, erreur reliée, succès qui ne tient pas qu'à la couleur
Le champ de code promo / bon de réduction est un mini-formulaire à part entière. Il a besoin d'une étiquette reliée (« Code promo »), pas seulement d'un placeholder gris qui disparaît à la saisie. En cas d'erreur (code invalide, expiré), le message doit être en texte, relié au champ et annoncé (3.3.1, 3.3.3). En cas de succès, la réduction appliquée ne doit pas être signalée par la seule couleur verte : dites-le en mots et annoncez le nouveau total (1.4.1, 4.1.3). Le bouton « Appliquer » est un vrai bouton nommé.
<label for="promo">Code promo</label> ; à l'échec, « Code expiré » relié via aria-describedby ; au succès, « Réduction de 10 € appliquée, nouveau total 49 € » dans une région live.→ Voir aussi les messages d'erreur de formulaire et le tunnel de commande.
Le panier de l'en-tête : ouvert au clavier, état exposé, contenu annoncé
Beaucoup de boutiques affichent un mini-panier déroulant depuis l'icône de l'en-tête. Il doit s'ouvrir par un vrai bouton (pas seulement au survol), exposer son état avec aria-expanded, et son contenu doit être atteignable au clavier sans piège (on doit pouvoir en sortir avec Échap ou Tab). L'icône panier de l'en-tête a besoin d'un nom accessible incluant le nombre d'articles (« Panier, 3 articles »), et ce compteur doit se mettre à jour de façon perceptible. Un mini-panier qui n'apparaît qu'au survol de la souris et disparaît au moindre mouvement exclut les personnes au clavier et complique la tâche en cas de tremblements (critère 1.4.13 pour le contenu au survol/focus).
<button aria-expanded="false" aria-label="Panier, 3 articles"> ouvre le mini-panier ; on y navigue au clavier, Échap le referme et rend le focus au bouton.→ Voir aussi menus et composants déroulants accessibles.
Récapitulatif : sur le panier aussi, tout est du socle
| Point à vérifier | Niveau | Statut EAA |
|---|---|---|
| Panier structuré, lignes rattachées au produit — 1.3.1 | A | Exigé |
| Quantité : champ ou boutons nommés, au clavier — 4.1.2 / 2.1.1 | A | Exigé |
| Suppression : bouton au libellé explicite — 2.4.4 / 1.1.1 | A | Exigé |
| Total recalculé annoncé, focus géré — 4.1.3 / 2.4.3 | A · AA | Exigé |
| Code promo : étiqueté, erreur reliée, pas la couleur seule — 3.3.1 / 1.4.1 | A | Exigé |
| Mini-panier : au clavier, état exposé, nombre d'articles — 2.1.1 / 4.1.2 | A · AA | Exigé |
role="status" ou aria-live="polite") qui énonce à chaque changement le nouveau sous-total, le total et le nombre d'articles — et un focus qui reste à un endroit logique après une suppression. C'est l'un des correctifs les plus rentables : il rend le panier pilotable jusqu'au paiement.
Comment vérifier votre panier
Quelques contrôles concrets à mener directement sur la page panier :
- Modifiez une quantité au clavier seul : peut-on atteindre et activer les boutons « + »/« – » (ou le champ) sans souris, avec un focus visible ?
- Supprimez un article au lecteur d'écran : le bouton dit-il ce qu'il retire (« Supprimer [produit] ») ? la suppression et le nouveau total sont-ils annoncés ?
- Écoutez le total après chaque geste : le sous-total et le total changent-ils en silence, ou sont-ils énoncés ?
- Testez un code promo invalide : le message d'erreur est-il en texte, relié au champ et annoncé ?
- Ouvrez le mini-panier au clavier : s'ouvre-t-il sans la souris ? peut-on en sortir avec Échap ? l'icône annonce-t-elle le nombre d'articles ?
Une partie de ces points se prête à la détection automatique : un scanner repère un bouton sans nom accessible, un champ de code promo non étiqueté, un contraste insuffisant, une icône sans alternative. En revanche, savoir si le total est annoncé, si le focus est correctement géré après une suppression, ou si le mini-panier est pilotable au clavier demande un essai réel au clavier et au lecteur d'écran. Notre rapport signale les manquements détectables sur la page analysée et liste les vérifications manuelles à mener.
→ Méthode complète : comment tester l'accessibilité de son site. Voir aussi par où commencer.
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 (boutons sans nom, champs non étiquetés, contraste, structure…) 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
Faut-il annoncer le nouveau total quand on change une quantité ?
Oui. Quand le total ou le sous-total se recalcule sans rechargement de page, le changement doit être annoncé via une région live (aria-live="polite" ou role="status"), par exemple « Quantité mise à jour, total du panier 96 € ». Sans cette annonce, une personne aveugle ne sait pas combien elle doit ni si son action a abouti : c'est le critère 4.1.3 (Messages d'état, niveau AA).
Une icône poubelle suffit-elle pour supprimer un article ?
Pas seule. Une icône sans texte n'a pas de nom accessible : au lecteur d'écran, elle s'annonce « bouton » sans dire qu'elle supprime, ni quel article. Donnez au bouton un nom explicite — par un texte visible ou un aria-label du type « Supprimer [produit] du panier » — et marquez l'icône comme décorative (aria-hidden). Le bouton doit aussi être activable au clavier (critères 2.4.4 et 1.1.1, niveau A).
Comment rendre les boutons « + » et « – » de quantité accessibles ?
Ils doivent être de vrais <button> atteignables au clavier, avec un nom accessible qui précise l'action et l'article — par exemple aria-label="Augmenter la quantité, Sac à dos toile". Un « + » seul s'annonce « bouton plus » sans contexte. Une alternative est un <input type="number"> avec une étiquette reliée. Dans les deux cas, le sous-total recalculé doit être annoncé (critères 4.1.2 et 2.1.1, niveau A).
Un mini-panier qui s'ouvre au survol est-il conforme ?
Pas s'il ne fonctionne qu'au survol de la souris. Le mini-panier doit s'ouvrir par un vrai bouton utilisable au clavier, exposer son état avec aria-expanded, et son contenu doit être atteignable puis refermable (par exemple avec Échap). Un panneau survol-uniquement exclut les personnes au clavier et celles qui ont des tremblements ; le contenu affiché au survol ou au focus relève en plus du critère 1.4.13 (niveau AA).
Le panier doit-il forcément être un tableau ?
Non. Un tableau avec de vrais en-têtes est une bonne option, mais un panier en « cartes » est tout aussi valable s'il rattache clairement chaque information (prix, quantité, sous-total) et chaque contrôle au nom du produit concerné. L'exigence est la relation explicite entre les éléments, pas une structure de tableau en particulier (critère 1.3.1, niveau A).