Bandeau cookies et accessibilité : ce qu'exige vraiment le RGAA

Vous chargez une page pour la première fois, et avant même d'avoir lu une ligne, un bandeau de cookies s'affiche. Vous rangez la souris, vous appuyez sur Tab pour l'atteindre au clavier, et là, plus rien : impossible d'entrer dans le bandeau, ou pire, impossible d'en sortir. Ce scénario n'a rien d'anecdotique. Le bandeau de consentement est, chronologiquement, le premier composant interactif que rencontre un internaute. S'il est mal conçu, il ne dégrade pas l'expérience : il la bloque, dès la position zéro.

On parle beaucoup des bandeaux cookies sous l'angle du RGPD et de la CNIL. On en parle beaucoup moins sous l'angle du RGAA, alors que c'est souvent là que le bât blesse. Cet article fait le tour des critères RGAA qu'un bandeau de consentement doit réellement respecter, lève une idée fausse tenace (« confiner le focus, c'est piéger le clavier »), et vous donne une checklist clavier de 30 secondes utilisable sans aucun outil. Registre honnête garanti : on distingue partout ce qu'une machine peut détecter de ce qu'un humain doit trancher.

Le bandeau cookies : un test d'accessibilité en position zéro

Le premier composant interactif que rencontre l'internaute

Un bandeau de consentement s'affiche avant le contenu, souvent par-dessus lui, et réclame une action immédiate : accepter, refuser ou paramétrer. Pour une personne qui navigue à la souris, c'est une formalité de deux secondes. Pour une personne qui navigue au clavier seul, à la voix, ou avec un lecteur d'écran, ce même bandeau devient le tout premier obstacle à franchir. Il concentre donc, sur quelques centimètres carrés, l'essentiel des points de friction de l'accessibilité web : focus clavier, contrastes, étiquettes de formulaire, ordre de tabulation, restitution des messages.

S'il piège le clavier, tout le reste du site devient inatteignable

C'est ce qui rend le bandeau cookies particulier. Un défaut de contraste sur un article de blog gêne la lecture de cet article. Un piège au clavier sur le bandeau d'accueil, lui, empêche l'utilisateur d'atteindre quoi que ce soit d'autre. Il n'a même pas pu commencer sa visite. Ce n'est pas un défaut parmi cent-six, c'est un défaut bloquant, en amont de tous les autres. D'où l'intérêt de le traiter en priorité.

Piège au clavier : le critère RGAA 12.9, angle mort des bandeaux

Ce que dit le critère 12.9 et sa base WCAG 2.1.2

Le critère RGAA 12.9 (niveau A) est formulé ainsi : « Dans chaque page web, la navigation ne doit pas contenir de piège au clavier. Cette règle est-elle respectée ? »

Sa base normative est le critère de succès WCAG 2.1.2 « Pas de piège au clavier ». Le principe, tel que l'explicite le document W3C Understanding SC 2.1.2 : si le focus clavier peut être placé sur un composant, alors il doit pouvoir en être retiré au seul clavier. Si Tab, les flèches ou Échap ne suffisent pas, l'utilisateur doit au minimum être informé de la méthode pour sortir. Un bandeau qui capte le focus sans offrir de porte de sortie au clavier viole ce critère.

Confiner le focus n'est pas le piéger : la nuance qui change tout

Voici l'idée fausse à démonter : « si le bandeau garde le focus à l'intérieur, c'est un piège au clavier ». C'est faux. Un bandeau modal a parfaitement le droit de retenir le focus tant qu'il est ouvert. C'est même le comportement recommandé par le patron Dialog (Modal) de l'ARIA Authoring Practices Guide : à l'ouverture, le focus entre dans le dialogue ; Tab et Maj+Tab bouclent à l'intérieur (confinement volontaire) ; la touche Échap ferme le dialogue ; à la fermeture, le focus revient sur l'élément qui l'a déclenché.

Confiner n'est donc pas piéger. Le confinement est légitime tant qu'il existe une sortie clavier. Le piège, au sens du 12.9, c'est exactement l'inverse : entrer sans pouvoir sortir. Pour approfondir la mécanique du focus dans les fenêtres modales, voir notre article Modales accessibles : implémentation ARIA et gestion du clavier.

<!-- MAUVAIS : faux boutons non focusables, aucune sortie clavier -->
<div class="cookie-banner">
  <div class="btn" onclick="acceptAll()">Tout accepter</div>
  <div class="btn" onclick="refuseAll()">Tout refuser</div>
  <!-- des <div> non atteignables au Tab, pas de role, Echap ne ferme rien -->
</div>

<!-- BON : dialogue modal, boutons natifs, Echap ferme -->
<div role="dialog" aria-modal="true" aria-labelledby="cookie-titre">
  <h2 id="cookie-titre">Gestion des cookies</h2>
  <button type="button" onclick="acceptAll()">Tout accepter</button>
  <button type="button" onclick="refuseAll()">Tout refuser</button>
  <button type="button" onclick="openSettings()">Parametrer</button>
</div>
<!-- Echap referme le dialogue et rend le focus au declencheur -->

Les trois symptômes d'un vrai piège

Comment reconnaître un vrai piège au clavier sur un bandeau ? Trois symptômes, faciles à repérer à la main :

1. Pas de touche Échap. Vous êtes dans le bandeau, mais aucune touche ne le ferme.
2. Un contrôle inatteignable. Le bouton « Refuser » ou « Paramétrer » existe visuellement, mais Tab ne l'atteint jamais (souvent parce que c'est un faux bouton en <div> ou <span> sans tabindex).
3. Un focus renvoyé en boucle. À chaque Tab, le focus tourne indéfiniment dans le bandeau et ne rend jamais la main au reste de la page ni ne propose de sortie.

