CMS ac­ces­sibles : bases et exemples (Contao, Plone et Papaya CMS)

Depuis l’entrée en vigueur de la loi sur le ren­for­ce­ment de l’ac­ces­si­bi­lité, il est in­dis­pen­sable de créer des sites Web ac­ces­sibles avec un CMS. Un système de gestion de contenu doté des fonc­tion­na­li­tés adaptées permet de respecter les exigences légales, d’améliorer l’ex­pé­rience uti­li­sa­teur et d’optimiser les contenus pour le ré­fé­ren­ce­ment.

Pourquoi un CMS devrait-il garantir des contenus ac­ces­sibles à tous ?

L’ac­ces­si­bi­lité numérique ne concerne pas seulement l’in­fras­truc­ture technique d’un site Web, mais aussi les contenus publiés. Pour que les in­for­ma­tions nu­mé­riques soient ac­ces­sibles à tous les visiteurs, elles doivent être conçues de manière à pouvoir être con­sul­tées avec des lecteurs d’écran, des dis­po­si­tifs braille ou au clavier.

Le système de gestion de contenu (CMS) utilisé joue ici un rôle central. Si l’ac­ces­si­bi­lité de l’interface uti­li­sa­teur d’un CMS est souvent mise en avant, il est tout aussi essentiel de con­si­dé­rer dans quelle mesure celui-ci soutient la création édi­to­riale de contenus ac­ces­sibles. Le CMS doit fournir aux ré­dac­teurs des outils d’as­sis­tance, des di­rec­tives struc­tu­relles et des mé­ca­nismes de va­li­da­tion fa­ci­li­tant la création de sites Web sans barrière. Voici quelques exemples concrets :

• Champs de saisie pour les textes al­ter­na­tifs des images
• Aver­tis­se­ments en cas d’absence de structure des titres
• Outils pour créer des tableaux et for­mu­laires
• Vé­ri­fi­ca­tions au­to­ma­tiques des con­trastes et des erreurs sé­man­tiques

Un CMS ac­ces­sible réduit le risque d’erreurs édi­to­riales et aide les or­ga­ni­sa­tions à respecter les exigences légales, tout en four­nis­sant des in­for­ma­tions équi­va­lentes à tous les uti­li­sa­teurs.

Quelles sont les normes qui dé­fi­nis­sent l’ac­ces­si­bi­lité du Web ?

L’ac­ces­si­bi­lité du Web est encadrée par le Ré­fé­ren­tiel général d’amé­lio­ra­tion de l’ac­ces­si­bi­lité (RGAA), qui transpose la directive eu­ro­péenne (UE) 2016/2102 sur l’ac­ces­si­bi­lité des sites et ap­pli­ca­tions publics. Depuis 2023, la trans­po­si­tion de la directive (UE) 2019/882 (European Ac­ces­si­bi­lity Act) étend ces obli­ga­tions à certains produits et services nu­mé­riques, ap­pli­cables à partir du 28 juin 2025. Ces règles s’appuient sur les di­rec­tives in­ter­na­tio­nales WCAG 2.2 du W3C ainsi que sur la norme eu­ro­péenne EN 301 549, qui fixent les principes fon­da­men­taux pour garantir l’ac­ces­si­bi­lité des contenus en ligne.

Les WCAG 2.2 dé­fi­nis­sent quatre principes es­sen­tiels à respecter pour assurer l’ac­ces­si­bi­lité d’un site ou d’un CMS :

• Per­cep­ti­bi­lité : toutes les in­for­ma­tions doivent être pré­sen­tées de manière com­pré­hen­sible pour chaque uti­li­sa­teur, par exemple avec des al­ter­na­tives tex­tuelles aux images et des con­trastes suf­fi­sants.
• Uti­li­sa­bi­lité : l’interface doit être navigable avec dif­fé­rents dis­po­si­tifs, y compris au clavier.
• Com­pré­hen­si­bi­lité : les contenus doivent être struc­tu­rés clai­re­ment, rédigés dans un langage simple et faciles à lire.
• Ro­bus­tesse : les contenus doivent être com­pa­tibles avec dif­fé­rents appareils et outils d’as­sis­tance.

Pour les ré­dac­teurs, cela implique notamment d’utiliser une hié­rar­chie de titres logique (H1 à H6) et d’intégrer des textes al­ter­na­tifs et liens per­ti­nents. Il est tout aussi essentiel d’adopter un langage clair et une na­vi­ga­tion cohérente. Un CMS inclusif conforme à ces exigences simplifie le travail ré­dac­tion­nel et contribue au respect des obli­ga­tions légales en France.

