Tout comme pour l'écoconception, Drupal n'est pas une solution "magique" qui garantit la conformité en un clic. Il fournit un socle technique puissant et pré-optimisé, mais la conformité RGAA s'obtient par un traitement transversal complet : par une configuration rigoureuse, un thémage (front-end) sémantique et une discipline stricte dans la contribution de contenu. L'initiative Drupal Accessibility (A11Y) est au cœur de la communauté, ce qui signifie que le Core de Drupal est conçu pour respecter les standards internationaux (WCAG), dont le RGAA est la déclinaison française. Voici comment concilier Drupal et le RGAA V4 à chaque étape du projet.

Le socle Drupal (core et administration)

La bonne nouvelle est que Drupal (versions 9 et 10+) fait une grande partie du travail pour vous, en particulier côté back-office.

Thème d'administration Claro : Le thème d'administration par défaut, Claro, a été conçu pour être conforme aux normes WCAG 2.1 AA. C'est également vrai pour le thème Gin qui était un thème communautaire intégré désormais dans le core tant il était populaire. C'est LE thème d'administration par excellence dans la communauté aujourd'hui et il fait l'objet d'audits d'accessibilités réguliers.
Cela signifie que l'outil de travail des contributeurs est lui-même accessible (navigation clavier, contrastes, sémantique). C'est un prérequis essentiel puisque l’accessibilité ne concerne pas seulement les visiteurs de sites web, mais aussi les personnels des organisations.  

Thème front-end Olivero : Le thème front-end par défaut, Olivero, est par ailleurs conçu avec l'accessibilité comme priorité. Il gère nativement les contrastes élevés, la navigation clavier, et une structure sémantique.

API de rendu : Les API de Drupal (Render API, Form API) génèrent du code HTML sémantique par défaut. Par exemple, les formulaires générés par Drupal incluent nativement les balises <label for="...">, les <fieldset> et les <legend> nécessaires.

Thème front-end et conception UX/UI

Contrairement à une idée reçue, l’accessibilité numérique n’est pas seulement une question de graphisme. Le thème front end comprend la majorité des critères graphiques et techniques du RGAA. Un thème “custom” (sur mesure) doit impérativement intégrer l'accessibilité dès la première ligne de code.

Sémantique HTML (Critères 8 & 9)

Technique Drupal (Twig) : C'est le cœur du travail. Vous devez surcharger les gabarits (templates) Twig (.html.twig) pour utiliser les balises HTML sémantiques. N'utilisez pas des <div> pour tout.

• page.html.twig : Doit contenir <header>, <nav>, <main>, <footer>.
• node.html.twig : Doit contenir la balise <article>.
• block.html.twig : Un bloc de navigation doit être entouré d'une balise <nav>.

Le core délivre des exemples qui peuvent servir de modèles pour les bonnes pratiques.

Hiérarchie des titres (<h1>, <h2>...) : Le thème doit garantir un seul <h1> par page (généralement le titre du contenu principal). Les titres des blocs et des vues doivent suivre une hiérarchie logique.

Navigation Clavier (Critère 12) 

Technique CSS : Tous les éléments interactifs (liens, boutons, champs) doivent avoir un état :focus visible et contrasté. Ne supprimez jamais l'outline (outline: none;) sans proposer une alternative (ex: box-shadow).

Technique Front-end (JS) : Pour les composants complexes (sliders, onglets, modales), vous devez gérer le focus manuellement en JavaScript (le "piéger" dans la modale, le déplacer dans les onglets avec les flèches directionnelles).

ARIA (Critère 7) 

Technique Drupal (JS/Twig) : Utilisez les attributs ARIA (Accessible Rich Internet Applications) pour les composants dynamiques. Drupal facilite cela via son système drupalSettings et les *.libraries.yml.

Couleurs et contrastes (Critère 3) 

Technique UX/UI : Ce point se gère dès la conception de la charte graphique. Les couleurs choisies pour le texte et les fonds doivent respecter les ratios de contraste (4.5:1 pour le texte normal). Des outils comme "Contrast Checker" ou autres sont utiles pour tester les contrastes. 

Contribution et gestion de contenu

Un site techniquement conforme peut être rendu inaccessible par ses contributeurs. Drupal doit être configuré pour les guider et les contraindre.