Pour aller plus loin sur ce critère et ses variantes hors bandeau cookies, consultez notre article dédié Pièges au clavier : un frein majeur à l'accessibilité web et la fiche officielle du critère 12.9.

Les autres critères RGAA qu'un bandeau doit respecter

Le 12.9 est le point le plus bloquant, mais un bandeau de consentement mobilise en réalité une petite grappe de critères. Voici les libellés officiels des principaux concernés.

Contraste du texte et des contrôles (3.2 et 3.3)

Un bandeau au design « léger » (texte gris clair sur fond blanc, bouton « Refuser » volontairement plus discret que « Accepter ») trébuche vite sur le contraste. Le critère de succès WCAG 1.4.3, base du RGAA 3.2, impose un ratio d'au moins 4,5:1 pour le texte normal, et 3:1 pour le grand texte (au moins 18 points, ou 14 points en gras). Le critère WCAG 1.4.11, base du RGAA 3.3, exige lui un ratio d'au moins 3:1 pour les composants d'interface et leurs bordures : contour des boutons, cases à cocher, indicateur de focus. Un bouton « Refuser » dont la bordure disparaît sur le fond échoue au 3.3. Pour comprendre pourquoi le seul ratio 4,5:1 ne suffit plus, voir Contrastes de couleurs : pourquoi le ratio 4.5:1 ne suffit plus.

Boutons Accepter / Refuser / Paramétrer réellement activables au clavier (7.1, 7.3, 7.4)

Beaucoup de bandeaux affichent de faux boutons : un <div> ou un <span> stylé en bouton, activable au clic mais pas au clavier. C'est un échec conjoint du 7.3 (le script doit être contrôlable au clavier) et du 7.1 (compatibilité avec les technologies d'assistance, car un <div> sans rôle n'est pas annoncé comme un bouton). Le 7.4 entre en jeu quand une action déclenche un changement de contexte : si cliquer sur « Accepter » recharge la page ou vous redirige sans prévenir, l'utilisateur doit en être averti ou en avoir le contrôle. La règle est simple : utilisez des <button> natifs pour les actions, jamais des <div onClick>.

Cases à cocher et champs avec étiquette programmatique (11.1)

Le panneau « Paramétrer » d'un bandeau contient presque toujours des cases à cocher par finalité (mesure d'audience, publicité, réseaux sociaux). Chacune doit avoir une étiquette associée programmatiquement, faute de quoi un lecteur d'écran annonce « case à cocher, non cochée » sans dire de quoi il s'agit. C'est l'objet du critère 11.1.

<!-- MAUVAIS : etiquette juste posee a cote, non associee -->
<input type="checkbox" id="stats"> Statistiques

