RGAA & Accessibilité Drupal : mettre votre site en conformité en 2026

Votre site Drupal est en ligne depuis plusieurs années. Vos équipes maîtrisent le CMS, les performances sont au rendez-vous, et la sécurité a été auditée. Mais une question reste souvent sans réponse précise dans les comités de direction : sommes-nous conformes au RGAA ?

En 2026, cette question n'est plus facultative. La loi impose des obligations d'accessibilité numérique à un périmètre croissant d'organisations publiques et privées — avec des sanctions à la clé. Et pour les Directeurs Marketing, l'accessibilité représente aussi un levier SEO sous-exploité : Google intègre de plus en plus les signaux d'accessibilité dans son évaluation de la qualité des pages.

Ce guide s'adresse aux DSI et Directeurs Marketing qui gèrent un site Drupal et doivent répondre à deux questions concrètes :

Quelles sont nos obligations légales au titre du RGAA 4.1 ?
Comment Drupal nous aide-t-il — ou nous freine-t-il — à les remplir ?

Il couvre les obligations légales, les modules Drupal dédiés (Editoria11y, Sa11y), le processus d'audit, et se termine par un plan de mise en conformité que vous pouvez adapter à votre contexte.

Comprendre le RGAA 4.1 : obligations et périmètre

Qu'est-ce que le RGAA ?

Le Référentiel Général d'Amélioration de l'Accessibilité (RGAA) est le référentiel officiel français pour l'accessibilité numérique. Sa version 4.1, publiée en 2021, transpose les exigences du niveau AA des WCAG 2.1 (Web Content Accessibility Guidelines) en critères applicables au contexte français.

Le RGAA comporte 106 critères organisés en 13 thématiques : images, cadres, couleurs, multimédia, tableaux, liens, scripts, éléments obligatoires, structuration de l'information, présentation de l'information, formulaires, navigation, consultation.

Chaque critère est accompagné de tests précis, de techniques de vérification, et d'un niveau de conformité (A, AA — le RGAA n'intègre pas le niveau AAA des WCAG).

Qui est concerné par l'obligation légale ?

La loi n°2005-102 du 11 février 2005, renforcée par la directive européenne 2016/2102 et la loi pour une République Numérique, impose la conformité RGAA à :

Obligatoirement depuis 2020 :

Les administrations de l'État, collectivités territoriales, établissements publics
Les entreprises délégataires d'une mission de service public
Les organismes privés dont le chiffre d'affaires annuel excède 250 millions d'euros

Extension progressive : La directive européenne sur l'accessibilité des produits et services (European Accessibility Act, EAA), en cours de transposition en France pour une application à partir de juin 2025, élargit les obligations au secteur privé pour un périmètre plus large de services numériques — notamment le e-commerce, les services bancaires, les transports, et la téléphonie.

Pour les DSI : vérifiez si votre organisation entre dans l'un de ces périmètres. Si c'est le cas, la non-conformité expose à des sanctions administratives et, surtout, à des recours de la part d'usagers handicapés.

Ce que la conformité implique concrètement

Au-delà des critères techniques, la conformité RGAA impose trois obligations organisationnelles :

1. La déclaration d'accessibilité. Tout site concerné doit publier une page "Accessibilité" mentionnant le niveau de conformité atteint, les non-conformités identifiées, et les alternatives disponibles. Cette page doit être accessible depuis le pied de page.

2. Le schéma pluriannuel de mise en accessibilité. Les organismes publics doivent publier un plan sur trois ans détaillant les actions prévues pour atteindre la conformité. Ce plan doit être mis à jour annuellement.

3. La possibilité de signalement. Un mécanisme permettant aux utilisateurs de signaler un problème d'accessibilité et de demander une alternative doit être disponible. Le délai de réponse maximal est de deux jours ouvrés.

L'avantage SEO de l'accessibilité : pourquoi les Directeurs Marketing doivent s'y intéresser