Ac­ces­si­bi­lité dans le CMS : exemples pratiques avec Contao, Plone et Papaya CMS

Tous les CMS ne proposent pas les mêmes con­di­tions pour créer des contenus ac­ces­sibles. Certains systèmes se dis­tin­guent par la qualité de leur rendu frontend, tandis que d’autres mettent l’accent sur le contrôle ré­dac­tion­nel ou la rigueur sé­man­tique. Les trois CMS open source Contao, Plone et Papaya CMS sont par­ti­cu­liè­re­ment réputés pour favoriser l’ac­ces­si­bi­lité. C’est pourquoi nous pré­sen­tons ci-dessous leurs prin­ci­pales fonc­tion­na­li­tés dans ce domaine.

Contao

Contao est un CMS développé en Allemagne, pensé dès l’origine pour un code ac­ces­sible et sé­man­ti­que­ment propre. Afin de faciliter la création de contenus conformes à la lé­gis­la­tion sur l’ac­ces­si­bi­lité, le logiciel propose notamment les fonc­tion­na­li­tés suivantes :

• Templates ac­ces­sibles : de nombreux thèmes res­pec­tent les normes WCAG et sont conçus pour être adap­ta­tifs.
• Éléments de contenu struc­tu­rés : les ré­dac­teurs utilisent des modules ga­ran­tis­sant une sortie claire et sé­man­ti­que­ment correcte.
• Prise en charge des textes al­ter­na­tifs : les images, vidéos et autres médias peuvent être enrichis de des­crip­tions al­ter­na­tives.
• Modules de for­mu­laire : des com­po­sants prêts à l’emploi prennent en charge la dé­sig­na­tion des champs obli­ga­toires, la na­vi­ga­tion au clavier et la gestion des erreurs.

En com­plé­ment, des ex­ten­sions comme Si­te­Cock­pit ajoutent des fonctions d’ac­ces­si­bi­lité intégrées, telles que l’ajus­te­ment du contraste des couleurs, le contrôle de la taille de la police ou encore des rapports d’audit au­to­ma­ti­sés. Grâce à ces atouts, Contao constitue une solution par­ti­cu­liè­re­ment adaptée aux ins­ti­tu­tions publiques, aux éta­blis­se­ments d’en­seig­ne­ment et aux ONG.

Plone

Plone est un CMS puissant basé sur Python, qui applique depuis de nom­breuses années des normes strictes en matière d’ac­ces­si­bi­lité. Il est utilisé dans le monde entier par des uni­ver­si­tés, des mi­nis­tères et des or­ga­ni­sa­tions ayant des exigences élevées en ac­ces­si­bi­lité numérique. Plone est conforme aux WCAG 2.1, niveau AA, et intègre donc par défaut de nom­breuses fonc­tion­na­li­tés fa­ci­li­tant l’ac­ces­si­bi­lité.

Pour attester de cette con­for­mité, un document VPAT (Voluntary Product Ac­ces­si­bi­lity Template) est dis­po­nible. Il s’agit d’un rapport stan­dar­disé qui décrit dans quelle mesure le logiciel respecte les normes d’ac­ces­si­bi­lité. Ce document permet aux en­tre­prises et ins­ti­tu­tions de vérifier ra­pi­de­ment si Plone répond à leurs obli­ga­tions légales et à leurs besoins en matière d’ac­ces­si­bi­lité.

Parmi les prin­ci­paux avantages ré­dac­tion­nels en matière d’ac­ces­si­bi­lité offerts par Plone, on retrouve :

• Struc­tures sé­man­tiques claires : la mise en forme du contenu repose stric­te­ment sur les standards HTML5.
• Gestion du flux de travail (workflow) éditorial : les contenus peuvent être contrôlés et validés pour leur con­for­mité avant pu­bli­ca­tion.
• Contrôle d’accès : permet un travail col­la­bo­ra­tif grâce à des rôles clai­re­ment définis.

De plus, des ex­ten­sions comme le Plone All in One Ac­ces­si­bi­lity Widget ajoutent des fonc­tion­na­li­tés pratiques, telles que l’ajus­te­ment de la taille de police, la mo­di­fi­ca­tion des con­trastes ou la na­vi­ga­tion optimisée au clavier. Ces atouts font de Plone une solution idéale pour les portails ac­ces­sibles intégrant des processus complexes.

Papaya CMS

