Une bannière cookies est souvent la première interface interactive rencontrée en arrivant sur un site. Si elle est inaccessible, le problème apparaît donc avant même que le visiteur puisse réellement utiliser le contenu.
La question ne se limite pas à ajouter quelques attributs ARIA. Une bannière accessible doit pouvoir être comprise et utilisée au clavier, conserver un focus visible, proposer des contrastes suffisants et rester cohérente avec un lecteur d’écran.
Il faut également conserver ces propriétés après personnalisation. Une CMP peut fournir une interface accessible par défaut puis devenir beaucoup moins utilisable après quelques lignes de CSS.
Une bannière cookies est une véritable interface
Un bandeau de consentement contient généralement plusieurs composants interactifs : boutons d’acceptation et de refus, accès aux préférences, catégories, services individuels et mécanisme permettant de fermer ou rouvrir le panneau.
Il faut donc le traiter comme n’importe quelle autre interface du site.
Un visiteur qui ne peut pas utiliser une souris doit pouvoir atteindre les différentes actions. Une personne utilisant un lecteur d’écran doit pouvoir comprendre leur fonction. Un utilisateur malvoyant doit pouvoir distinguer les textes et les composants interactifs.
Le fait que l’interface ne soit affichée que quelques secondes ne réduit pas ces besoins. Au contraire, son caractère bloquant ou très visible peut rendre une mauvaise accessibilité particulièrement gênante.
Tout doit commencer par le clavier
Le test le plus simple consiste à poser la souris et à utiliser uniquement la touche Tab.
Les éléments interactifs doivent pouvoir être atteints dans un ordre logique. Maj+Tab doit permettre de revenir en arrière. Les boutons doivent pouvoir être activés au clavier.
Il ne devrait jamais être nécessaire de cliquer avec une souris pour refuser les cookies, ouvrir les préférences ou valider une sélection.
Ce test est extrêmement simple et détecte déjà beaucoup de problèmes d’accessibilité.
Le focus doit rester visible
Pouvoir atteindre un bouton au clavier ne suffit pas si rien ne permet de savoir quel élément est actuellement sélectionné.
Le focus doit rester visuellement identifiable. Supprimer globalement les outline avec du CSS sans fournir d’alternative est donc une très mauvaise idée.
Le contraste et la visibilité du focus sont particulièrement importants dans une interface comprenant plusieurs boutons proches les uns des autres.
Les WCAG accordent d’ailleurs une attention particulière au focus, notamment à sa visibilité et au fait qu’un élément recevant le focus ne soit pas masqué par un autre contenu.
Attention au focus lors de l’ouverture du panneau
Les panneaux de gestion détaillée ajoutent une difficulté supplémentaire.
Lorsqu’une interface assimilable à une boîte de dialogue s’ouvre, le comportement du focus doit rester cohérent. L’utilisateur ne doit pas continuer à tabuler dans des éléments invisibles situés derrière le panneau sans comprendre ce qui se passe.
À la fermeture, il est également utile que la navigation reste prévisible plutôt que de replacer arbitrairement l’utilisateur au début de la page.
Ces détails paraissent secondaires avec une souris. Au clavier ou avec certaines technologies d’assistance, ils changent complètement l’utilisation de l’interface.
Les boutons doivent avoir un sens compréhensible
Un lecteur d’écran ne bénéficie pas nécessairement de toutes les informations visuelles utilisées pour comprendre l’interface.
Les boutons et contrôles doivent donc disposer d’un nom accessible cohérent avec leur fonction.
Un pictogramme seul peut être évident visuellement et totalement ambigu lorsqu’il est annoncé sans contexte. C’est particulièrement vrai pour le bouton permettant de rouvrir le panneau de gestion du consentement.
Les éléments HTML natifs restent généralement une excellente base. Un véritable <button> possède déjà un comportement clavier et une sémantique que l’on devrait éviter de reconstruire inutilement avec un <div>.
Le contraste concerne les textes mais aussi l’interface
Une bannière très discrète peut être jolie tout en étant difficile à lire.
Le texte doit conserver un contraste suffisant avec son arrière-plan. Les composants nécessaires à la compréhension de l’interface doivent également rester perceptibles.
Les problèmes apparaissent souvent après personnalisation : texte gris clair, bouton secondaire presque invisible, contour supprimé ou couleur de focus trop proche de l’arrière-plan.
Une identité graphique ne devrait pas rendre le refus ou la gestion des préférences difficile à percevoir.
Accessibilité et consentement se rejoignent parfois
Une interface de consentement accessible doit permettre de comprendre et d’utiliser les différents choix. Une interface de consentement honnête doit également éviter de pousser artificiellement vers l’un d’entre eux.
Les deux sujets ne sont pas identiques, mais ils se croisent souvent.
Un bouton "Tout accepter" énorme et très contrasté accompagné d’un refus gris presque invisible est à la fois une mauvaise décision d’interface et un problème pour la qualité du choix proposé.
La CNIL rappelle que refuser les traceurs doit être aussi facile que les accepter. L’accessibilité ne doit donc pas devenir un prétexte pour rendre une action techniquement disponible mais pratiquement difficile à trouver.
La personnalisation peut casser une interface accessible
Avec tarteaucitron, il est possible de modifier très largement l’apparence du bandeau. Les couleurs et différentes options sont accessibles depuis la console Pro, du CSS peut être ajouté et l’interface reste constituée de HTML, CSS et JavaScript classiques.
Cette liberté implique aussi une responsabilité.
Une règle CSS peut supprimer le focus. Une couleur personnalisée peut rendre un texte illisible. Un élément repositionné peut masquer un bouton sur mobile. Une modification JavaScript peut perturber l’ordre de navigation.
Il faut donc retester l’accessibilité après une personnalisation importante plutôt que considérer que les propriétés de l’interface d’origine sont automatiquement conservées.
Le zoom et les petits écrans sont faciles à oublier
Une bannière doit également rester utilisable lorsque l’espace disponible diminue.
Sur mobile ou avec un niveau de zoom important, les boutons peuvent passer sur plusieurs lignes et le contenu devenir plus haut que l’écran.
Il faut alors vérifier que toutes les actions restent accessibles, que le contenu peut défiler correctement et qu’aucun bouton important n’est placé hors de la zone atteignable.
Une interface parfaitement utilisable sur un écran desktop de 27 pouces peut devenir très problématique sur un téléphone ou avec un zoom important.
Tester avec un lecteur d’écran apporte une autre vision
Le test clavier est une excellente première étape, mais il ne permet pas de détecter tous les problèmes.
Utiliser VoiceOver sur macOS ou iOS, NVDA sous Windows ou un autre lecteur d’écran permet d’entendre réellement la manière dont les composants sont annoncés.
Les titres, groupes de choix, états des boutons et contrôles doivent rester compréhensibles sans avoir besoin de voir leur position dans la page.
Il n’est pas nécessaire d’être un expert quotidien des lecteurs d’écran pour découvrir des erreurs évidentes. Quelques minutes suffisent souvent à repérer un bouton sans nom ou une structure incompréhensible.
Une checklist simple pour tester une CMP
- Ouvrir le site sans utiliser la souris.
- Parcourir toutes les actions avec Tab et Maj+Tab.
- Vérifier que le focus reste toujours visible.
- Accepter, refuser puis personnaliser les services uniquement au clavier.
- Vérifier le comportement lors de l’ouverture et de la fermeture du panneau détaillé.
- Tester avec un zoom important et sur un petit écran.
- Contrôler les contrastes après toute personnalisation graphique.
- Faire au moins un passage avec un lecteur d’écran.
Ce test ne remplace pas un audit d’accessibilité complet, mais il permet déjà d’éliminer de nombreux problèmes très concrets.
L’accessibilité ne devrait pas être une option de la CMP
Je considère l’accessibilité comme une propriété normale d’une interface de consentement, pas comme une fonctionnalité premium à activer.
tarteaucitron évolue régulièrement sur ces sujets, notamment grâce aux retours et contributions de développeurs spécialisés qui utilisent le projet open source.
C’est également l’un des avantages que je trouve au développement public du projet : une amélioration apportée pour un besoin d’accessibilité peut bénéficier à tous les utilisateurs.
Une CMP sert à demander un choix. La condition minimale est donc que tout le monde puisse réellement effectuer ce choix.