Alternatives d'images (Critère 1) : C'est un point crucial. (Voir le § Gérer les alternatives d'images ci-dessous).

Hiérarchie des titres (Critère 9) - Technique Drupal (CKEditor 5) : Configurez l'éditeur de texte pour n'autoriser que les styles sémantiques. Interdisez le choix de la couleur, de la taille de police (qui doit être gérée par le CSS) et limitez les titres à Titre 2, Titre 3, etc. (le Titre 1 étant géré par le thème).

Liens explicites (Critère 6) - Technique Drupal (CKEditor 5) : Formez les équipes à ne pas faire de liens "Cliquez ici". Le texte du lien doit être explicite. L'éditeur de lien de CKEditor permet d'ajouter un "Titre" (attribut title) pour donner plus de contexte, ce qui est une bonne pratique.

Documents en téléchargement (Critère 13) - Technique Drupal (Twig) : Le RGAA impose d'indiquer le format, le poids et la langue des fichiers. Configurez l'affichage du champ "Fichier" (field--file.html.twig) pour ajouter automatiquement ces informations à côté du lien.

Exemple d’intitulé de lien : "Télécharger le rapport (PDF - 1.2 Mo)”

Écosystème (Modules “Contrib”) et audit

Audit des modules contrib : Avant d'ajouter un module (un slider, un formulaire complexe, une dataviz), vérifiez son niveau d'accessibilité. Regardez dans la file d'incidents (issue queue) du module sur drupal.org les mots-clés "accessibility" ou "a11y".

Modules "à risque" : Méfiez-vous des modules qui génèrent beaucoup de JavaScript front-end (ex: sliders, galeries complexes).

Modules "utiles" :

• Views (Core) : Très accessible, car il génère du HTML que vous contrôlez entièrement via les gabarits Twig.

• Webform : Extrêmement puissant et très bien configuré pour l'accessibilité (bonne gestion des labels, fieldset, erreurs).

• CKEditor Accessibility Auditor : Peut-être ajouté à CKEditor pour auditer le contenu avant sa publication.

Gérer les alternatives d'images (Critère 1)

Le RGAA stipule que toute image porteuse d'information doit avoir une alternative textuelle (alt). Toute image décorative doit avoir un attribut alt vide (alt="").

Par défaut, le champ "Image" de Drupal rend le texte alternatif obligatoire. Comment permettre à un contributeur de la marquer comme décorative ?

Solution technique 

Modifier le champ image :

• Allez dans Structure > Types de contenu > [Votre type] > Gérer les champs.
• Modifiez votre champ "Image".
• Décochez la case "Texte alternatif obligatoire".
• Cochez la case "Afficher le champ 'Texte alternatif'" (il reste visible).

Ajouter un champ "image décorative" :

• Sur le même type de contenu, ajoutez un nouveau champ de type Booléen (case à cocher).
• Nommez-le "Image décorative" (field_image_decorative).
• Configurez son affichage pour qu'il apparaisse juste sous le champ alt de l'image.
• Accessoirement, utilisez un module comme conditional_field ou un code custom pour masquer le champ de texte alternatif en fonction de la valeur de cette case à cocher afin d’assurer une expérience utilisateur fluide.

Logique dans twig :

• Surchargez le gabarit Twig de votre champ image (ex: field--field-image.html.twig) ou de l'image elle-même (image.html.twig).
• Ajoutez une logique pour forcer un alt vide si la case est cochée.

Résultat : Le contributeur a un choix clair. S'il ne coche pas "Image décorative", le champ alt (qu'il aura rempli) sera utilisé. S'il la coche, l'attribut alt="" sera généré, assurant la conformité.

Liens d'évitement et sémantique (Critère 12.7)

Le RGAA exige des liens d'évitement ("skip links") pour permettre aux utilisateurs de clavier de sauter les blocs répétitifs (comme le menu principal ou le header).

La solution technique (thème) :

Dans page.html.twig : Placez ces liens tout en haut de votre <body>. Ils ciblent les id des zones principales de votre page.
Le CSS essentiel : Ces liens doivent être invisibles par défaut, mais devenir visibles lorsqu'ils reçoivent le focus (via la touche Tab).
CSS

Résultat : Le premier appui sur "Tab" en arrivant sur la page révèle ces liens, permettant à l'utilisateur de sauter directement au contenu.

Conclusion

L’accessibilité numérique n’est pas une option ni même seulement une obligation réglementaire, c’est un impondérable de la qualité de votre site qui favorise l’expérience utilisateur, le référencement naturel et permet aux personnes en situation de handicap de gagner en autonomie dans leur vie de tous les jours en profitant pleinement de vos services en ligne. C’est ainsi un potentiel de 15 à 20% d’utilisateurs et visiteurs en plus en mesure de visiter ou d’acheter sur vos sites. 
Si vous vous posez des questions sur le niveau d’accessibilité de votre site Drupal ou que vous envisagez une refonte, faites appel à Smile pour auditer, concevoir ou développer votre site pour assurer le meilleur niveau de conformité au RGAA. 
Nous disposons de toutes les compétences sur l’intégralité de la chaîne de valeur de l’accessibilité numérique et mettons à votre disposition notre profil d’installation Sobki élaboré par notre équipe R&D pour répondre précisément à ces exigences dès la phase d’architecture, selon le principe d’accessibilité “by design”.