Mon site Drupal est-il conforme au RGAA parce que le cœur l'est ?

Non. Le cœur Drupal vise WCAG 2.1 AA, mais votre conformité dépend du thème, des modules contribués et du contenu. La conformité RGAA s'évalue sur les pages réellement livrées, pas sur les promesses du CMS.

Drupal est-il un bon choix pour le secteur public soumis au RGAA ?

Oui, c'est un choix solide : sa gouvernance accessibilité et son back-office utilisable au clavier facilitent le travail. Mais cela ne dispense pas d'un audit du thème, des modules et de la formation des contributeurs.

L'European Accessibility Act concerne-t-il mon site Drupal ?

L'EAA s'applique depuis le 28 juin 2025 à de nombreux services numériques privés (commerce en ligne, banque, transport, etc.). Si vous y êtes soumis, un thème dit accessible ne suffit pas : il faut prouver la conformité du site complet.

Accessibilité Drupal : où en est vraiment votre site ?

Drupal est l'un des CMS les plus présents dans le secteur public français, 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.

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

Le cœur Drupal vise WCAG 2.1 AA et son back-office (administration, formulaires, messages d'état) est lui-même conçu pour être accessible, ce qui aide les contributeurs en situation de handicap.
Le système de rendu (Twig, Render API) génère un HTML sémantique propre et permet de maîtriser finement le balisage, les attributs ARIA et l'ordre du DOM.
Drupal gère nativement les régions de zones de page (landmarks), les messages d'alerte via aria-live et les liens d'évitement, facilitant le respect de plusieurs critères RGAA.
L'écosystème propose des modules dédiés (par exemple Editoria11y pour signaler les erreurs au rédacteur, ou CKEditor Accessibility Checker) pour outiller la chaîne éditoriale.

Les points de vigilance

Les thèmes sur mesure ou achetés introduisent l'essentiel des problèmes : contrastes insuffisants, focus clavier invisible, ordre de tabulation incohérent et composants interactifs (menus déroulants, onglets, carrousels) non pilotables au clavier.
Les modules contribués sont de qualité d'accessibilité très inégale : un module de vues, de mise en page (Layout Builder), de pop-in ou de slider peut produire un balisage non sémantique ou des éléments non annoncés par le lecteur d'écran.
Webform, très utilisé, génère des formulaires corrects de base, mais les configurations avancées (champs conditionnels, messages d'erreur, regroupements fieldset) sont souvent mal reliées aux champs et cassent les critères RGAA sur les formulaires.
L'éditeur CKEditor laisse les rédacteurs produire des titres non hiérarchisés, des liens peu explicites et des images sans alternative pertinente : le cœur est accessible, le contenu saisi ne l'est pas forcément.
Les médias et fichiers (vues en grille, galeries, PDF déposés) ajoutent des images décoratives mal déclarées et des documents non accessibles qui pèsent dans l'audit final.

Checklist pour Drupal

Auditer en priorité le thème front : navigation clavier complète, focus visible, contrastes et comportement des composants JavaScript (menus, modales, onglets).
Faire l'inventaire des modules contribués et vérifier le HTML qu'ils génèrent réellement en page, pas seulement leur réputation.
Contrôler chaque formulaire Webform : labels associés, regroupements fieldset/legend, restitution des erreurs et champs conditionnels annoncés.
Configurer l'éditeur (CKEditor) pour cadrer les rédacteurs : niveaux de titres disponibles, texte alternatif obligatoire, et activer un vérificateur comme Editoria11y.
Mettre en place une procédure pour les documents (PDF, bureautique) déposés via les champs média, qui relèvent aussi du RGAA.
Tester sur un parcours réel au clavier et avec NVDA, plutôt que de se fier au seul label accessible du cœur Drupal.

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 gratuit

Pour aller plus loin

Questions sur l'accessibilité Drupal

Mon site Drupal est-il conforme au RGAA parce que le cœur l'est ?: Non. Le cœur Drupal vise WCAG 2.1 AA, mais votre conformité dépend du thème, des modules contribués et du contenu. La conformité RGAA s'évalue sur les pages réellement livrées, pas sur les promesses du CMS.
Drupal est-il un bon choix pour le secteur public soumis au RGAA ?: Oui, c'est un choix solide : sa gouvernance accessibilité et son back-office utilisable au clavier facilitent le travail. Mais cela ne dispense pas d'un audit du thème, des modules et de la formation des contributeurs.
L'European Accessibility Act concerne-t-il mon site Drupal ?: L'EAA s'applique depuis le 28 juin 2025 à de nombreux services numériques privés (commerce en ligne, banque, transport, etc.). Si vous y êtes soumis, un thème dit accessible ne suffit pas : il faut prouver la conformité du site complet.