Accessibilité médias dans Drupal : sous-titres, descriptions et PDF

Pourquoi les médias concentrent les failles d'accessibilité

Un texte bien balisé, avec une hiérarchie H1/H2/H3 correcte et des liens explicites, passe sans difficulté les outils de lecture d'écran. Un formulaire avec des labels bien associés aussi. Mais une vidéo, une image ou un PDF posés dans une page Drupal sans configuration spécifique posent des problèmes que le balisage seul ne règle pas.

Trois facteurs expliquent cette concentration.

Le contenu média est souvent externalisé. Les vidéos viennent d'une agence de production, les infographies d'un prestataire graphique, les PDF du service juridique. Chacun livre un fichier, personne ne vérifie l'accessibilité avant import.

Les champs Drupal restent facultatifs par défaut. Le champ « texte alternatif » sur les images est activé par défaut dans Drupal, mais il n'est pas obligatoire. En pratique, les équipes de contenu le laissent vide ou y copient le nom du fichier.

Les PDF ne se valident pas avec un outil de lint. Contrairement au HTML, un PDF accessible repose sur une structuration interne que la plupart des outils de génération (Word, InDesign, exports automatiques) ne produisent pas correctement sans configuration supplémentaire.

Vidéos sans sous-titres : le cas le plus courant

Une vidéo sans sous-titres exclut les utilisateurs sourds ou malentendants, les personnes qui regardent dans un environnement bruyant ou silencieux, et les non-natifs de la langue. C'est aussi le cas d'accessibilité le plus facile à identifier lors d'un audit.

Dans Drupal, la gestion des sous-titres dépend du module d'intégration vidéo utilisé.

Video Embed Field : ce module affiche une vidéo intégrée depuis YouTube ou Vimeo. Les sous-titres sont dans ce cas gérés par la plateforme externe. Il faut s'assurer que la vidéo source dispose de sous-titres activés côté plateforme, et que le player est configuré pour les afficher par défaut.

Media module (core depuis Drupal 8.4) : pour les vidéos hébergées directement, Drupal peut afficher un player HTML5 natif. Ce player gère les fichiers de sous-titres au format WebVTT via l'élément <track>. La configuration se fait au niveau du formateur de champ dans la gestion de l'affichage de l'entité.

La vérification avant publication repose sur deux contrôles distincts. Un premier vérifie que le fichier de sous-titres est bien associé au média. Un second, visuel et humain, vérifie que les sous-titres sont synchronisés et complets.

Textes alternatifs et descriptions d'images dans Drupal

Le texte alternatif (attribut alt) remplit deux fonctions : décrire l'image pour un utilisateur qui ne peut pas la voir, et fournir un texte de substitution si l'image ne charge pas. Ces deux fonctions réclament le même soin, mais des formulations différentes selon le contexte.

Rendre le champ obligatoire. Dans la configuration du champ Image sur un type de contenu, Drupal permet de rendre le texte alternatif obligatoire. C'est le premier levier à activer. Un champ obligatoire ne garantit pas un texte de qualité, mais il élimine les cas de vide total.

Définir un guide de rédaction. Un texte alternatif bien formé décrit ce qui est visuellement pertinent dans l'image, sans commencer par « Image de » ou « Photo de », sans répéter le titre adjacent. Pour un infogramme ou un graphique, la description peut inclure les données représentées sous forme textuelle.

Drupal permet d'ajouter un champ de description longue distinct du texte alternatif, pour les images complexes. Ce champ est sous-utilisé, mais il est disponible et peut être exposé dans les types de contenu concernés.

Images décoratives. Une image purement décorative (séparateur, fond, icône générique) ne doit pas recevoir de texte alternatif descriptif : l'attribut alt doit être présent mais vide (alt=""). Cela indique aux lecteurs d'écran de l'ignorer. Ce cas exige une règle éditoriale claire : comment distinguer une image informative d'une image décorative dans le workflow de contribution.

PDF : le point aveugle des organisations

Le PDF accessible est le sujet le moins bien maîtrisé dans les équipes de contenu. Un PDF visuellement correct peut être totalement illisible pour un lecteur d'écran, sans que l'éditeur ne le remarque.

Les points de défaillance les plus fréquents :