<!-- BON : label associe explicitement par for/id -->
<input type="checkbox" id="stats">
<label for="stats">Cookies de mesure d'audience</label>

Le détail de ce mécanisme et ses pièges figurent dans Pourquoi chaque champ de formulaire nécessite un label.

Ordre de tabulation cohérent (12.8) et confirmation annoncée sans voler le focus (7.5)

Deux points souvent oubliés. D'abord l'ordre de tabulation (12.8) : dans le panneau de réglages, la tabulation doit suivre un enchaînement logique (case, puis case, puis boutons de validation), pas sauter de façon erratique à cause d'un tabindex positif mal placé. La visibilité du focus qui accompagne cet ordre est traitée dans Indicateurs de focus visibles.

Ensuite la confirmation. Quand l'utilisateur valide et qu'un message « Vos préférences ont été enregistrées » apparaît, ce message de statut doit être restitué aux technologies d'assistance sans recevoir le focus, comme l'explique le critère WCAG 4.1.3, base du RGAA 7.5. C'est le rôle d'une zone live.

<!-- Confirmation annoncee sans voler le focus -->
<p role="status">Vos preferences ont ete enregistrees.</p>

Le fonctionnement des zones live est détaillé dans ARIA Live régions : le guide pour rendre vos dashboards accessibles.

Accessibilité et consentement CNIL : deux exigences qui se renforcent

Refuser doit être aussi simple qu'accepter

On oppose souvent RGPD et RGAA comme deux contraintes concurrentes. Sur les bandeaux cookies, c'est l'inverse : elles se renforcent. La CNIL rappelle que le consentement doit être « libre, spécifique, éclairé et univoque », et que l'utilisateur doit pouvoir accepter ou refuser le dépôt de cookies « avec le même degré de simplicité ». La CNIL a d'ailleurs engagé des mises en demeure sur ce point précis.

Un contrôle inaccessible fragilise la validité du consentement

Or, si le bouton « Refuser » a un contraste insuffisant, n'a pas d'étiquette accessible ou n'est tout simplement pas atteignable au clavier, alors, pour une partie des utilisateurs, refuser n'est pas aussi simple qu'accepter. L'accessibilité devient ici une condition de validité du consentement : un « Refuser » que certains ne peuvent pas activer n'est plus vraiment « libre » ni « univoque ». Améliorer l'accessibilité de votre bandeau, ce n'est donc pas seulement cocher une case RGAA, c'est aussi consolider votre conformité CNIL. Restons centrés accessibilité : la CNIL sert ici de point d'ancrage, pas de sujet.

Tester votre bandeau au clavier en 30 secondes, sans outil

La checklist Tab / Échap / focus visible / ordre logique

Vous n'avez besoin d'aucun logiciel pour repérer les défauts les plus graves. Rangez la souris et faites ce test :

1. Tab. Pouvez-vous atteindre chaque bouton (Accepter, Refuser, Paramétrer) au clavier seul ?
2. Échap ou sortie. Une fois dans le bandeau, pouvez-vous en ressortir sans souris (Échap qui ferme, ou Tab qui finit par rendre la main) ?
3. Focus visible. Voyez-vous nettement où se trouve le focus à chaque étape (un contour, un halo) ?
4. Ordre logique. L'enchaînement des tabulations suit-il un ordre qui a du sens ?

Si vous butez sur un seul de ces points, vous tenez probablement une non-conformité, dont le piège au clavier (12.9) est la plus bloquante.

Ce qu'un audit externe constate en conditions réelles

Ce constat n'est pas théorique. Dans un article de Smashing Magazine (Marcus Herrmann, 2023), un expert documente cinq familles d'échecs récurrents des bandeaux cookies : contrôles au contraste insuffisant, faux boutons non focusables au clavier, cases à cocher sans étiquette programmatique, sémantique de dialogue cassée, et mauvaise découvrabilité pour les lecteurs d'écran. On retrouve exactement notre grappe de critères RGAA (3.2, 3.3, 7.1, 7.3, 11.1). À prendre pour ce que c'est : un constat d'expert de 2023, pas une statistique nationale.

Ce que notre scanner détecte, et ce qu'il ne peut pas décider