L'accessibilité et le référencement naturel partagent une base commune : rendre l'information compréhensible pour les machines comme pour les humains. Un site conforme WCAG/RGAA est presque toujours mieux indexé qu'un site qui ne l'est pas.

Les signaux d'accessibilité que Google valorise

Le balisage sémantique HTML. Les titres (<h1>, <h2>…), les listes, les tableaux correctement balisés et les landmarks ARIA aident Googlebot à comprendre la structure du contenu. C'est exactement ce que les critères RGAA sur la structuration de l'information exigent.

Les alternatives textuelles aux images. Le critère RGAA 1.1 impose un attribut alt pertinent sur chaque image porteuse de sens. C'est également l'un des facteurs de classement les plus simples à optimiser pour les images dans Google Images.

Les liens explicites. Le RGAA exige que chaque lien ait un intitulé compréhensible hors contexte (fini les "Cliquez ici" ou "En savoir plus"). Des liens bien formulés améliorent le maillage interne et la clarté de la structure pour Googlebot.

La vitesse et la performance. L'accessibilité inclut la possibilité pour les utilisateurs de contrôler les animations, les défilements automatiques et les contenus en mouvement. Les sites qui maîtrisent ces éléments ont généralement de meilleures métriques Core Web Vitals.

La compatibilité mobile. Les sites RGAA-conformes sont rigoureusement testés sur différents contextes (zoom jusqu'à 200 %, orientation portrait/paysage, navigation clavier seule). Ces tests révèlent systématiquement des problèmes qui impactent aussi l'expérience mobile.

L'argument business pour les Directeurs Marketing

En France, 12 millions de personnes vivent avec un handicap. 80 % des handicaps sont invisibles (déficiences visuelles légères, troubles cognitifs, dyslexie, difficultés motrices). Ces utilisateurs représentent un segment de marché que les sites non accessibles excluent de facto.

Au-delà de l'obligation légale, l'accessibilité est un argument de différenciation B2B : vos prospects institutionnels et grands comptes vérifient de plus en plus la conformité de leurs fournisseurs dans leurs appels d'offres. Afficher une déclaration d'accessibilité à jour est un signal de maturité organisationnelle.

Drupal et l'accessibilité : un CMS bien positionné mais pas magique

Ce que Drupal fait nativement

Drupal a une longue histoire d'engagement pour l'accessibilité. L'équipe core maintient des engagements d'accessibilité depuis Drupal 7 :

Drupal core est conforme WCAG 2.1 AA pour l'interface d'administration. C'est un avantage significatif pour les équipes éditoriales qui utilisent des technologies d'assistance.
Les thèmes Drupal core (Olivero, Claro) sont développés avec des standards d'accessibilité stricts. Olivero (le thème front-end par défaut depuis Drupal 9.3) intègre des contrastes de couleurs conformes AA, une navigation clavier cohérente, et des landmarks ARIA.
Les CKEditor 5 (éditeur intégré depuis Drupal 10.1) inclut des contrôles d'accessibilité natifs pour les rédacteurs : avertissements sur les images sans alt, vérification des titres de tableaux, etc.

Ce que Drupal ne fait pas à votre place

La conformité RGAA d'un site Drupal dépend à 80 % de la façon dont il est configuré et dont le contenu est produit — pas du CMS lui-même.

Les problèmes d'accessibilité les plus fréquents sur les sites Drupal que nous auditons :

Thème personnalisé non audité. Le thème front-end a été développé sans référence aux critères WCAG/RGAA. Contrastes insuffisants, focus non visible, ordre de lecture incohérent.
Médias sans alternatives. Les rédacteurs n'ont pas été formés à renseigner les attributs alt, les sous-titres vidéo, ou les transcriptions des fichiers audio.
Formulaires mal balisés. Les champs de formulaire n'ont pas de labels associés (<label for>), les messages d'erreur ne sont pas liés aux champs concernés.
Tableaux de mise en page. Des tableaux HTML utilisés pour la mise en page (sans <th>, sans scope, sans caption) perturbent les lecteurs d'écran.
Composants JavaScript inaccessibles. Accordéons, onglets, modales, sliders — ces composants courants nécessitent une implémentation ARIA précise pour être utilisables au clavier et avec un lecteur d'écran.

Les modules Drupal incontournables pour l'accessibilité

Editoria11y — le vérificateur en temps réel pour les rédacteurs

Editoria11y (drupal/editoria11y) est le module d'accessibilité le plus impactant pour les sites Drupal éditoriaux. Il intègre un panneau de vérification de l'accessibilité directement dans l'interface front-end du site, visible uniquement par les utilisateurs authentifiés ayant les droits appropriés.

Ce qu'il fait :

Détecte en temps réel les problèmes d'accessibilité sur chaque page : images sans alt, titres mal structurés, liens génériques ("cliquez ici"), tableaux sans en-têtes, contrastes insuffisants
Affiche les problèmes directement sur la page, avec un compteur visible dans la barre d'administration Drupal
Fournit des explications pédagogiques et des suggestions de correction — idéal pour former les rédacteurs
Propose un tableau de bord centralisé des erreurs sur l'ensemble du site

Installation :

composer require drupal/editoria11y
drush en editoria11y

Configuration recommandée :

Dans /admin/config/user-interface/editoria11y, configurez :

Rôles qui voient le panneau : limitez aux rédacteurs et administrateurs (pas aux visiteurs)
Mode automatique ou manuel : en mode automatique, le panneau s'ouvre dès qu'une erreur est détectée sur la page
Erreurs ignorées : certaines fausses positives peuvent être masquées par thème ou par élément

Pourquoi c'est stratégique : Editoria11y change les comportements éditoriaux. Les rédacteurs voient immédiatement les conséquences de leur contenu en matière d'accessibilité. Un seul mois d'utilisation réduit significativement le volume d'erreurs dans les nouvelles pages.

Sa11y — l'alternative axée sur les rédacteurs

Sa11y (drupal/sa11y) est un module similaire à Editoria11y, développé par l'université Ryerson. Il propose également un panneau de vérification en temps réel intégré au front-end, avec une approche pédagogique encore plus prononcée.

Ce qui différencie Sa11y d'Editoria11y :

Interface utilisateur plus visuelle, avec des tooltips colorés directement sur les éléments problématiques
Système de "mise en evidence" des éléments : liens, images, titres sont surlignés pour faciliter la vérification manuelle
Panel de contraste de couleurs intégré
Option "mode daltonisme" pour tester différents types de déficiences visuelles
Localisation complète en français

Installation :

composer require drupal/sa11y
drush en sa11y

Quand choisir Sa11y plutôt qu'Editoria11y ? Sa11y est souvent préféré lorsque l'équipe éditoriale est moins technique et bénéficie d'une interface plus visuelle. Editoria11y est plus complet pour le reporting et la gestion centralisée des erreurs. Les deux modules sont compatibles et peuvent coexister si nécessaire.

Autres modules essentiels

Module	Fonction	Cas d'usage
Accessibility Scanner (`drupal/accessibility_scanner`)	Lance des audits automatisés via axe-core ou WAVE sur l'ensemble du site	Rapports périodiques, intégration CI/CD
Media Entity + alt_field	Impose la saisie de l'attribut alt à l'ajout de chaque média	Force les bonnes pratiques éditoriales
CKEditor Accessibility Checker	Plugin CKEditor qui vérifie l'accessibilité du contenu en cours de rédaction	Sites avec rédaction intensive dans l'éditeur wysiwyg
Accessible Menus (`drupal/accessible_menu`)	Améliore l'accessibilité des menus déroulants natifs Drupal	Sites avec navigation complexe, multi-niveaux
Skip Navigation (`drupal/skip_navigation`)	Ajoute des liens "Aller au contenu principal" et "Aller au menu"	Baseline RGAA, exigence WCAG 2.4.1
Responsive Tables (`drupal/responsive_table_filter`)	Rend les tableaux complexes utilisables sur mobile et avec un lecteur d'écran	Sites avec contenu tabulaire dense

Configuration critique : les champs alt obligatoires

L'une des sources les plus fréquentes de non-conformité est l'absence d'alternatives textuelles sur les images. Drupal permet de rendre le champ alt obligatoire au niveau du type de champ image :

Dans /admin/structure/types/manage/[type_contenu]/fields/field_image, cochez "Champ Texte de remplacement (Alt) requis". Cette option force les rédacteurs à renseigner l'alt avant toute sauvegarde.

Pour les images décoratives (n'apportant pas d'information), le RGAA impose un alt="" (vide, pas absent). Formez vos rédacteurs à cette distinction — c'est l'un des critères les plus souvent mal appliqués.

Le processus d'audit RGAA : comment évaluer votre site

Les trois niveaux d'audit

1. L'audit automatisé (première passe)

Les outils automatisés — axe-core, WAVE, Lighthouse, Google Accessibility Insights — détectent environ 30 à 40 % des problèmes d'accessibilité. C'est une première passe rapide, pas un audit complet.

Ces outils détectent avec fiabilité :

Images sans attribut alt
Champs de formulaire sans label
Contrastes de couleurs insuffisants
Absence de langue déclarée sur la page (lang attribute)
Titres manquants ou mal structurés
Erreurs ARIA explicites

Ce qu'ils ne détectent pas : la pertinence des textes alternatifs, la qualité de la navigation au clavier, la cohérence de l'expérience avec un lecteur d'écran, les erreurs dans les documents PDF.

2. L'audit semi-automatisé (échantillon de pages)

La méthodologie RGAA recommande d'auditer un échantillon représentatif du site, pas la totalité des pages. Cet échantillon doit inclure :

La page d'accueil
La page de contact
Les pages de contenu représentatives (article de blog, fiche produit, page institutionnelle)
Les pages avec des formulaires (inscription, devis, contact)
Les pages de connexion et d'espace membre si applicables
La page d'accessibilité et le plan du site

Pour chaque page de l'échantillon, évaluez manuellement les 106 critères RGAA. En pratique, commencez par les thématiques à fort impact : images, formulaires, liens, structuration, couleurs.

3. L'audit avec lecteur d'écran

La validation finale doit inclure des tests avec un lecteur d'écran réel. Les combinaisons standard de référence sont :

NVDA + Firefox ou JAWS + Chrome sur Windows
VoiceOver + Safari sur macOS et iOS

Ces tests révèlent des problèmes qui ne sont détectables ni par les outils automatisés ni par l'inspection manuelle du code : l'ordre de lecture, les annonces dynamiques, la navigation dans les composants complexes (datepickers, autocomplete, sliders).

Calculer le taux de conformité RGAA

Le RGAA définit trois niveaux de conformité :

Non conforme : taux inférieur à 50 %
Partiellement conforme : taux entre 50 % et 99 %
Conforme : 100 % des critères applicables sont respectés

Le taux se calcule sur les critères applicables au site — certains critères (multimédia, captchas) ne s'appliquent que si le type de contenu correspondant est présent sur le site.

Pour la plupart des sites Drupal B2B, l'objectif réaliste d'une première mise en conformité est d'atteindre le niveau partiellement conforme (> 75 %) avec un plan de correction documenté.

Les outils d'audit recommandés

Outil	Type	Usage
axe DevTools (extension Chrome)	Automatisé	Audit page par page avec classification WCAG
WAVE (WebAIM)	Automatisé	Visualisation des erreurs directement sur la page
Lighthouse (Chrome DevTools)	Automatisé	Score d'accessibilité + recommandations
Colour Contrast Analyser (TPGi)	Manuel	Vérification précise des contrastes sur maquettes et captures
NVDA	Lecteur d'écran	Test de référence sur Windows
Accessibility Insights (Microsoft)	Semi-auto	Guidage pas-à-pas pour l'audit manuel

Plan de mise en conformité RGAA pour un site Drupal

Phase 1 — Diagnostic (semaines 1-2)

Objectif : connaître votre niveau de conformité actuel et prioriser les corrections.

Actions :

Lancez un audit automatisé Lighthouse sur les 10 pages les plus visitées. Notez le score d'accessibilité et les types d'erreurs les plus fréquents.
Installez Editoria11y ou Sa11y et demandez aux rédacteurs d'ouvrir les 20 pages les plus importantes : comptabilisez les erreurs remontées.
Réalisez un test de navigation clavier de 30 minutes sur votre site : pouvez-vous tout utiliser sans souris ? (Tab, Entrée, Espace, Flèches suffisent-ils ?)
Testez avec NVDA sur la page d'accueil et un formulaire : l'expérience est-elle cohérente ?

Livrable : tableau des types d'erreurs, leur fréquence, et une estimation du taux de conformité RGAA actuel.

Phase 2 — Corrections rapides (semaines 3-6)

Les "quick wins" — corrections à fort impact, effort faible :

Structuration des titres. Vérifiez que chaque page a un <h1> unique et que la hiérarchie des titres est logique (pas de <h3> sans <h2> précédent). Configurez votre éditeur CKEditor pour guider les rédacteurs.

Alternatives aux images. Activez le champ alt obligatoire sur tous les types d'image. Auditez le stock d'images existantes et corrigez les alt manquants ou génériques ("image", "photo", "img001.jpg").

Liens explicites. Remplacez tous les "Cliquez ici", "En savoir plus", "Lire la suite" par des intitulés complets. En Drupal, configurez les "More link label" dans les vues Views pour qu'ils soient contextuels.

Langue de la page. Vérifiez que l'attribut lang="fr" est présent sur la balise <html> de toutes vos pages. En Drupal, ce comportement est géré nativement selon la langue du nœud.

Focus visible. Supprimez les règles CSS outline: none ou outline: 0 sans alternative. Le focus doit rester visible pour les utilisateurs qui naviguent au clavier.

Déclaration d'accessibilité. Créez la page d'accessibilité requise par la loi, même si votre taux de conformité est encore faible. Publiez honnêtement votre niveau actuel et les actions prévues.

Phase 3 — Corrections structurelles (mois 2-4)

Ces corrections nécessitent un travail de développement :

Audit et refactoring du thème. Passez le thème front-end en revue avec les critères RGAA sur les couleurs (contrastes), la présentation (texte redimensionnable à 200 % sans perte d'information), et les scripts (composants JavaScript accessibles au clavier et aux lecteurs d'écran).

Formulaires. Auditez chaque formulaire du site. Chaque <input> doit avoir un <label> associé. Les messages d'erreur doivent être liés au champ concerné via aria-describedby. Les champs obligatoires doivent être signalés autrement que par la couleur seule.

Composants JavaScript. Accordéons, onglets, modales, menus déroulants — chacun de ces composants a un pattern ARIA défini (WAI-ARIA Authoring Practices Guide). Si votre thème utilise des composants custom, auditez-les un par un.

Documents PDF. Les PDFs liés au site doivent être accessibles (balises, ordre de lecture, texte sélectionnable, pas uniquement des images scannées). Adobe Acrobat Pro ou PAC 3 permettent de vérifier et corriger la structure des PDFs.

Vidéos. Toute vidéo doit être accompagnée de sous-titres synchronisés et d'une transcription textuelle. Pour les vidéos hébergées sur YouTube ou Vimeo, activez les sous-titres et vérifiez leur qualité.

Phase 4 — Formation éditoriale (en parallèle dès le mois 1)

La conformité se dégrade aussi vite qu'elle se construit si les rédacteurs ne sont pas formés.

Programme de formation minimal (2h) :

Les 5 erreurs d'accessibilité les plus courantes dans le CMS
Comment rédiger un alt pertinent (vs. alt vide pour les images décoratives)
Comment structurer les titres dans l'éditeur
Comment nommer un lien de façon explicite
Comment utiliser Editoria11y / Sa11y pour s'auto-corriger

Maintenez cette formation dans votre onboarding pour tous les nouveaux rédacteurs.

Phase 5 — Audit officiel et déclaration finale

Une fois les phases 1 à 4 réalisées, mandatez un audit RGAA officiel par un prestataire habilité. Cet audit produit un rapport avec le taux de conformité final, les non-conformités résiduelles documentées, et les attestations nécessaires à votre déclaration d'accessibilité.

Mettez à jour votre déclaration d'accessibilité en conséquence et publiez votre schéma pluriannuel si vous êtes un organisme soumis à cette obligation.

Checklist de conformité RGAA pour Drupal

Modules et configuration

[ ] Editoria11y ou Sa11y est installé et configuré pour les rédacteurs
[ ] Le champ alt est obligatoire sur tous les types de champ image
[ ] La langue (lang="fr") est correctement configurée pour tous les types de contenu
[ ] CKEditor 5 est configuré pour guider les rédacteurs (boutons de titre, accessibilité checker)
[ ] Les "More link labels" des vues Views sont contextuels

Contenu et rédaction

[ ] Chaque image porteuse d'information a un alt pertinent
[ ] Les images décoratives ont alt=""
[ ] La hiérarchie des titres est logique sur chaque page (un seul H1, pas de saut de niveau)
[ ] Tous les liens ont un intitulé compréhensible hors contexte
[ ] Aucun lien "Cliquez ici", "En savoir plus" ou "Lire la suite" générique
[ ] Les tableaux ont des en-têtes (<th>) et un titre (<caption>)
[ ] Les vidéos ont des sous-titres synchronisés
[ ] Les PDFs liés au site sont accessibles

Thème et développement

[ ] Les contrastes de couleurs respectent le ratio 4.5:1 pour le texte normal (3:1 pour le texte grand)
[ ] Le focus clavier est visible sur tous les éléments interactifs
[ ] La navigation au clavier seul couvre l'ensemble du site
[ ] Les composants JavaScript (accordéons, modales, onglets) implémentent les patterns ARIA
[ ] Le texte reste lisible et le contenu utilisable lors d'un zoom à 200 %
[ ] Le site est utilisable en orientation portrait et paysage

Obligations légales

[ ] La page "Accessibilité" est publiée et accessible depuis le pied de page
[ ] La déclaration d'accessibilité indique le niveau de conformité actuel
[ ] Un mécanisme de signalement des problèmes est disponible
[ ] Le schéma pluriannuel est publié (pour les organismes publics)
[ ] Un audit RGAA officiel a été réalisé ou planifié

Les erreurs les plus fréquentes sur les sites Drupal

Sur les sites que nous auditons chez DrupaLabs, ces problèmes reviennent systématiquement :

1. L'alt "titre de l'image" automatique. Certaines configurations Drupal utilisent le titre du fichier média comme alt par défaut. "DSC_0047.jpg" ou "banniere-homepage" ne sont pas des alternatives textuelles. Désactivez ce comportement et rendez l'alt obligatoire.

2. Les titres utilisés comme mise en forme. Des <h3> ou <h4> choisis pour leur rendu visuel, pas pour leur hiérarchie sémantique. Un lecteur d'écran navigue dans les titres comme dans une table des matières — une hiérarchie incohérente désorganise complètement cette navigation.

3. Les modales sans gestion du focus. Une modale qui s'ouvre sans capturer le focus laisse le lecteur d'écran "derrière" le rideau. Les utilisateurs clavier ne peuvent pas interagir avec le contenu de la modale. Le pattern ARIA dialog doit être implémenté correctement.

4. Le contraste insuffisant sur les états désactivés. Les boutons désactivés (disabled) avec un texte gris clair sur fond blanc passent souvent sous le ratio minimal de 3:1. Les états désactivés ne sont pas exemptés des exigences de contraste RGAA.

5. Les formulaires multi-étapes sans indicateur de progression accessible. Les barres de progression basées uniquement sur la couleur ou la taille ne communiquent rien aux utilisateurs de lecteurs d'écran. L'étape actuelle doit être annoncée textuellement.

RGAA et SEO : le tableau de bord commun

Pour les Directeurs Marketing, voici une vision synthétique des optimisations RGAA qui améliorent simultanément le référencement naturel :

Critère RGAA	Impact SEO	Action
Images avec alt pertinent	Google Images, richesse sémantique	Rendre alt obligatoire, former les rédacteurs
Hiérarchie des titres (H1-H6)	Structure de contenu, featured snippets	Former les rédacteurs, auditer les pages existantes
Liens avec intitulés explicites	Ancres de maillage interne, contexte	Revoir les liens "En savoir plus"
Langue de la page déclarée	Ciblage linguistique, localisation	Vérifier `lang` dans le thème Drupal
Balisage sémantique HTML	Compréhension du contenu par Googlebot	Auditer le thème, utiliser les bons éléments HTML
Performance et Core Web Vitals	Classement direct dans les SERP	Optimiser les animations, contrôler les médias
Compatibilité clavier et navigation	Engagement utilisateur, temps sur site	Corriger le focus, tester la navigation

Par où commencer ?

Si vous partez de zéro, voici l'ordre recommandé pour maximiser l'impact des premières semaines :

Semaine 1 — Installez Editoria11y. Ouvrez vos 10 pages les plus visitées. Comptabilisez les types d'erreurs. Vous avez votre état des lieux initial.

Semaine 2 — Rendez le champ alt obligatoire sur tous les types d'image. Lancez une correction groupée des images existantes sans alt ou avec un alt automatique.

Semaine 3 — Auditez les formulaires. Vérifiez que chaque champ a un label. Testez chaque formulaire au clavier uniquement.

Semaine 4 — Publiez votre déclaration d'accessibilité, même incomplète. Mentionnez votre niveau actuel honnêtement et les actions en cours. C'est une obligation légale, et un document vivant qui évolue avec votre conformité.

Mois 2-4 — Audit du thème, corrections des composants JavaScript, formation des rédacteurs, audit RGAA officiel.

Conclusion : l'accessibilité n'est pas un projet, c'est un état d'esprit

Un site Drupal conforme RGAA en 2026 n'est pas le résultat d'une refonte unique : c'est le produit d'une culture organisationnelle où chaque contributeur — développeur, rédacteur, chef de projet — intègre les critères d'accessibilité dans son travail quotidien.

Les outils existent, Drupal les supporte, les obligations légales sont claires. Ce qui fait la différence, c'est la méthode : commencer par l'état des lieux, prioriser les corrections à fort impact, former les équipes, et maintenir la conformité dans la durée.

Pour les DSI, c'est une réduction du risque juridique et réputationnel. Pour les Directeurs Marketing, c'est un levier SEO et un argument différenciant dans les appels d'offres. Pour vos utilisateurs, c'est simplement un site qu'ils peuvent utiliser.

Vous souhaitez faire auditer votre site ?

Chez DrupaLabs, nous réalisons des audits d'accessibilité RGAA pour les sites Drupal en production. Notre audit couvre l'ensemble des 106 critères RGAA 4.1 sur un échantillon représentatif de votre site, avec un rapport priorisé et un plan de correction actionnable.

L'audit diagnostic est offert pour les DSI et Directeurs Marketing qui souhaitent connaître leur niveau de conformité actuel.

Demander l'audit accessibilité offert →

Réponse sous 48h — sans engagement.