Pourquoi l'accessibilité et le consentement se chevauchent désormais

Le RGPD exige que le consentement soit obtenu de chaque utilisateur, pas seulement de ceux qui peuvent voir et cliquer sur une bannière. Le Comité européen de la protection des données a précisé que si une personne concernée ne peut pas interagir de manière significative avec l'interface de consentement — en raison d'un handicap que le site n'a pas pris en compte — le consentement n'est pas valablement obtenu. Cela signifie que les cookies n'auraient jamais dû se charger.

Du côté de l'accessibilité, la loi européenne sur l'accessibilité (EAA), transposée en droit national dans tous les États membres de l'UE, fait du WCAG 2.1 AA le minimum pour les sites web et applications du secteur privé proposant des services aux consommateurs. Le régime de sanctions varie selon les pays, mais se situe généralement entre 50 000 et 500 000 euros par infraction, plus des ordonnances de retrait du marché en cas de non-conformité persistante.

Les exigences essentielles du WCAG pour les bannières de cookies

Opérabilité au clavier

Chaque contrôle de bannière — Accepter, Refuser, Gérer les préférences, fermer — doit être accessible et utilisable avec le clavier uniquement. Les utilisateurs doivent pouvoir naviguer entre les boutons dans un ordre logique avec Tab et les activer avec Enter ou Space. Le focus doit être visible avec un rapport de contraste minimum de 3:1 par rapport à l'arrière-plan.

Piégeage du focus dans les bannières modales

Si la bannière bloque l'interaction avec le reste de la page, le focus du clavier doit être piégé à l'intérieur de la bannière jusqu'à ce que l'utilisateur fasse un choix. Les utilisateurs ne doivent pas pouvoir appuyer sur Tab pour sortir de la bannière et faire défiler la page sous-jacente. Lorsque le focus était piégé et que la bannière se ferme, le focus doit revenir à l'élément qui a déclenché la bannière ou à un élément par défaut sensé.

Annonces du lecteur d'écran

La bannière doit être annoncée comme une boîte de dialogue avec un nom et un rôle accessibles. Utilisez `role="dialog"` ou `role="alertdialog"` avec `aria-labelledby` pointant vers le titre de la bannière et `aria-describedby` pointant vers le texte explicatif.

Contraste des couleurs

Le texte du corps doit satisfaire un contraste de 4,5:1 par rapport à l'arrière-plan ; le texte large (18pt+ ou 14pt gras) nécessite 3:1. Le texte des boutons, les icônes et les indicateurs de focus ont tous leurs propres minimums de contraste. Un bouton « Refuser » gris clair sur fond blanc est un échec WCAG fréquent que nous observons lors des audits.

Pas d'indices basés uniquement sur la couleur

Ne vous fiez pas uniquement à la couleur pour différencier Accepter de Refuser. Utilisez des libellés, des icônes ou des formes distincts pour que les utilisateurs daltoniens puissent distinguer les boutons.

Schémas obscurs et accessibilité

Le WCAG 2.2 introduit de nouveaux critères qui ciblent directement les schémas obscurs — particulièrement pertinents pour le consentement :

• 3.3.8 Authentification accessible — interdit les énigmes cognitives comme friction de consentement.
• 3.3.7 Saisie redondante — les utilisateurs ne devraient pas avoir à ressaisir des informations juste pour retirer leur consentement.
• 2.4.11 Focus non obscurci — la bannière elle-même ne doit pas obscurcir l'indicateur de focus des éléments derrière elle.
• 2.5.7 Mouvements de glissement — si votre bannière utilise une interaction glisser-pour-accepter, une alternative à pointeur unique doit exister.

RTL et internationalisation

L'accessibilité s'étend aux langues de droite à gauche (arabe, hébreu, persan, ourdou) et à la prononciation des lecteurs d'écran :

• Définissez `dir="rtl"` sur la bannière lorsque la langue du document est RTL pour que l'ordre des boutons et le flux de focus correspondent à la direction de lecture.
• Utilisez les attributs `lang` corrects sur le contenu de la bannière traduite afin que les lecteurs d'écran prononcent les mots avec la bonne phonétique.
• Miroir de l'iconographie — les chevrons, flèches et indicateurs de progression doivent s'inverser pour les locales RTL.

Tester votre bannière pour la conformité WCAG

Ne vous fiez pas à un seul outil. Combinez l'analyse automatisée avec des tests de technologie d'assistance réels :

• axe DevTools ou Lighthouse — détecte automatiquement environ 30 à 40 % des échecs WCAG.
• NVDA ou JAWS sur Windows, VoiceOver sur Mac/iOS, TalkBack sur Android — testez avec de vrais lecteurs d'écran. La bannière peut-elle être annoncée, parcourue et rejetée en utilisant uniquement le lecteur d'écran ?
• Navigation au clavier uniquement — débranchez votre souris. Si vous ne pouvez pas Accepter, Refuser et gérer les préférences, les utilisateurs au clavier non plus.
• Simulation du daltonisme — Chrome DevTools dispose de simulateurs intégrés de déficiences visuelles. Vérifiez qu'Accepter et Refuser sont distinguables en cas de protanopie, deutéranopie et tritanopie.
• Zoom à 400 % — le WCAG exige que le contenu reste utilisable à 400 % de zoom sans défilement horizontal. Les bannières en position fixe échouent souvent à ce test.

Échecs d'accessibilité courants que nous observons

• Refuser caché derrière une icône en forme d'engrenage — schéma obscur plus échec d'accessibilité (pas de nom accessible sur le bouton icône).
• Le focus n'atteint jamais la bannière — des bannières qui volent l'attention visuelle mais sont ignorées dans l'ordre Tab.
• Bannière modale sans piège de focus — les utilisateurs peuvent appuyer sur Tab pour accéder à la page en arrière-plan pendant que la bannière prétend bloquer l'interaction.
• Pas de `aria-live` sur les changements de préférences — les utilisateurs de lecteur d'écran n'entendent pas la confirmation que leur choix a été enregistré.
• Bannières traduites sans attribut `lang` — les lecteurs d'écran prononcent le contenu espagnol avec une phonétique anglaise.

Comment FlexyConsent offre l'accessibilité