Détection nommée des CMP connus dans la page rendue

Soyons transparents sur l'outillage. Notre scanner sait repérer, dans la page telle qu'elle est rendue (bandeaux injectés en JavaScript inclus), la présence des plateformes de gestion du consentement (CMP) les plus répandues, et vous les nomme : OneTrust, Axeptio, Didomi, tarteaucitron et Cookiebot. Il s'appuie pour cela sur les conteneurs stables de ces solutions.

Un signal « à vérifier », jamais un verdict

Quand un CMP est détecté, le scanner ne déclare pas le bandeau accessible ou inaccessible. Il émet un signal sur le critère 12.9 du type « Bandeau de consentement détecté (OneTrust). Vérifiez qu'il ne piège pas la navigation au clavier », accompagné des trois vérifications manuelles à mener vous-même. C'est un signal « à vérifier », pas un verdict : la présence d'un bandeau n'est pas une non-conformité établie, et l'absence de signalement n'est pas une garantie de conformité. Le piège au clavier, le contraste réel des contrôles et la pertinence des étiquettes se jugent à la main. Si vous voulez que le scanner repère et nomme le CMP présent sur une de vos pages, lancez une analyse : il vous mettra sur la piste du 12.9, à vous de conclure.

La part du manuel : 8 vérifiés, 65 pré-vérifiés, 33 manuels sur 106

Pour situer honnêtement ce qu'une machine peut et ne peut pas faire : sur les 106 critères du RGAA, notre scanner en vérifie 8 automatiquement, en pré-vérifie 65 (une anomalie est détectée, mais sa pertinence reste à valider humainement) et en laisse 33 exclusivement manuels. Un bandeau cookies mobilise surtout des critères de la seconde et de la troisième catégorie. Autrement dit, l'outil vous fait gagner du temps et pointe les zones à risque, mais le verdict d'accessibilité reste un acte humain. Un score RGAA Checker n'est pas un taux de conformité RGAA.

Questions fréquentes

Un bandeau cookies qui garde le focus à l'intérieur est-il un piège au clavier ? Non, pas nécessairement. Un bandeau modal a le droit de confiner le focus tant qu'il est ouvert (comportement recommandé par l'ARIA Authoring Practices Guide), à condition que la touche Échap le ferme et que le focus revienne à son point de départ. Le piège au clavier (critère 12.9), c'est entrer sans pouvoir sortir au clavier seul.

Quels critères RGAA s'appliquent à un bandeau de consentement ? Principalement le 12.9 (piège au clavier), les 3.2 et 3.3 (contrastes), les 7.1, 7.3 et 7.4 (scripts contrôlables au clavier, changement de contexte), le 11.1 (étiquettes des cases), le 12.8 (ordre de tabulation) et le 7.5 (message de confirmation restitué aux technologies d'assistance).

Un scanner peut-il vérifier automatiquement l'accessibilité d'un bandeau cookies ? Non entièrement. Notre scanner détecte et nomme le CMP présent dans la page rendue et vous signale le 12.9 à tester, mais le piège au clavier, le contraste réel des contrôles et la pertinence des étiquettes se jugent manuellement. Une anomalie détectée n'est pas une non-conformité établie.

Refuser les cookies doit-il être aussi accessible qu'accepter ? Oui. La CNIL exige que refuser soit aussi simple qu'accepter. Si le bouton « Refuser » a un contraste insuffisant ou n'est pas atteignable au clavier, refuser n'est plus aussi simple pour une partie des utilisateurs, et la validité du consentement s'en trouve fragilisée.

Gardez la checklist à portée de clavier

Le bandeau cookies est un petit composant, mais il occupe une grande place : celui que tout le monde voit en premier, et celui que beaucoup ne peuvent pas franchir. Vous n'avez pas besoin d'attendre un audit complet pour agir. Gardez la checklist de 30 secondes sous la main (Tab, Échap, focus visible, ordre logique) et repassez-la à chaque évolution de votre bandeau. Pour ancrer le tout dans le référentiel, la fiche du critère 12.9 détaille les tests officiels, et notre article sur les pièges au clavier vous montre les autres endroits du site où le même défaut se cache. Un bandeau bien conçu, c'est une porte d'entrée accessible, pas un mur.