« Ce document ne contient aucune structure de balises. » C’est le verdict, sans appel, que renvoie le vérificateur d’accessibilité intégré à un lecteur PDF standard sur un rapport annuel pourtant soigné visuellement, généré automatiquement depuis une page WordPress via un plugin d’export. Le fichier ouvert dans un lecteur classique donne toutes les apparences d’un document professionnel : titres bien hiérarchisés visuellement, tableau de chiffres clés, mise en page à deux colonnes. Et pourtant, aucun lecteur d’écran ne peut en extraire la moindre information exploitable.
Ce cas est devenu plus fréquent avec la généralisation des générateurs de PDF qui convertissent une page HTML en image rastérisée avant de l’assembler en document final, pour préserver fidèlement une mise en page complexe difficile à reproduire avec les outils de composition PDF traditionnels. Le résultat visuel est irréprochable. La structure interne, elle, est souvent absente ou réduite à un unique bloc d’image sans aucun texte réel sélectionnable.
Distinguer rendu visuel et structure interne
Un document PDF conforme aux exigences d’accessibilité (norme PDF/UA, elle-même alignée avec les critères WCAG applicables aux documents) doit contenir un arbre de balises structurelles : des balises H1, H2, P, Table, Figure qui décrivent la nature de chaque élément, indépendamment de son apparence visuelle. C’est cet arbre que consulte un lecteur d’écran pour naviguer dans le document par titres, comme il le ferait sur une page web bien structurée.
Le problème des générateurs basés sur la capture d’écran ou le rendu en image, c’est qu’ils ne produisent tout simplement pas cet arbre : le contenu visible est une image plate, sans aucune information sémantique associée, exactement comme une photographie de texte scannée sans reconnaissance optique de caractères.
Où se cache le défaut dans la chaîne de génération
Sur le projet concerné, la chaîne technique reposait sur un service tiers qui prenait une capture d’écran haute résolution d’une page HTML dédiée à l’impression, puis assemblait ces captures en pages PDF successives. Cette approche garantit un rendu visuel pixel perfect, identique quel que soit le lecteur PDF utilisé, mais sacrifie entièrement la couche sémantique du document.
Vérifier avant de publier
Un contrôle simple, réalisable sans outil spécialisé, permet de détecter ce type de défaut avant publication : ouvrir le PDF généré et tenter une sélection de texte à la souris. Si la sélection encadre l’intégralité de la page comme s’il s’agissait d’une seule image, sans permettre d’isoler un mot ou une phrase précise, le document ne contient probablement aucun texte réel. Un second test, plus rigoureux, consiste à ouvrir le panneau des balises d’accessibilité dans Adobe Acrobat ou un outil équivalent, qui affiche directement l’arbre structurel du document, ou son absence.
- Tenter une sélection de texte à la souris sur chaque page du PDF généré.
- Vérifier la présence d’un arbre de balises via le panneau d’accessibilité du lecteur PDF.
- Tester la recherche de texte (Ctrl+F) : un document sans texte réel ne trouvera jamais aucune occurrence.
- Contrôler que le titre du document (les métadonnées, pas seulement le texte visible) est correctement renseigné.
Vers une génération respectueuse de la structure
La correction durable ne consiste pas à retoucher chaque PDF généré, mais à changer d’approche de génération : privilégier un moteur qui compose le PDF à partir du HTML source structuré (en conservant les balises h1 à h6, les listes, les tableaux) plutôt qu’un moteur qui capture visuellement le rendu final. Plusieurs bibliothèques PHP permettent cette approche sans dépendre d’un service tiers propriétaire, à condition de vérifier explicitement qu’elles exportent un arbre de balises et pas seulement une mise en page visuelle correcte.
Sur ce projet précis, le changement de moteur de génération a nécessité de revoir intégralement le gabarit HTML source, car celui-ci utilisait des positionnements absolus en pixels incompatibles avec une conversion structurée — un rappel que l’accessibilité d’un document final dépend directement de la rigueur structurelle du contenu qui lui sert de source.
En résumé
Un PDF peut être visuellement parfait et totalement inutilisable pour un lecteur d’écran : ce sont deux qualités indépendantes, et seule la seconde garantit une réelle accessibilité. Avant toute publication d’un document généré automatiquement, un contrôle rapide de sélection de texte et de structure de balises permet d’éviter cette confusion fréquente entre apparence et accessibilité réelle.
