PDF accessibles et Drupal

Beaucoup d'organisations investissent dans l'accessibilité de leur site web, puis oublient un pan entier de leurs contenus : les documents PDF. Rapports annuels, formulaires administratifs, fiches produit, comptes rendus de conseil municipal, brochures téléchargeables. Ces fichiers représentent souvent une part importante de l'information publiée, et dans la majorité des cas, ils ne sont pas accessibles. Pour une personne qui navigue au lecteur d'écran, un PDF mal balisé est au mieux pénible à parcourir, au pire totalement illisible. Pour une organisation soumise au RGAA, c'est aussi un risque de non-conformité que les audits relèvent systématiquement.

La bonne nouvelle, c'est que le problème est cernable et que les solutions existent. Cet article explique pourquoi les PDF posent un problème spécifique, quels critères RGAA s'appliquent à eux, comment générer des PDF accessibles depuis Drupal, comment vérifier leur conformité et pourquoi l'alternative HTML mérite presque toujours d'être considérée en complément.

Pourquoi les PDF posent un problème d'accessibilité

Un PDF, par défaut, n'est qu'une représentation visuelle figée. Quand un outil génère un PDF sans précaution, il décrit où placer chaque caractère sur la page, mais il n'enregistre aucune information sur la nature de ce contenu. Un titre ressemble visuellement à un titre parce qu'il est en gras et plus gros, mais rien dans le fichier ne dit que c'est un titre. Pour un œil humain, la mise en forme suffit à comprendre la structure. Pour un lecteur d'écran, qui s'appuie sur le balisage et non sur l'apparence, cette information n'existe pas.

L'absence de structure sémantique. C'est le cœur du problème. Un PDF accessible doit contenir un arbre de balises (le tagged PDF) qui décrit la hiérarchie du document : titres, paragraphes, listes, tableaux, liens. Sans cet arbre, le lecteur d'écran ne peut pas annoncer "titre de niveau 2" ni permettre à l'utilisateur de naviguer de section en section. Le document devient un bloc de texte continu, sans repères.

Le balisage manquant ou incorrect. Même quand un PDF contient des balises, elles sont fréquemment erronées : des titres marqués comme de simples paragraphes, des tableaux de données reconstruits comme des suites de cellules sans en-têtes, des images décoratives non marquées comme telles. Un balisage approximatif peut être pire qu'absent, car il induit l'utilisateur en erreur.

Le contenu non textuel. Un PDF produit par numérisation (un scan) est une image. Sans couche de texte issue de la reconnaissance optique de caractères (OCR), aucun texte n'est sélectionnable ni lisible par une technologie d'assistance. C'est un cas extrêmement courant pour les documents administratifs numérisés.

Les critères RGAA applicables aux PDF

Le RGAA ne traite pas le PDF comme un format à part : un document bureautique en téléchargement est soumis aux mêmes exigences d'accessibilité que le reste du contenu, dès lors qu'il porte de l'information. Plusieurs critères se révèlent particulièrement structurants pour les PDF.

Le PDF doit être balisé. C'est la condition de base. Le document doit contenir un arbre de balises correct qui reflète sa structure logique. Sans balisage, aucun autre critère ne peut réellement être satisfait.

L'ordre de lecture doit être cohérent. Le lecteur d'écran parcourt le contenu dans l'ordre défini par l'arbre de balises, pas dans l'ordre visuel. Sur une mise en page en colonnes ou avec des encadrés, l'ordre de lecture logique peut diverger de l'ordre d'affichage. Il faut s'assurer que la séquence annoncée a du sens.

La langue du document doit être déclarée. Le PDF doit indiquer sa langue principale (français, par exemple) pour que la synthèse vocale utilise la bonne prononciation. Les passages dans une autre langue devraient être signalés individuellement.

La hiérarchie des titres doit être respectée. Les titres doivent être structurés en niveaux logiques (titre 1, titre 2, titre 3) sans saut de niveau injustifié. Cette hiérarchie permet la navigation rapide et donne à l'utilisateur une vue d'ensemble du document.

À ces points s'ajoutent les exigences classiques : alternatives textuelles pour les images porteuses d'information, en-têtes explicites pour les tableaux de données, contraste suffisant des couleurs, libellés clairs pour les champs de formulaire dans les PDF interactifs. Le standard de référence pour un PDF nativement accessible est le format PDF/UA, conçu spécifiquement pour ces enjeux. Si vous voulez situer ces critères dans le cadre global de votre conformité, notre page sur l'accessibilité RGAA Drupal détaille la démarche d'ensemble.

Générer des PDF accessibles depuis Drupal

La règle fondamentale est simple : l'accessibilité d'un PDF généré dépend de l'accessibilité de sa source. Si le HTML ou le template à partir duquel le PDF est produit est bien structuré, le moteur de génération peut transposer cette structure dans l'arbre de balises du PDF. Si la source est un assemblage visuel sans sémantique, le PDF en héritera.

Partir de sources balisées. Dans Drupal, les PDF sont souvent générés à partir de contenu HTML : un nœud, une vue, un template Twig dédié. La première étape consiste donc à soigner ce HTML source : utiliser de vraies balises de titre, des listes réelles, des tableaux avec en-têtes, des attributs alt sur les images. Un HTML propre est la matière première d'un PDF propre.

