Bannières cookies et consentement RGPD accessibles
En bref
- Le bandeau cookies est souvent le tout premier élément rencontré — s'il piège le clavier, tout le site devient inutilisable au clavier.
- Tout doit être atteignable et activable au clavier (Tab, Entrée, Espace) — y compris la fermeture — sans piège de focus — WCAG 2.1.1 · 2.1.2.
- « Accepter » et « Refuser » ne peuvent pas se distinguer par la couleur seule (vert vs gris) — 1.4.1. Et le RGPD/CNIL impose qu'ils soient aussi faciles l'un que l'autre.
- Texte et boutons doivent atteindre le contraste minimum (4,5:1 texte, 3:1 bordures/icônes) — 1.4.3 · 1.4.11.
- À 200 % de zoom, le bandeau ne doit ni masquer le contenu ni empêcher de le lire ou de le fermer — 1.4.10 · 1.4.4.
- Les boutons doivent avoir un nom accessible clair et un rôle correct — 4.1.2. Un overlay ne corrige pas une CMP codée en
<div>.
Pourquoi le bandeau cookies est un cas critique
C'est le premier obstacle de la page, et le plus visité : chaque visiteur le rencontre. S'il est inaccessible, l'utilisateur ne peut ni consentir, ni refuser, ni atteindre le contenu derrière — l'échec est total dès la première seconde.
Un bandeau de consentement combine deux obligations qui se rejoignent. D'un côté, le RGPD / directive ePrivacy (en France, les lignes directrices de la CNIL) impose un choix libre, éclairé et où refuser doit être aussi simple qu'accepter. De l'autre, l'European Accessibility Act (28 juin 2025) impose que ce choix soit techniquement utilisable par tous, y compris au clavier et au lecteur d'écran, selon l'EN 301 549 / WCAG 2.1 AA.
Beaucoup de bandeaux échouent sur les deux fronts à la fois : un bouton « Tout accepter » bien visible, un « Refuser » caché derrière deux écrans, le tout piégeant le focus clavier. Rendre le bandeau accessible règle souvent les deux problèmes d'un coup.
Les 6 règles à appliquer
Tout opérable au clavier, sans piège de focus
Chaque bouton et lien du bandeau (Accepter, Refuser, Personnaliser, fermer) doit être atteignable avec Tab et activable avec Entrée ou Espace. Surtout, le focus ne doit jamais rester piégé : si l'utilisateur peut entrer dans le bandeau au clavier, il doit pouvoir en sortir au clavier (2.1.2 — pas de piège du clavier).
Si le bandeau est une modale bloquante (rien d'autre n'est utilisable tant qu'on n'a pas répondu), alors le focus doit être déplacé dans le bandeau à son ouverture, maintenu à l'intérieur tant qu'il est ouvert, puis rendu à la page une fois le choix fait — le pattern « dialog modal » classique avec role="dialog" et aria-modal="true".
Boutons nommés, rôle correct, état exposé
Chaque contrôle doit exposer un nom, un rôle et une valeur aux technologies d'assistance. En pratique : utilisez de vrais <button> avec un libellé textuel explicite (« Tout accepter », « Tout refuser », « Personnaliser mes choix »), pas des <div onclick> qui n'ont ni rôle ni focus natifs.
Si le bandeau s'ouvre en modale, donnez-lui role="dialog", aria-modal="true" et un aria-labelledby pointant vers son titre. Les interrupteurs de catégories (statistiques, marketing…) doivent être de vrais <input type="checkbox"> ou des role="switch" avec leur état aria-checked.
<button>Tout refuser</button>
✓ role="dialog" aria-modal="true" aria-labelledby
✓ Cases de catégories = checkbox avec <label>
✗ <div class="btn" onclick> sans rôle ni nom
« Accepter » et « Refuser » : pas distingués par la couleur seule
Le motif classique — « Tout accepter » en vert proéminent, « Refuser » en gris pâle à peine visible — pose un double problème. Côté WCAG 1.4.1, l'information (« ceci est le bouton principal ») ne peut pas reposer uniquement sur la couleur : un utilisateur daltonien ou en mode contraste élevé doit pouvoir distinguer et lire les deux options par leur libellé.
Côté RGPD, les lignes directrices de la CNIL exigent que refuser soit aussi simple qu'accepter — même niveau de visibilité, même nombre de clics. Les deux exigences convergent : présentez deux boutons clairement libellés, lisibles, de prominence équivalente. La distinction « principal / secondaire » peut passer par la forme (plein vs contour) en plus de la couleur, mais jamais par la couleur seule.
Contraste suffisant du texte et des boutons
Le texte du bandeau doit atteindre un contraste de 4,5:1 (3:1 pour le grand texte). C'est exactement le piège qui revient le plus souvent sur ces bandeaux : un texte gris clair sur fond blanc, ou un libellé blanc sur un bouton vert pâle, échoue à ce seuil. Les bordures et icônes des boutons (et les interrupteurs de catégories) relèvent de 1.4.11 : contraste minimum 3:1 contre leur arrière-plan.
Un bouton « Refuser » volontairement délavé pour décourager le refus échoue presque toujours au contraste — corriger l'accessibilité corrige aussi le dark pattern.
Reflow et zoom : ne pas masquer ni bloquer le contenu
À 200 % de zoom (1.4.4) et en reflow à 320 px de large (1.4.10), le bandeau ne doit pas grandir au point de couvrir tout l'écran sans pouvoir défiler, ni piéger l'utilisateur dans une zone qu'il ne peut pas faire défiler pour atteindre les boutons. Un bandeau plein écran dont le bouton « Valider » se retrouve hors de la zone visible, sans scroll possible, est un blocage total.
Veillez aussi à ce que le bandeau ne recouvre pas en permanence du contenu essentiel (mentions légales, lien de contact) au point de le rendre inatteignable tant que le choix n'est pas fait — proche de la problématique 2.4.11 (contenu masqué par le focus) en WCAG 2.2.
Annonce au lecteur d'écran et pas de surprise
Quand le bandeau apparaît après le chargement (ou qu'un message « Vos préférences ont été enregistrées » s'affiche après le choix), il doit être perçu par les lecteurs d'écran. Pour une modale, le déplacement du focus suffit ; pour un message de confirmation non bloquant, une région aria-live="polite" (ou un role="status") l'annonce sans voler le focus — c'est l'objet de 4.1.3 (Messages d'état).
Enfin, recevoir le focus sur un contrôle ne doit pas déclencher de changement de contexte inattendu (3.2.1) : tabuler sur « Personnaliser » ne doit pas valider ni recharger la page — seule une action explicite (clic / Entrée) le doit.
role="status" / aria-live="polite"
✗ Bandeau ajouté au DOM sans aucune annonce
✗ Le focus sur un onglet valide le consentement
Récapitulatif des critères
| Critère WCAG | Niveau | Application au bandeau cookies |
|---|---|---|
| 2.1.1 — Clavier | A | Tous les boutons et interrupteurs activables au clavier (Tab + Entrée/Espace) |
| 2.1.2 — Pas de piège au clavier | A | On peut entrer ET sortir du bandeau au clavier |
| 1.4.1 — Utilisation de la couleur | A | Accepter / Refuser distingués par le libellé, pas la couleur seule |
| 1.4.3 — Contraste (minimum) | AA | Texte et libellés de bouton ≥ 4,5:1 |
| 1.4.11 — Contraste des éléments non-texte | AA | Bordures de boutons et interrupteurs ≥ 3:1 |
| 1.4.4 / 1.4.10 — Zoom et reflow | AA | Bandeau utilisable et scrollable à 200 % / 320 px |
| 3.2.1 — Au focus | A | Le focus ne valide ni ne recharge — seule l'action explicite le fait |
| 4.1.2 — Nom, rôle, valeur | A | Vrais <button> nommés ; modale = role="dialog" |
| 4.1.3 — Messages d'état | AA | Confirmation de choix annoncée via aria-live sans voler le focus |
Comment vérifier
- Clavier seul : chargez la page, n'utilisez que Tab, Maj+Tab, Entrée et Espace. Vous devez pouvoir accepter, refuser, personnaliser, fermer — et atteindre le contenu derrière. Si le focus reste coincé, c'est un piège (2.1.2).
- Lecteur d'écran (NVDA / VoiceOver) : à l'apparition, le bandeau doit être annoncé (focus déplacé pour une modale). Chaque bouton doit être annoncé avec son libellé. Le message « préférences enregistrées » doit être lu.
- Contraste : vérifiez le texte et les libellés de boutons (≥ 4,5:1) et les bordures (≥ 3:1) avec un vérificateur de contraste ou l'audit axe-core.
- Zoom 200 % (navigateur) : le bandeau reste lisible, scrollable, et tous les boutons sont atteignables — rien n'est coupé hors écran sans défilement.
Questions fréquentes
J'utilise une CMP tierce (Axeptio, Cookiebot, Didomi…). Suis-je couvert pour l'accessibilité ?
Pas automatiquement. Une CMP gère le recueil et la traçabilité du consentement RGPD, mais l'accessibilité du bandeau réellement affiché dépend de son thème, de sa configuration et de votre intégration. Certaines CMP proposent des modèles plus accessibles que d'autres, mais aucune ne vous dispense de vérifier le rendu final au clavier et au lecteur d'écran. La responsabilité de la conformité reste celle de l'éditeur du site, pas du fournisseur de la CMP.
Mon bandeau doit-il être une vraie fenêtre modale qui bloque la page ?
Ce n'est pas obligatoire. Un bandeau non bloquant (en bas de page, sans piéger le focus) est tout à fait acceptable et souvent plus simple à rendre accessible. Si vous choisissez une modale bloquante, vous devez alors gérer correctement le focus : le déplacer dans la modale à l'ouverture, le maintenir à l'intérieur tant qu'elle est ouverte (focus trap volontaire), et le restituer à la page après le choix — avec role="dialog" et aria-modal="true". La modale mal gérée crée justement le piège de focus que 2.1.2 interdit.
Pourquoi « refuser aussi facilement qu'accepter » apparaît dans un guide d'accessibilité ?
Parce que les deux exigences se recoupent. C'est d'abord une règle RGPD (lignes directrices de la CNIL en France) : le consentement n'est valide que s'il est libre, donc refuser doit être aussi simple qu'accepter. Mais un bouton « Refuser » caché ou délavé est aussi, presque toujours, une non-conformité d'accessibilité (contraste 1.4.3, information par la couleur 1.4.1). Corriger l'un corrige souvent l'autre — d'où la mention dans ce guide.
Le bandeau réapparaît à chaque page et casse ma navigation clavier. Que faire ?
Un bandeau bien construit ne réapparaît qu'une fois (le choix est mémorisé), et place le focus de façon prévisible. S'il réapparaît à chaque navigation et capture le focus à chaque fois, il viole à la fois le bon sens UX et l'esprit de 2.4.3 (ordre de focus cohérent). Vérifiez que le consentement est correctement stocké et que le bandeau ne se réinjecte pas à chaque chargement. Pour les utilisateurs clavier, le bandeau ne devrait pas se placer avant le lien d'évitement ni perturber l'ordre de tabulation des pages suivantes.
Le scanner gratuit de DeclareAccess détecte-t-il les problèmes de bandeau cookies ?
Partiellement. Le scanner basé sur axe-core détecte fiablement les boutons sans nom accessible (cas du bandeau en <div>), les contrastes de texte insuffisants et certains problèmes d'ARIA. En revanche, il ne peut pas tester le piège de focus au clavier, ni l'égalité réelle entre « Accepter » et « Refuser », ni le comportement au zoom — ces points exigent un test manuel au clavier et au lecteur d'écran. Comme beaucoup de bandeaux sont injectés en JavaScript après le chargement, pensez aussi à scanner la page une fois le bandeau affiché.
Lancez le scan automatisé de votre boutique
DeclareAccess analyse une page de votre site selon les WCAG 2.1 AA, vous renvoie un rapport chiffré des non-conformités (avec les éléments concernés), puis génère la déclaration d'accessibilité prête à publier — modèle français (RGAA) ou allemand (BFSG). Audit gratuit, sans carte bancaire.
Rapport WCAG par e-mail sous 24 h ouvrées.
C'est noté. Votre demande d'audit est enregistrée — vous recevrez votre rapport WCAG par e-mail sous 24 h ouvrées.