Choisir un CMS conforme RGAA n’a rien d’un luxe pour administrations, collectivités ou entreprises : sans un système de gestion de contenu accessible, chaque mise à jour de page risque de recréer des barrières pour les utilisateurs handicapés. Un mauvais choix de CMS enferme les équipes dans une interface rigide, des modèles impossibles à corriger et des plugins qui cassent l’accessibilité à chaque version. À l’inverse, un outil pensé pour le web accessible aide les rédacteurs à produire des contenus plus clairs, les développeurs à appliquer les normes d’accessibilité et les responsables métiers à piloter la conformité RGAA sur la durée.
Ce sujet dépasse largement la case « technique » dans un cahier des charges. Le choix CMS conditionne la qualité des formulaires, la structure des menus, la gestion des médias, les possibilités de tester et corriger les erreurs… et la capacité à prouver sa conformité via une vraie déclaration de conformité RGAA. Derrière ce choix, on retrouve aussi le risque contentieux pour les organismes soumis à l’obligation légale d’accessibilité et la perspective de sanctions pour non-respect du RGAA si rien n’est anticipé. L’enjeu est donc double : protéger les usagers les plus vulnérables et sécuriser juridiquement et politiquement vos projets numériques.
- Le CMS ne rend pas un site conforme par magie : il doit offrir des outils, des modèles et des garde-fous qui facilitent l’application du RGAA.
- Les critères d’accessibilité doivent être présents dès le cahier des charges : rôles d’éditeur, formulaires, médias, composants interactifs, workflows.
- Un audit d’accessibilité reste indispensable pour vérifier la mise en œuvre concrète, quel que soit le CMS retenu.
- Les coûts cachés viennent souvent des plugins non accessibles et des correctifs à répétition après mise en production.
- L’accompagnement et la formation RGAA des équipes comptent autant que la technologie choisie.
CMS, RGAA et accessibilité : comprendre ce que le système peut (et ne peut pas) faire pour vous
Avant de cocher la case « CMS accessible », il faut clarifier un point souvent mal compris : un CMS ne rend jamais un site conforme à lui seul. Ce que le système de gestion de contenu peut offrir, ce sont des briques techniques et des interfaces d’édition qui rendent l’application du RGAA plus ou moins crédible sur le terrain. Un outil bien conçu réduit les risques d’erreur, propose une structure sémantique correcte par défaut, et limite les pratiques qui cassent l’ergonomie web ou le design inclusif.
Concrètement, un système de gestion de contenu peut aider à garantir que les titres respectent une hiérarchie Hn, que les images exigent un texte alternatif avant publication, ou encore que les éditeurs ne puissent pas insérer de textes illisibles en gris clair sur fond gris. Certains CMS proposent même des modules de contrôle automatique qui pointent, dès l’édition, une partie des erreurs courantes de non-conformité RGAA. Mais dès que l’on sort des usages simples, ce sont les templates, les composants front et les bonnes pratiques des équipes qui prennent le relais.
De nombreux décideurs se rassurent en pensant qu’un CMS « réputé accessible » suffira à couvrir l’obligation réglementaire. C’est un piège classique. Dans les audits, il n’est pas rare de trouver des sites basés sur WordPress, Drupal ou Joomla, adossés à des thèmes graphiques très marketés, mais remplis de sliders inaccessibles, de menus non pilotables au clavier et de contrastes insuffisants. Ces non-conformités relèvent moins du cœur du CMS que des choix de thèmes, d’extensions et de configuration. D’où l’intérêt de se référer à un référentiel RGAA clairement assumé dans toute la chaîne du projet.
Pour poser un cadre commun, beaucoup d’équipes gagnent à repartir de définitions simples : le RGAA est la déclinaison française des WCAG, adaptée au contexte réglementaire national. Certains CMS intègrent désormais des options qui s’alignent explicitement sur ces standards (contrôle du contraste, composants ARIA, navigation clavier robuste). Mais même les meilleurs systèmes restent des outils : sans un audit d’accessibilité sérieux, il est impossible de déclarer une conformité honnête.
Un autre malentendu courant concerne le périmètre technique : beaucoup de responsables imaginent que le back-office échappe au RGAA au motif qu’il serait réservé aux agents internes. Ce n’est plus défendable lorsque ces agents sont eux-mêmes en situation de handicap ou qu’ils utilisent des lecteurs d’écran et des aides techniques. Un CMS conforme RGAA doit être regardé sur les deux faces du miroir : l’interface publique et le back-office d’administration. Un éditeur de contenu non accessible condamne littéralement certains collègues à ne jamais pouvoir publier ou corriger une simple page.
Au fond, la question à se poser en amont n’est pas « ce CMS est-il RGAA-ready ? », mais plutôt : « Ce CMS me permet-il de contrôler finement le HTML rendu, d’imposer des modèles accessibles et de suivre les écarts dans le temps ? ». Un système rigide, fermé, sans possibilité d’adapter les composants aux normes d’accessibilité finira presque toujours par générer une dette impossible à rattraper. Mieux vaut se confronter tôt à cette réalité que de la découvrir au moment du contrôle réglementaire.
Critères RGAA incontournables à intégrer dans le choix d’un système de gestion de contenu
Une fois cette frontière posée entre ce que peut offrir l’outil et ce qui relève de l’implémentation, reste à baliser les critères concrets à intégrer dans le choix CMS. Plutôt que de se perdre dans des dizaines de fonctionnalités marketing, le plus utile consiste à regarder comment le système gère quelques grands classiques du web accessible : les images, les médias, les formulaires, les structures de page, les composants interactifs et la gestion des langues.
Sur les images, la question clé est simple : le CMS impose-t-il un texte alternatif pour chaque visuel inséré, avec une interface qui incite à rédiger un contenu pertinent, et non à laisser des champs vides ou remplis mécaniquement de mots-clés SEO ? Les systèmes les plus matures vont plus loin en distinguant images purement décoratives et visuels porteurs d’information, avec une logique claire pour masquer les décoratives aux lecteurs d’écran. Sans ce type de garde-fou, les équipes éditoriales reproduisent vite des erreurs pourtant faciles à éviter.
Côté vidéo et audio, on attend d’un CMS moderne qu’il facilite la gestion des sous-titres, des transcriptions et des pistes audio alternatives. Dans les projets publics, l’absence de sous-titrage reste encore l’un des motifs de non-conformité les plus fréquents signalés dans les rapports d’audit RGAA. Un bon système permet d’associer facilement un fichier de sous-titres, de gérer plusieurs versions linguistiques et de rappeler systématiquement aux équipes la nécessité d’une transcription pour les contenus strictement audio.
Les formulaires méritent une attention particulière. Les exigences du RGAA sur ce point couvrent les intitulés de champs, la gestion des erreurs, les aides à la saisie, la navigation au clavier, la cohérence des libellés et l’ordre de tabulation. Un CMS orienté design inclusif proposera par défaut des modèles de formulaires où chaque champ est lié à une étiquette explicite, où les messages d’erreur sont visibles, lisibles, et signalés correctement pour les technologies d’assistance. Sans cette base, chaque formulaire devra être repris au cas par cas, avec un risque énorme d’incohérences dans le temps.
La structure générale des pages constitue un autre pilier. Un outil qui laisse les rédacteurs changer la taille visuelle des titres sans respecter la hiérarchie H2, H3, H4 produit vite des pages impossibles à naviguer avec un lecteur d’écran. Certains CMS s’en sortent mieux que d’autres en proposant une palette de styles graphiques dissociée de la structure HTML. Pour les projets soumis au RGAA, ce genre de détail fait une vraie différence en audit, car il réduit la variabilité selon les contributeurs.
Enfin, dans un contexte où les sites multilingues se multiplient, le support des attributs de langue et la gestion structurée des versions traduites sont loin d’être accessoires. Un système qui mélange les contenus de plusieurs langues sur la même page, ou qui ne permet pas d’indiquer correctement la langue de chaque segment, complique forcément la navigation pour les usagers de lecteurs d’écran. Certains outils facilitent au contraire ce travail en intégrant des workflows de traduction, des URLs segmentées par langue et des champs dédiés aux métadonnées linguistiques.
Pour garder une vision synthétique de ces exigences, un certain nombre d’équipes utilisent des ressources comme la checklist RGAA en 106 points, en repérant ce qui relève plutôt du CMS, du thème graphique, du développement spécifique ou du contenu éditorial. Cette répartition sert ensuite de base pour questionner les éditeurs de solutions et cadrer les tests à réaliser avant signature.
Tableau comparatif : ce qu’un CMS doit permettre pour viser la conformité RGAA
Pour objectiver les discussions avec les prestataires et éviter les promesses vagues, un tableau comparatif des capacités du CMS face aux exigences d’accessibilité reste un outil précieux. Il ne remplace pas un audit, mais il permet de filtrer d’emblée les solutions les moins adaptées, notamment les offres fermées de type « constructeur de sites » qui laissent très peu de contrôle sur le code produit.
| Aspect d’accessibilité | Question à poser sur le CMS | Ce qu’on attend d’un outil sérieux |
|---|---|---|
| Images et médias | Le CMS gère-t-il les textes alternatifs, les sous-titres et les transcriptions de manière structurée ? | Champs obligatoires pour les textes alternatifs, distinction décoratif/informatif, association simple de sous-titres et transcriptions. |
| Formulaires | Les modèles de formulaires respectent-ils nativement les critères RGAA (labels, erreurs, aide) ? | Gabarits accessibles, champs correctement étiquetés, messages d’erreur visibles et annoncés, navigation clavier fluide. |
| Structure des pages | Les titres Hn, listes, tableaux sont-ils structurés automatiquement de manière sémantique ? | Contrôle de la hiérarchie des titres, styles graphiques dissociés de la structure, éditeur qui génère un HTML propre. |
| Navigation et menus | Les menus générés sont-ils pilotables au clavier et correctement annoncés aux lecteurs d’écran ? | Menus accessibles par défaut, gestion du focus, possibilité d’ajouter des liens d’évitement et des fils d’Ariane conformes. |
| Back-office | L’interface d’édition respecte-t-elle les principes du web accessible pour les contributeurs internes ? | Navigation clavier possible, champs lisibles, composants ARIA pertinents, aide contextuelle sur les exigences d’accessibilité. |
Ce type de grille ouvre souvent les yeux de la direction sur un point simple : un CMS trop fermé, qui ne laisse pas la main sur le HTML rendu ni sur la structure des composants, rend presque impossible un site réellement conforme au RGAA. À partir de là, la discussion ne porte plus seulement sur le coût apparent de la licence, mais sur la capacité réelle de la solution à éviter une dette d’accessibilité lourde à corriger.
CMS open source, SaaS et RGAA : forces, limites et idées reçues pour un web accessible
Le débat « open source vs SaaS propriétaire » revient systématiquement lorsque l’on parle de CMS conforme RGAA. Plutôt que d’en faire une querelle idéologique, il est plus utile de regarder ce que chaque modèle apporte ou complique pour un projet tourné vers un design inclusif et une conformité pérenne. Le critère déterminant reste la capacité à garder la main sur le code, les composants et les mises à jour, sans perdre l’équipe dans une usine à gaz.
Les CMS open source comme WordPress, Drupal ou Joomla offrent un avantage clair : accès au code, écosystème riche, libertés de personnalisation. Dans une démarche RGAA, cette ouverture autorise la création de thèmes et de modules sur mesure, testés et corrigés en fonction des résultats d’audits. Des ressources dédiées, comme les plugins d’accessibilité WordPress orientés RGAA, peuvent compléter ce socle. L’envers de la médaille, c’est la dispersion des extensions : un plugin mal conçu suffit à casser l’accessibilité d’un ensemble pourtant bien pensé.
Les solutions en mode SaaS (Wix, Squarespace, certains constructeurs de sites « clé en main ») séduisent par leur promesse de simplicité et de mise en ligne rapide. Pour des projets très simples, portés par de toutes petites structures, cela peut suffire. Mais dès que le RGAA entre en jeu de manière stricte, les limites apparaissent vite : accès restreint au code, peu de contrôle sur le HTML généré, dépendance forte au fournisseur pour corriger une anomalie d’accessibilité. Quand un composant central ne respecte pas un critère RGAA (par exemple la navigation clavier ou le contraste), il devient compliqué de le corriger sans attendre une mise à jour globale du produit.
Il existe un entre-deux intéressant avec les plateformes type « headless CMS » ou « CMS hybride », où le back-office gère le contenu et le front est entièrement développé sur mesure. Ce modèle redonne une grande liberté côté interface publique : les équipes peuvent construire un site RGAA conforme en pilotant chaque composant, chaque interaction. L’effort initial est plus élevé, mais la capacité à faire évoluer l’interface sans changer de système de gestion de contenu est souvent un atout sur plusieurs années, surtout lorsque les référentiels ou les usages évoluent.
Un point que beaucoup sous-estiment concerne la stratégie d’hébergement et de mise à jour. Certains éditeurs de CMS proposent des offres où ils gardent la main sur les versions, les correctifs de sécurité et parfois les thèmes de base. Pour l’accessibilité, cela peut être une aide ou un frein. Si l’éditeur prend au sérieux les normes d’accessibilité et publie des modèles mis à jour suite aux évolutions du RGAA et des WCAG, c’est une vraie force. S’il considère ce sujet comme secondaire, les équipes se retrouvent coincées avec un socle difficile à corriger.
Au-delà du type de CMS, la vraie différence se joue sur la culture d’accessibilité de l’écosystème. Drupal, par exemple, a bâti une réputation solide sur ce point en structurant une communauté très active autour des questions d’inclusion, de sécurité et de performance. WordPress propose aussi de nombreux thèmes orientés accessibilité, mais leur qualité reste très variable et nécessite d’être vérifiée par un audit sérieux. Les systèmes plus confidentiels, eux, peuvent être techniquement excellents sans disposer de modules ou de ressources explicitement tournés vers le RGAA, ce qui complique la tâche des équipes.
Pour reprendre un cas concret, de nombreuses collectivités locales se retrouvent aujourd’hui avec un CMS propriétaire mis en place il y a quelques années, sans réel contrôle sur les évolutions. Quand elles engagent un audit et découvrent un taux de conformité très faible, elles constatent qu’une part non négligeable des corrections est impossible sans toucher au cœur du système, ce que l’éditeur refuse. À ce stade, la seule option réaliste reste souvent la migration, avec tout ce que cela implique en coût et en charge de travail. D’où l’intérêt d’intégrer dès le départ la question du contrôle et de la réversibilité dans le choix CMS.
Processus concret pour choisir un CMS accessible : besoins, tests, preuves de conformité
Pour éviter de se perdre dans les argumentaires commerciaux, une approche structurée aide beaucoup. La plupart des équipes qui réussissent leur transition vers un CMS conforme RGAA suivent une logique en quatre temps : clarification des besoins, traduction en exigences mesurables, tests sur maquettes ou démonstrateurs, puis engagement contractuel avec des critères de succès précis. Cette méthode ne supprime pas les aléas, mais elle limite nettement les mauvaises surprises après mise en production.
La première étape consiste à établir un portrait précis du site visé et des utilisateurs. S’agit-il d’un portail institutionnel avec forte part de démarches en ligne, d’un site vitrine simple, d’un extranet réservé à des professionnels, ou d’un intranet interne où travaillent des agents en situation de handicap ? La volumétrie de contenu, la fréquence des mises à jour, le niveau de compétences des contributeurs et le périmètre fonctionnel (formulaires complexes, simulateurs, vidéo en direct) orientent fortement le type de système de gestion de contenu pertinent.
Vient ensuite la traduction de ces besoins en exigences d’accessibilité formalisées. Ce travail peut s’appuyer sur des guides opérationnels comme le guide d’accessibilité RGAA pour équipes projet, qui aide à transformer les critères du référentiel en questions concrètes pour le CMS : quels modèles de pages, quels composants doivent être présents, quels contrôles automatiques ou semi-automatiques sont attendus dans l’éditeur, comment seront gérées les versions et les traductions, etc. Cette liste sert de base à un cahier des charges partagé avec les éditeurs ou intégrateurs.
Le troisième temps, souvent négligé, consiste à tester réellement les systèmes pressentis avant de trancher. Demander un accès de démonstration à un back-office, publier quelques contenus types (article avec images, tableau, vidéo, formulaire simple), puis vérifier leur rendu avec un lecteur d’écran, une navigation au clavier et quelques scénarios utilisateurs concrets change radicalement la perception du produit. Des outils en ligne, comme un test RGAA rapide sur une page de démonstration, peuvent déjà donner un premier niveau de signal.
À ce stade, certaines organisations font appel à un expert RGAA pour les accompagner dans l’analyse des réponses techniques des éditeurs et, si besoin, la réalisation d’un mini-audit comparatif. L’idée n’est pas de sanctionner, mais d’identifier les points forts et faibles de chaque solution au regard de la stratégie numérique à moyen terme. Un CMS très performant sur la partie blog mais limité sur les formulaires dynamiques, par exemple, pourra convenir à une structure mais pas à une autre.
Le dernier temps relève du contrat. Trop d’appels d’offres se contentent d’exiger la conformité RGAA « à 100 % » sans préciser les modalités de contrôle, ni les responsabilités en cas de dérive. Un cadrage plus réaliste décrit le niveau visé pour la mise en ligne, les écarts acceptables et surtout l’organisation d’un audit de conformité indépendant, avec un plan de correction partagé. Ce même contrat peut prévoir un accompagnement continu, via un dispositif d’appui à l’accessibilité, pour aider les équipes à maintenir le niveau au fil des évolutions.
Dans cette démarche, certains choisissent de mobiliser une formation spécifique pour les contributeurs, en particulier lorsque le CMS retenu propose des fonctionnalités avancées en matière d’accessibilité. Une formation RGAA centrée sur les usages du CMS donne aux rédacteurs les bons réflexes dès le départ : structurer leurs contenus, décrire les images, vérifier le contraste, tester au clavier. Sans ce volet humain, même le meilleur système finit par produire des contenus bancals.
Comparateur de CMS conforme RGAA
Comparez rapidement deux CMS sur leurs capacités d’accessibilité (RGAA). Sélectionnez une évaluation pour chaque critère, ajoutez vos notes puis exportez la grille en texte pour l’intégrer à votre audit ou à votre cahier des charges.
| Critère RGAA | CMS A | CMS B | Notes / points de vigilance |
|---|---|---|---|
| Synthèse |
Score moyen
–
|
Score moyen
–
|
Le score est calculé sur 3 (1 = insuffisant, 2 = correct, 3 = très bon). |
Copier-coller ce texte dans votre rapport d’accessibilité, votre ticket de cadrage ou votre cahier des charges.
Anticiper la maintenance, les audits et l’évolution du RGAA pour ne pas se retrouver bloqué
Choisir un CMS conforme RGAA ne se limite pas au lancement du site. La maintenance, les mises à jour, l’ajout de nouvelles fonctionnalités et l’évolution des référentiels transforment très vite un projet ponctuel en sujet de long terme. Sans stratégie claire, on voit des sites passer de « plutôt accessibles » à « très dégradés » en quelques mois, au fil des sprints et des arbitrages fonctionnels.
Le premier levier, souvent sous-estimé, concerne les processus de mise à jour du CMS, des thèmes et des modules. Dans l’idéal, chaque montée de version importante devrait faire l’objet d’une courte batterie de tests ciblés sur les scénarios d’accessibilité critiques : navigation clavier du menu principal, lecture des formulaires avec lecteurs d’écran, gestion du focus dans les pop-ins, cohérence des contrastes. Un contrôle plus complet, via un audit RGAA fiable à fréquence définie, permet ensuite de garder une vision globale de la dérive éventuelle.
Ensuite, la gouvernance éditoriale joue un rôle déterminant. Un CMS peut proposer des gabarits accessibles… s’ils ne sont jamais utilisés parce que chacun crée ses propres blocs à la volée, l’effet sera nul. Doter le projet d’un ou plusieurs « référents accessibilité » qui veillent à ce que les modèles officiels soient bien utilisés, qui accompagnent les nouveaux contributeurs et qui arbitrent les demandes de nouveaux composants, aide à maintenir un socle robuste. Beaucoup d’équipes choisissent aussi de formaliser quelques règles simples dans un guide interne, en complément du RGAA, pour rappeler les bons réflexes au quotidien.
Un autre enjeu tient à l’évolution du cadre réglementaire. Entre les mises à jour du RGAA et les ajustements autour de la directive européenne sur l’accessibilité du web, les exigences se précisent régulièrement. Un CMS figé, sans feuille de route claire sur ce sujet, risque de devenir un frein. À l’inverse, une solution suivie, assortie d’un plan public de mise en conformité progressive avec les nouveaux critères, donne de l’air aux équipes. Certaines organisations vont jusqu’à inscrire dans leurs exigences la nécessité pour l’éditeur de documenter, à chaque release majeure, les impacts sur l’accessibilité.
La question des contenus dynamiques et des modules évolués mérite également un suivi particulier : pagination, filtres de recherche, carrousels, composants riches. Par exemple, un module de pagination non accessible peut suffire à créer une rupture de parcours. Des ressources ciblées, comme le guide sur la pagination accessible au RGAA, aident à vérifier que les briques choisies dans le CMS (ou développées sur mesure) respectent bien les pratiques attendues. Même chose pour le contraste des couleurs, sujet sur lequel des outils et méthodes spécifiques existent, comme ceux présentés autour du contraste RGAA.
Enfin, il ne faut pas perdre de vue que le CMS n’est qu’un élément parmi d’autres dans l’architecture numérique. Les PDF générés automatiquement, les connecteurs vers des outils tiers, les scripts de suivi statistique ou les solutions de gestion de consentement peuvent réintroduire des obstacles sur un site par ailleurs bien construit. D’où l’intérêt d’inscrire l’accessibilité dans une vision plus large, qui couvre aussi les documents téléchargeables, les emails transactionnels, les services métiers connectés et les contenus embarqués.
Au bout du compte, la meilleure garantie reste souvent une combinaison de trois éléments : un CMS techniquement capable de produire un site conforme, une équipe sensibilisée et formée, et un dispositif de contrôle régulier. Sans ce trio, la conformité affichée reste fragile, parfois très loin de l’expérience réelle vécue par les utilisateurs handicapés.
Un CMS conforme RGAA suffit il pour rendre mon site accessible ?
Non. Un CMS peut faciliter le respect des normes d accessibilite (gabarits accessibles, controles automatiques, bonne structure HTML), mais seul un travail de conception, de developpement et de redaction rigoureux, verifie par un audit RGAA independant, permet de parler de conformite reelle.
Faut il privilegier un CMS open source ou SaaS pour le RGAA ?
Pour un projet soumis au RGAA, un CMS open source ou tres ouvert donne souvent plus de marge de manoeuvre pour adapter les composants et corriger les problemes d accessibilite. Une solution SaaS peut convenir pour des sites simples, mais son manque de controle sur le code genere peut devenir un frein des que l on doit traiter des cas complexes ou corriger rapidement un defaut critique.
Comment verifier qu un CMS respecte bien les exigences d accessibilite ?
La seule reponse fiable consiste a tester : navigation au clavier, lecture avec lecteur d ecran, controle des contrastes, verification des formulaires et des medias sur une instance de demonstration. Un mini audit cible peut etre realise avant le choix definitif, en complement des engagements contractuels annonces par l editeur.
Le back office du CMS doit il aussi etre accessible ?
Oui, surtout si des collaborateurs en situation de handicap utilisent l outil de publication. Le RGAA ne se limite pas a la partie publique quand le service interne concerne directement des agents ; et au dela de la loi, un back office non accessible exclut de fait certains membres de l equipe de toute contribution au site.
A quelle frequence faut il auditer un site pour garder la conformite RGAA ?
La plupart des organisations choisissent un audit complet tous les 1 a 3 ans, complete par des controles plus legers a chaque grande evolution du CMS, du theme ou des fonctionnalites. L essentiel est de ne pas attendre plusieurs cycles de projet avant de mesurer a nouveau la qualite de l accessibilite.
