Conformité d'accessibilité WCAG 2.1
Nous concevons les composants de notre Consent Management Platform (CMP) pour répondre par défaut aux normes d’accessibilité WCAG 2.1 niveau AA. Cependant, lorsque vous appliquez des styles personnalisés — en particulier à l’aide de CSS personnalisé — il existe un risque d’introduire involontairement des problèmes d’accessibilité.
Ce guide présente des bonnes pratiques adaptées à la fois aux utilisateurs non techniques et utilisateurs techniques afin de vous aider à garantir que votre notice personnalisée reste conforme.
Didomi n’est pas expert en accessibilité et ne peut pas fournir de conseils spécifiques en matière d’accessibilité. Les informations non exhaustives de cette page sont fournies à titre informatif uniquement et ont pour but de vous aider à identifier les problèmes courants et à démarrer. Pour une évaluation fiable et une remédiation des problèmes d’accessibilité, veuillez consulter un partenaire qualifié en accessibilité.
Pour les utilisateurs non techniques
Ce sont des recommandations générales pour toute personne qui ajuste les paramètres via la Console Didomi ou les options de branding sans écrire de code ni de CSS.
✅ Utilisez des couleurs à contraste élevé
Choisissez des couleurs de texte et d’arrière-plan présentant un contraste suffisant :
Texte normal : rapport de contraste de 4,5:1
Grand texte (18 pt ou 14 pt en gras) : rapport de contraste de 3:1
Utilisez des outils gratuits comme WebAIM Contrast Checker pour tester.
✅ Gardez une police lisible
Évitez les polices trop décoratives. Utilisez des polices lisibles sans empattement (par exemple Arial, Helvetica). Assurez-vous que la taille de police est d’au moins 16 px pour le texte principal.
✅ Testez uniquement au clavier
Essayez de naviguer dans votre notice en utilisant uniquement les Tab et Enter touches. Tous les boutons et options doivent être accessibles et actionnables de cette manière.
✅ Rendez-la adaptée aux mobiles
Assurez-vous que votre notice s’affiche clairement sur les petits écrans. Le texte ne doit pas être tronqué ni trop petit pour être lu.
✅ Regroupez et étiquetez clairement les options
Utilisez des libellés descriptifs pour les finalités et les fournisseurs. Évitez les termes vagues comme « Option 1 » ou « Cliquez ici ».
Pour les utilisateurs techniques et les développeurs
Si vous appliquez custom CSS ou développez des intégrations, vous devez redoubler de prudence afin de préserver l’accessibilité.
🎨 1. Maintenir le contraste des couleurs
Évitez d’utiliser du CSS qui modifie les couleurs sans vérifier le contraste. Exemple :
Correctif : Testez les paires de couleurs pour vérifier leur conformité WCAG avant de les appliquer.
⌨️ 2. Préserver les styles de focus
Ne supprimez pas les contours de focus utilisés pour la navigation au clavier.
Correctif :
Au lieu de le supprimer, personnalisez-le selon votre marque :
🧭 3. Utiliser un HTML sémantique
Évitez de remplacer des éléments sémantiques par des conteneurs non standards (par exemple, <div> au lieu de <button>). Si vous devez utiliser des éléments personnalisés, ajoutez les rôles et libellés ARIA de manière appropriée.
🧪 4. Utiliser des outils de test
Validez votre implémentation finale avec :
Lighthouse (dans Chrome DevTools)
Axe DevTools
NVDA ou VoiceOver pour les tests avec lecteur d’écran
Navigation uniquement au clavier
🚨 5. Éviter de masquer des éléments essentiels
Si vous utilisez du CSS pour masquer des composants (par exemple des modales, des superpositions), assurez-vous qu’ils ne sont masqués que visuellement (display: none) et non complètement retirés de l’arborescence d’accessibilité, sauf si cela est voulu.
📋 Liste de contrôle rapide pour les développeurs
Élément
OK ?
Contraste des couleurs suffisant
☐
Styles de focus préservés
☐
Utilise du HTML sémantique ou ARIA
☐
Entièrement navigable au clavier
☐
Adapté aux mobiles
☐
Testé avec des lecteurs d’écran / outils
☐
Mis à jour