vendredi 25 septembre 2026

À propos

Contact

Accessibilité

Construire une bannière de cookies accessible au clavier et aux lecteurs d’écran

Presque tous les sites en affichent une, peu la rendent réellement utilisable au clavier. Voici comment construire une bannière de consentement accessible, sans piéger le reste du site.

Par Clément Hadrot • 17 janvier 2022 • 4 min de lecture • Aucun commentaire
Construire une bannière de cookies accessible au clavier et aux lecteurs d'écran

La bannière de consentement aux cookies s’affiche sur la quasi-totalité des sites depuis l’entrée en application du RGPD, souvent injectée par un plugin ou un script tiers de gestion du consentement. Beaucoup de ces implémentations, y compris certaines proposées par des solutions payantes réputées, gèrent mal deux aspects pourtant simples : le focus clavier à l’ouverture, et la restauration du focus une fois le choix effectué. Sans plugin dédié pour ce projet associatif, nous avons construit notre propre bannière, en traitant le sujet du consentement et celui de l’accessibilité comme deux exigences également non négociables.

Une bannière de cookies qui bloque l’intégralité du site tant qu’aucun choix n’est fait se comporte, du point de vue de l’accessibilité, exactement comme une fenêtre modale : elle doit donc suivre les mêmes règles de piégeage et de restauration du focus qu’une modale classique.

La structure HTML

<div id="banniere-cookies" role="dialog" aria-modal="true" aria-labelledby="cookies-titre" aria-describedby="cookies-description">
  <h2 id="cookies-titre">Gestion des cookies</h2>
  <p id="cookies-description">
    Nous utilisons des cookies de mesure d'audience et, si vous l'acceptez, des cookies publicitaires.
  </p>
  <div class="cookies-actions">
    <button type="button" id="cookies-refuser">Refuser</button>
    <button type="button" id="cookies-personnaliser">Personnaliser</button>
    <button type="button" id="cookies-accepter">Tout accepter</button>
  </div>
</div>

aria-modal="true" indique aux technologies d’assistance que le reste de la page est temporairement inaccessible tant que la bannière est affichée — un signal qui doit être accompagné, côté script, d’un véritable piégeage du focus, sans quoi l’attribut seul reste un mensonge.

Piéger le focus à l’intérieur de la bannière

L'essentiel à retenir : role=dialog et un focus posé à l'ouverture ; Piéger le focus tant que la bannière est modale ; Restaurer le focus après le choix de l'utilisateur
const banniere = document.getElementById('banniere-cookies');
const elementsFocusables = banniere.querySelectorAll('button');
const premier = elementsFocusables[0];
const dernier = elementsFocusables[elementsFocusables.length - 1];

premier.focus();

banniere.addEventListener('keydown', (event) => {
  if (event.key !== 'Tab') return;
  if (event.shiftKey && document.activeElement === premier) {
    event.preventDefault();
    dernier.focus();
  } else if (!event.shiftKey && document.activeElement === dernier) {
    event.preventDefault();
    premier.focus();
  }
});

Ce piégeage boucle le focus entre le premier et le dernier bouton de la bannière : impossible d’en sortir par tabulation tant qu’aucun choix n’a été fait, ce qui empêche un utilisateur au clavier de se retrouver par erreur à naviguer dans le reste du site alors qu’un bandeau de consentement, invisible à l’écran pour lui, bloque toujours l’interaction réelle.

Restaurer le focus après le choix

function validerChoix(consentement) {
  enregistrerConsentement(consentement);
  banniere.remove();
  document.body.focus();
  document.querySelector('h1').setAttribute('tabindex', '-1');
  document.querySelector('h1').focus();
}

document.getElementById('cookies-accepter').addEventListener('click', () => validerChoix('total'));
document.getElementById('cookies-refuser').addEventListener('click', () => validerChoix('refuse'));

Une fois le choix effectué, la bannière disparaît du DOM et le focus est redirigé vers le titre principal de la page — pas laissé livré à lui-même sur <body>, ce qui reproduirait exactement le défaut de focus perdu que l’on rencontre sur les fenêtres modales mal fermées.

Le panneau de personnalisation

Le bouton « Personnaliser » ouvre un second niveau, avec des cases à cocher par finalité (mesure d’audience, publicité, réseaux sociaux), chacune avec son propre <label> explicite. Ce second panneau suit exactement les mêmes règles de piégeage de focus que la bannière initiale, puisqu’il s’agit d’un nouveau contexte modal à part entière.

Ce qu’il faut éviter absolument

  • Une bannière fixe en bas d’écran qui reste dans le flux de tabulation normal sans jamais piéger le focus : un utilisateur au clavier peut alors interagir avec le contenu masqué en arrière-plan sans même savoir que la bannière existe.
  • Un bouton de fermeture qui ne correspond à aucun choix réel (ni accepté, ni refusé) : au-delà du problème de conformité RGPD, cela laisse l’utilisateur dans un état ambigu.
  • Un contraste insuffisant sur les boutons secondaires, souvent traités visuellement comme moins importants alors qu’ils portent un choix tout aussi légitime que le bouton d’acceptation globale.

En résumé

Une bannière de cookies accessible n’est jamais qu’une fenêtre modale de plus, avec les mêmes exigences de piégeage et de restauration du focus. La contrainte réglementaire du consentement ne dispense en rien de ces règles, bien au contraire : c’est souvent l’un des tout premiers éléments interactifs qu’un visiteur rencontre sur un site.

Partager :

À propos de l'auteur

Clément Hadrot

Développeur WordPress, passionné par Elementor, le FSE et l’automatisation par IA.

Voir tous ses articles

Dans la même veine

À lire aussi