Audit RGAA Drupal : ce qu'on trouve, et comment le corriger
Drupal est l'un des CMS les plus présents dans le secteur public français et parmi les grandes institutions européennes, justement parce qu'il prend l'accessibilité au sérieux dès le cœur. Mais un cœur soigné ne protège pas des thèmes sur mesure et des centaines de modules contribués qui composent un vrai site. C'est là que se jouent la plupart des non-conformités RGAA, et, depuis le 28 juin 2025, des sanctions EAA pour les sites Drupal exploités en B2C (DGCCRF : 7 500 € pour un premier manquement, 15 000 € en cas de récidive).
Drupalest-il accessible par défaut ?
Drupal est l'un des rares CMS à avoir inscrit l'accessibilité dans sa gouvernance : le cœur suit WCAG 2.1 AA et l'administration elle-même est conçue pour être utilisable au clavier et au lecteur d'écran. Concrètement, un site Drupal vierge part avec de bonnes bases. Mais l'accessibilité réelle dépend du thème front, des modules contribués installés et du contenu saisi par les rédacteurs, qui échappent à ces garanties. Un site Drupal n'est donc jamais conforme par défaut : il l'est uniquement si le thème et les composants ajoutés le restent.
Les atouts
- Un CMS « Accessibility-First » : le cœur Drupal est testé rigoureusement contre les régressions pour maintenir une conformité WCAG 2.1 AA native.
- Back-office inclusif : les thèmes d'administration (Claro, Gin) sont pensés pour les contributeurs, garantissant une gestion de contenus accessible.
- Puissance sémantique : le Render API (Twig) génère nativement des structures HTML5 propres, facilitant l'implémentation des critères RGAA sur le balisage.
- Communauté active : une équipe dédiée et un système de gatekeeper interdisent toute mise à jour majeure du noyau qui dégraderait l'accessibilité existante.
- Gestion fine des alternatives : le framework permet de configurer des champs dédiés pour distinguer les images informatives des images décoratives.
Les points de vigilance
- L'illusion de la conformité : le déploiement par défaut est souvent confondu avec un audit complet, laissant croire à tort que le site est conforme sans effort supplémentaire.
- Risque des modules contrib : de nombreux modules tiers cruciaux n'ont pas les mêmes tests que le noyau et peuvent introduire des blocages.
- Complexité des thèmes custom : la surcharge automatique des templates Twig sans expertise A11y est la cause numéro un d'échec sur les critères 1.3.1 et 2.4.7.
- Composants dynamiques : l'abus de sliders ou galeries complexes provenant de modules externes fragilise fréquemment le respect des critères de navigation au clavier (2.1.1).
- Discipline éditoriale requise : sans Verrouillage de CKEditor 5 (couleurs, styles), les contributeurs dégradent rapidement la sémantique originelle du contenu.
Checklist pour Drupal
- Auditer en priorité la hiérarchie des niveaux de titres (H1-H6) générée par les vues et les blocs via Twig.
- Forcer l'utilisation de balises sémantiques header, nav, main et footer dans les templates page.html.twig.
- Configurer CKEditor 5 pour restreindre l'édition riche aux styles autorisés et supprimer les contrôles de couleurs CSS non conformes.
- Paramétrer le champ image pour obliger la saisie d'un texte alternatif ou cocher une case « image décorative » (critère 1.2).
- Valider que tous les éléments interactifs possèdent un état focus visible, contrasté et conforme aux directives du design system.
- Installer le module Inline Form Errors (Core) pour rendre la gestion des erreurs de formulaires conforme au critère 3.3.1.
- Neutraliser l'accessibilité des modules tiers non testés ou injecter les correctifs ARIA nécessaires (critère 4.1.2) après audit.
- Tester systématiquement la navigation au clavier sur les composants complexes (menus, carrousels) avec NVDA et VoiceOver.
Un thème ou une extension « accessible » ne suffit jamais à rendre un site conforme. Seul un audit du site réel — avec vos contenus, vos modules et vos parcours — permet de viser la conformité (déclaration d'accessibilité, schéma pluriannuel). En savoir plus sur l'audit.
Testez l’accessibilité de votre site, gratuitement
Vérifiez en moins d'une minute les premiers écarts d'accessibilité de votre site Drupal.
Lancer le diagnostic gratuitPour aller plus loin
L'accessibilité sur les autres CMS
Les écarts RGAA diffèrent d'une plateforme à l'autre. Voici le même état des lieux pour les solutions comparables à Drupal.
Questions sur l'accessibilité Drupal
- Drupal est-il conforme RGAA par défaut ?
- Non. Le noyau Drupal est techniquement très avancé, mais la conformité RGAA dépend de la qualité de votre thème, de vos développements spécifiques et de la saisie des contenus par les éditeurs.
- Mon site Drupal privé risque-t-il des sanctions EAA ?
- Oui, avec l'EAA applicable depuis le 28 juin 2025, les services numériques privés doivent respecter des exigences d'accessibilité. La DGCCRF peut infliger des amendes : 7 500 € pour un premier manquement et jusqu'à 15 000 € en cas de récidive.
- Quel est l'impact des modules contrib sur l'accessibilité ?
- Ils constituent le risque principal. Un module riche en fonctionnalités (sliders, formulaires complexes) peut introduire des erreurs de balisage ou de navigation au clavier qui invalident l'ensemble du site.
- Comment garantir une hiérarchie de titres correcte ?
- Utilisez le template page.html.twig pour définir un H1 unique et configurez CKEditor pour que les éditeurs ne puissent utiliser que les balises H2 à H6, garantissant ainsi une structure logique sans saut.
- L'éditeur CKEditor 5 pose-t-il problème ?
- Il est puissant mais doit être verrouillé via la configuration pour empêcher les contributeurs de briser la sémantique, notamment sur la gestion des liens explicites (critère WCAG 2.4.4) et des tableaux (critère WCAG 1.3.1).
- Pourquoi éviter le « div-itis » dans mes templates Twig ?
- Le surplus de conteneurs div invisibles alourdit le DOM et brouille la structure sémantique requise par les lecteurs d'écran pour le critère 1.3.1 (info et relations).