Choisir un moteur de génération adapté. L'écosystème Drupal propose plusieurs approches. Des modules comme Entity Print permettent de générer des PDF à partir d'entités Drupal, en s'appuyant sur des bibliothèques de rendu comme Dompdf, mPDF ou des moteurs basés sur un navigateur headless (Chrome via des outils comme Weasyprint ou les API de rendu Chromium). Le niveau de support du PDF balisé varie selon le moteur : tous ne produisent pas un arbre de balises complet de la même façon, et il faut valider ce point au moment du choix technique plutôt que de le découvrir à l'audit.

Maîtriser les métadonnées et la langue. Au-delà du contenu, le PDF généré doit porter ses métadonnées : titre du document, langue, éventuellement auteur. Ces informations se configurent au niveau du moteur de génération ou du template. C'est un réglage souvent négligé qui se corrige facilement une fois identifié.

Gérer le cas des PDF déjà existants. Beaucoup d'organisations ont un stock de PDF historiques uploadés dans la médiathèque Drupal au fil des ans. Ceux-là ne seront pas corrigés par un changement de moteur de génération. Il faut les inventorier, prioriser les plus consultés et décider au cas par cas : reprise du balisage dans un outil dédié, régénération depuis la source si elle existe encore ou remplacement par une version HTML.

Vérifier la conformité des PDF

Générer un PDF que l'on croit accessible ne suffit pas : il faut le vérifier, idéalement de façon outillée puis manuelle. La vérification automatique attrape les problèmes structurels évidents, mais seul un contrôle humain valide l'ordre de lecture et la pertinence des alternatives textuelles.

PAC (PDF Accessibility Checker). C'est l'outil de référence gratuit pour vérifier la conformité au standard PDF/UA et aux critères WCAG applicables. Il analyse l'arbre de balises, signale les erreurs et propose un aperçu de la structure logique telle qu'elle sera annoncée par un lecteur d'écran. Tout PDF destiné à être publié devrait passer par PAC.

Acrobat Pro. L'outil d'Adobe intègre un vérificateur d'accessibilité et, surtout, des fonctions de correction : ajout et réorganisation des balises, définition de l'ordre de lecture, ajout d'alternatives textuelles. C'est l'outil de prédilection pour reprendre manuellement un PDF existant qui ne peut pas être régénéré depuis sa source.

Le test au lecteur d'écran. Au-delà des outils automatiques, parcourir le document avec NVDA, JAWS ou VoiceOver reste le meilleur moyen de confirmer qu'il est réellement utilisable. C'est là qu'on détecte les incohérences d'ordre de lecture ou les alternatives textuelles inadaptées que les vérificateurs automatiques laissent passer.

Intégrer ces vérifications dans le workflow de publication évite de découvrir les problèmes a posteriori. Un audit Drupal ciblé sur l'accessibilité inclut généralement un échantillon des PDF publiés, parce qu'ils font partie intégrante du périmètre évalué par un audit de conformité RGAA et qu'ils sont souvent le maillon le plus faible.

L'alternative recommandée : proposer le contenu en HTML

Voici le point que les décideurs gagnent à intégrer tôt : dans une large majorité de cas, le contenu d'un PDF gagnerait à être disponible aussi en HTML accessible sur le site. Le PDF reste pertinent pour les documents destinés à être imprimés, archivés ou signés. Mais pour de l'information consultée à l'écran, le HTML présente des avantages décisifs.

Le HTML est nativement structuré. Une page Drupal bien construite porte sa sémantique par défaut : titres hiérarchisés, listes, tableaux avec en-têtes, liens explicites. L'accessibilité y est plus simple à atteindre et à maintenir que dans un PDF, où chaque correction demande un outil spécialisé.

Le HTML s'adapte à tous les contextes. Une page web se reflow sur mobile, se zoome sans casser la mise en page, s'adapte aux préférences de l'utilisateur (taille de police, contraste, mode sombre). Un PDF à mise en page fixe ne fait rien de tout cela, ce qui pénalise aussi bien les utilisateurs de technologies d'assistance que l'ensemble des visiteurs sur petit écran.

Le HTML est plus facile à maintenir dans Drupal. Le contenu vit dans le CMS, il est versionné, modifiable par les contributeurs sans logiciel tiers et indexé par la recherche interne comme par les moteurs. Un PDF, lui, est un fichier opaque qu'il faut régénérer et revérifier à chaque modification.

L'approche pragmatique consiste donc à publier l'information principale en HTML accessible, puis à proposer le PDF en complément pour ceux qui souhaitent imprimer ou archiver, en veillant à ce que ce PDF soit lui-même conforme. Vous offrez ainsi le meilleur des deux mondes sans sacrifier l'accessibilité, et vous réduisez la surface de contenus difficiles à maintenir dans le temps.

En résumé

Les PDF sont un angle mort fréquent des démarches d'accessibilité, alors qu'ils portent souvent de l'information essentielle. Les rendre conformes passe par trois leviers complémentaires : produire des PDF balisés depuis des sources HTML propres dans Drupal, vérifier systématiquement leur conformité avec PAC et Acrobat avant publication et privilégier le HTML accessible comme format principal chaque fois que c'est possible. Ces trois leviers se renforcent : un site dont le contenu est nativement bien structuré génère naturellement de meilleurs PDF et offre une alternative HTML de qualité.

C'est un chantier qui se traite méthodiquement, document après document, en commençant par les contenus les plus consultés. L'enjeu n'est pas seulement réglementaire : un contenu accessible est un contenu plus robuste, mieux référencé et utilisable par tous.

Vos PDF et votre site sont-ils réellement conformes? Faisons le point ensemble sur votre niveau d'accessibilité et les actions prioritaires. Parlons de votre projet.