# Baliser structurellement les PDF d’une médiathèque municipale publiés sur WordPress

> Étude de cas sur des centaines de PDF déposés dans la bibliothèque de médias d'un site municipal, sans aucune structure exploitable par un lecteur d'écran.

- Auteur : WordPress Développement
- Publié le : 2020-05-18
- Mis à jour le : 2020-05-18
- Catégorie : Accessibilité
- URL : https://www.wpmoderne.fr/accessibilite/baliser-pdf-mediatheque-municipale-wordpress/

## L’essentiel

- Un PDF sans balises n'est qu'une image de texte pour un lecteur d'écran
- La structure se construit dans le logiciel source, pas après coup
- La bibliothèque de médias WordPress ne corrige rien automatiquement

Un PDF issu d'un export Word sans styles de titres n'est, pour un lecteur d'écran, qu'une suite de blocs de texte sans hiérarchie ni relation logique. C'est le constat de départ d'un audit mené sur le site d'une médiathèque municipale, dont la bibliothèque de médias WordPress hébergeait plusieurs centaines de documents : programmes d'animations, règlements, formulaires d'inscription, bulletins mensuels.

Le thème du site avait déjà fait l'objet d'un travail de mise en conformité correct : contrastes vérifiés, formulaires étiquetés, navigation au clavier fonctionnelle. Mais l'audit thématique consacré aux documents bureautiques a révélé un angle mort classique, souvent ignoré parce qu'il ne se voit pas dans une page HTML : le contenu des fichiers déposés dans la médiathèque de contenus.

## Le point de départ : une bibliothèque de médias, pas un outil d'accessibilité

La bibliothèque de médias de WordPress gère l'upload, le renommage, l'organisation par date et la génération de vignettes. Elle ne modifie jamais le contenu binaire d'un fichier PDF déposé : ce qui entre structuré ressort structuré, ce qui entre en image scannée ressort en image scannée. Aucun réglage du cœur de WordPress, aucune extension de gestion documentaire, ne peut ajouter a posteriori une structure absente du fichier source.

Sur les 340 documents recensés dans la médiathèque du site audité, un test avec un lecteur d'écran sur un échantillon de cinquante fichiers a montré que seuls trois d'entre eux exposaient une arborescence de titres cohérente à la navigation. Les autres se présentaient comme un bloc de texte continu, ou pire, comme une image plein cadre issue d'un scanner, sans aucune couche de texte reconnaissable.

## Diagnostic : trois origines distinctes du même problème

L'analyse des fichiers par lot a permis de classer les documents en trois catégories, chacune appelant une correction différente :

- Des documents Word exportés en PDF sans utilisation des styles de titres intégrés (Titre 1, Titre 2), ce qui prive l'export de toute base structurelle à convertir en balises.
- Des formulaires d'inscription scannés à plat, sans reconnaissance optique de caractères, donc totalement invisibles pour un lecteur d'écran.
- Des documents mis en page directement dans un logiciel de PAO, exportés sans jamais activer l'option de génération de balises d'accessibilité.

> L'essentiel à retenir : Un PDF sans balises n'est qu'une image de texte pour un lecteur d'écran ; La structure se construit dans le logiciel source, pas après coup ; La bibliothèque de médias WordPress ne corrige rien automatiquement

## La correction, document par document

Pour la première catégorie, la solution la plus économe consistait à reprendre les fichiers sources Word ou LibreOffice, appliquer systématiquement les styles de titres plutôt qu'une mise en forme visuelle manuelle (gras et taille de police appliqués à la main), ajouter un texte alternatif aux images incluses, puis ré-exporter en cochant l'option de document balisé disponible dans les dialogues d'export PDF des deux suites bureautiques.

```
Word : Fichier -> Exporter -> Créer PDF/XPS
      -> Options -> cocher "Balises de structure de document"

LibreOffice Writer : Fichier -> Exporter au format PDF
      -> onglet Général -> cocher "Créer un document universel
      accessible (PDF/UA)"
```

Pour les formulaires scannés, aucun raccourci n'existe : une reconnaissance optique de caractères a été appliquée via un outil dédié, suivie d'une relecture manuelle des zones de texte reconnues, puis d'un étiquetage explicite des champs de saisie quand le formulaire restait interactif. Pour les documents issus de PAO, la reprise a été plus coûteuse : redéfinir l'ordre de lecture logique dans le panneau de balises, associer chaque image à une description, et vérifier que les tableaux de données conservaient leurs relations d'en-tête après export.

## Ce que l'audit a permis de prioriser

Refaire l'intégralité des 340 documents n'était budgétairement pas réaliste pour la collectivité. Le tri s'est fait sur deux critères croisés : la fréquence de consultation, mesurée dans les statistiques de téléchargement du site, et l'obligation réglementaire attachée au document, un formulaire d'inscription administratif pesant plus lourd qu'une affiche d'événement ponctuel déjà passée.

| Catégorie de document | Volume concerné | Traitement retenu |
| --- | --- | --- |
| Formulaires administratifs actifs | 18 fichiers | Reprise complète et test lecteur d'écran |
| Programmes d'animations en cours | 6 fichiers | Reprise complète |
| Bulletins et archives anciennes | plus de 250 fichiers | Remplacement progressif par une page HTML pour les nouveaux, conservation en l'état pour l'existant |

## La leçon pour un site propulsé par WordPress

Un audit d'accessibilité centré sur le thème et les gabarits HTML peut afficher un score flatteur tout en laissant de côté l'essentiel du contenu réellement consulté par les usagers d'une médiathèque : les documents téléchargeables. La bibliothèque de médias n'étant qu'un espace de stockage, la responsabilité de la structure revient entièrement au processus de production du document, en amont de tout dépôt sur le site.

> Un réflexe simple à instaurer côté rédaction : avant de déposer un PDF, se demander si un lecteur d'écran pourrait en restituer le plan en trente secondes. Si la réponse est non, le document n'est pas prêt à être publié.

## Pour aller plus loin

Cette étude de cas ne traite pas la question, distincte, de l'accessibilité du thème WordPress qui héberge les liens vers ces documents : ordre de tabulation, intitulés de liens, structure de la page de téléchargement relèvent d'un autre chantier, déjà traité par ailleurs sur ce blog. Le point à retenir ici tient en une phrase : un PDF accessible se construit dans le logiciel qui le produit, jamais dans l'outil qui l'héberge.