L'ordre de lecture. Dans un PDF, l'ordre dans lequel le lecteur d'écran parcourt le contenu n'est pas forcément l'ordre visuel. Sans balisage correct, le lecteur peut parcourir les colonnes dans le mauvais sens, sauter des éléments ou répéter des en-têtes.

Les tableaux. Un tableau dans un PDF doit avoir des en-têtes de colonnes et de lignes correctement balisés. Dans la plupart des exports Word ou InDesign, cette information est absente.

Les formulaires. Les champs de formulaire dans un PDF doivent avoir des labels associés. Sans label, un lecteur d'écran annonce « Zone de texte » sans indiquer ce qu'elle attend.

Les images dans les PDF. Mêmes règles que pour le web : texte alternatif sur les images informatives, attribut vide sur les images décoratives. Les PDF générés par export n'appliquent pas ces règles par défaut.

Drupal héberge les documents dans la Media Library. Quelques ajustements concrets au workflow de publication :

• Ajouter un champ « PDF vérifié » (booléen ou liste de statut) sur l'entité Media de type document.
• Bloquer la publication d'un document si ce champ n'est pas renseigné.
• Associer un guide de production : les équipes qui génèrent des PDF depuis Word utilisent les styles de titre natifs (Titre 1, Titre 2...), ce qui produit une structure taggée à l'export.
• Prévoir un outil de vérification en aval, comme PAC 2024 ou Adobe Acrobat Pro, avant import dans Drupal.

Un workflow complet pour les médias accessibles

Ce workflow s'applique à une organisation avec une équipe de contribution distincte de l'équipe technique.

Étape 1 : configuration du CMS. L'équipe technique configure les types de contenu et les entités Media pour rendre obligatoires les champs d'accessibilité (texte alternatif, sous-titres, statut de vérification PDF). Elle documente les formateurs de champ activés pour les vidéos.

Étape 2 : guide de contribution. Un document de référence, accessible depuis l'interface Drupal via un lien dans le formulaire de contribution, explique comment rédiger un texte alternatif, comment attacher un fichier WebVTT, et comment vérifier un PDF avant import.

Étape 3 : vérification avant publication. Dans le workflow de publication Drupal (modules Workflow ou Content Moderation), un état intermédiaire « En revue accessibilité » bloque la publication le temps qu'un responsable contenu valide les médias associés.

Étape 4 : audit périodique. Le module Editoria11y (compatible Drupal 9/10) analyse le contenu publié et remonte les problèmes d'accessibilité directement dans l'interface éditoriale, sans passer par un audit externe ponctuel.

Rôles et responsabilités

L'équipe Drupal configure les types de contenu, active les modules, et définit les règles de workflow. C'est là que se décide ce qui est techniquement obligatoire.

Les équipes de production de contenu (communication, marketing, juridique) livrent des médias conformes : vidéos avec fichier de sous-titres séparé, PDF produits avec des styles de titre natifs, images accompagnées d'un texte descriptif.

Les contributeurs Drupal saisissent les informations d'accessibilité dans le CMS au moment de l'import. Un champ vide sans règle de blocage devient systématiquement un champ ignoré.

Le responsable contenu ou référent accessibilité valide avant publication. Sans cette étape dans le workflow, la vérification reste déclarative.

Le RGAA (Référentiel général d'amélioration de l'accessibilité) impose des obligations précises aux organismes publics et à certaines entreprises privées au-delà d'un seuil de chiffre d'affaires. Mais au-delà de la conformité réglementaire, l'accessibilité des médias concerne tous les éditeurs de contenu Drupal qui s'adressent à des publics larges.

Ce que ça change dans la pratique

Un workflow structuré autour de l'accessibilité médias produit deux effets concrets.

Le premier : une réduction des corrections après publication. Sans workflow, les équipes corrigent en urgence quand un audit ou une réclamation remonte un problème. Avec un workflow, le problème est détecté avant que le contenu soit visible.

Le second : une meilleure qualité globale du contenu. Un texte alternatif rédigé avec soin est aussi un contenu mieux indexé par les moteurs de recherche. Un PDF structuré est un document plus facile à naviguer pour tous les utilisateurs, pas seulement ceux qui utilisent un lecteur d'écran.

DrupaLabs accompagne les organisations qui veulent intégrer l'accessibilité dans leur workflow Drupal : configuration des types de contenu, activation des modules de vérification, formation des équipes de contribution, audit de l'existant.

Tout commence par un diagnostic des processus en place.