Papaya CMS est un système de gestion de contenu modulaire, basé sur XML, qui se distingue par une sé­pa­ra­tion claire entre le contenu, la mise en page et la logique. Cette ar­chi­tec­ture permet de générer des sorties HTML sé­man­ti­que­ment correctes et ac­ces­sibles. Papaya est par­ti­cu­liè­re­ment adapté aux projets complexes avec de fortes exigences édi­to­riales et des canaux de diffusion bien définis.

• Struc­tu­ra­tion stricte : grâce à la sé­pa­ra­tion du contenu, de la mise en page et de la logique, la création de sites Web conformes aux standards sé­man­tiques HTML est facilitée.
• Templates et modules ac­ces­sibles : de nombreux modèles et com­po­sants res­pec­tent les normes WCAG.
• Contenus mul­ti­lingues : la gestion des données permet une diffusion inclusive dans plusieurs langues.

Comment vérifier si les contenus d’un CMS sont ac­ces­sibles ?

La création de contenus ac­ces­sibles ne s’arrête pas à leur saisie dans le CMS. Une vé­ri­fi­ca­tion régulière est in­dis­pen­sable pour détecter et corriger ra­pi­de­ment les obstacles à l’uti­li­sa­tion. Pour tester l’ac­ces­si­bi­lité d’un site Web, il est re­com­mandé de combiner des outils au­to­ma­ti­sés avec des méthodes manuelles.

Outils au­to­ma­ti­sés

• axe DevTools : une extension de na­vi­ga­teur éprouvée de Deque Systems, qui détecte de manière fiable les erreurs d’ac­ces­si­bi­lité selon les critères WCAG et fournit des in­di­ca­tions précises pour les corriger.
• WAVE (Web Ac­ces­si­bi­lity Eva­lua­tion Tool) : permet de vi­sua­li­ser di­rec­te­ment les barrières dans la fenêtre du na­vi­ga­teur ; idéal pour vérifier la qualité édi­to­riale de contenus comme les textes al­ter­na­tifs et la structure des titres.
• Google Ligh­thouse : fournit des scores d’ac­ces­si­bi­lité et des re­com­man­da­tions concrètes sur la structure, les couleurs, la con­vi­via­lité et plus ; exé­cu­table via Google PageSpeed Insights, dans Chrome DevTools, en ligne de commande ou sous forme de module Node.js.
• Evinced : utilise l’in­tel­li­gence ar­ti­fi­cielle et l’ap­pren­tis­sage au­to­ma­tique pour détecter des barrières complexes ; offre des rapports détaillés pour dé­ve­lop­peurs ainsi que des in­té­gra­tions pour les en­vi­ron­ne­ments DevOps.

Tests manuels

Les outils au­to­ma­ti­sés ne per­met­tent pas d’iden­ti­fier tous les problèmes d’ac­ces­si­bi­lité. C’est pourquoi il est essentiel de compléter leur uti­li­sa­tion par des méthodes manuelles, telles que :

• Na­vi­ga­tion au clavier : vérifier que le site est uti­li­sable uni­que­ment avec Tab et Maj, et que les in­di­ca­teurs de focus sont visibles et cohérents.
• Tests avec des lecteurs d’écran : utiliser NVDA (Windows), VoiceOver (macOS/iOS) ou JAWS pour contrôler la lecture sé­man­ti­que­ment correcte, les annonces de focus et la logique des séquences de lecture.
• Vé­ri­fi­ca­tion des con­trastes et si­mu­la­tions de couleurs : des outils comme WebAIM Contrast Checker ou Color Oracle per­met­tent d’évaluer les con­trastes et de simuler dif­fé­rentes dé­fi­ciences visuelles.
• Contrôle des for­mu­laires : s’assurer que les éti­quettes sont cor­rec­te­ment associées, que les messages d’erreur sont clairs, que le focus se déplace lo­gi­que­ment et que les champs de saisie sont ac­ces­sibles.
• Ins­pec­tion visuelle et tests de zoom : vérifier si le design reste fonc­tion­nel avec un fort taux de zoom et si les contenus s’adaptent cor­rec­te­ment, sans ap­pa­ri­tion de barres de dé­fi­le­ment ho­ri­zon­tales.

Enfin, il est re­com­mandé de mettre en place un guide éditorial sur l’ac­ces­si­bi­lité et de prévoir des for­ma­tions ré­gu­lières, afin de renforcer du­ra­ble­ment les com­pé­tences au sein de l’équipe.