« Ce document PDF ne respecte pas le critère 12.7 du RGAA » : cette remarque revient dans la quasi-totalité des audits menés pour des sites de collectivités qui publient des comptes rendus de conseil municipal, des délibérations ou des arrêtés au format PDF généré automatiquement depuis WordPress. Le problème ne se limite pas à la lisibilité du texte : il porte sur la structure interne du document, invisible à l’œil mais déterminante pour un lecteur d’écran.
Ce qui distingue un PDF « lisible » d’un PDF conforme PDF/UA
Un PDF exporté depuis une page HTML via une bibliothèque comme dompdf ou mPDF produit, dans la majorité des configurations par défaut, un document où le texte est bien présent et sélectionnable, mais où la hiérarchie des titres, l’ordre de lecture logique et le rôle de chaque élément (tableau, liste, image) ne sont pas déclarés dans les métadonnées internes du fichier. La norme ISO 14289, dite PDF/UA (Universal Accessibility), exige précisément cette structuration : un arbre de balises (StructTreeRoot) qui reflète l’organisation logique du contenu, indépendamment de sa mise en forme visuelle.
Pourquoi l’export « capture HTML » échoue systématiquement
La méthode la plus répandue dans les extensions maison consiste à générer une page HTML propre, puis à la convertir en PDF via une bibliothèque de rendu. Cette approche produit un fichier visuellement correct, mais dépourvu de la couche d’accessibilité : les balises <h2> et <table> du HTML source ne sont pas automatiquement traduites en équivalents structurels dans le PDF final, car le moteur de rendu se concentre sur le positionnement visuel des caractères.
La méthode retenue : structurer explicitement au moment de la génération
Pour un client collectivité publiant plusieurs centaines de délibérations par an, la solution a consisté à utiliser mPDF avec son support natif du balisage PDF/UA, en construisant explicitement chaque bloc structurel plutôt qu’en convertissant un template HTML générique :
use Mpdf\Mpdf;
$mpdf = new Mpdf( array(
'mode' => 'UTF-8',
) );
$mpdf->SetTitle( $deliberation->get_title() );
$mpdf->SetLang( 'fr' );
// Active le mode "Tagged PDF", prérequis de PDF/UA
$mpdf->PDFA = true;
$mpdf->PDFAauto = true;
$html = sprintf(
'<h1>%s</h1><p>%s</p>',
esc_html( $deliberation->get_title() ),
wp_kses_post( $deliberation->get_body() )
);
$mpdf->WriteHTML( $html );
$mpdf->Output( 'deliberation.pdf', 'D' );
Le réglage PDFAauto ne suffit pas à lui seul à garantir la conformité PDF/UA complète (il vise avant tout l’archivage à long terme, norme PDF/A, proche mais distincte) : une vérification manuelle à l’aide d’un outil comme le PAC (PDF Accessibility Checker) reste nécessaire avant publication, en particulier sur l’ordre de lecture des tableaux de résultats de vote.
Checklist avant publication d’un document généré
- Le titre du document (métadonnée
Title) est renseigné, distinct du nom de fichier. - La langue du document est déclarée (
SetLang( 'fr' )), y compris pour les portions citées dans une autre langue le cas échéant. - La hiérarchie des titres suit un ordre logique sans saut de niveau (pas de
<h3>direct après un<h1>). - Chaque tableau de données possède des en-têtes de colonnes correctement déclarés.
- Aucune information n’est portée uniquement par la couleur (résultat de vote « pour » en vert sans texte associé, par exemple).
- Le document passe la vérification PAC sans erreur bloquante avant mise en ligne.
Le cas des tableaux de vote
Les tableaux récapitulant les votes (pour, contre, abstention) par élu posaient une difficulté particulière : leur structure en grille à deux dimensions n’était correctement restituée par les lecteurs d’écran qu’après ajout explicite des attributs d’en-tête de ligne et de colonne dans le HTML source, avant conversion — un simple tableau visuel ne suffisait pas.
Sur un document public de collectivité, l’accessibilité n’est pas une option esthétique : c’est souvent la seule voie d’accès légale à une information administrative pour un administré malvoyant.
Pour aller plus loin
La génération de PDF/UA depuis WordPress reste un sujet où la documentation francophone est rare et où les bibliothèques PHP disponibles couvrent la norme de façon inégale. Documenter précisément, dans le code de l’extension, quelles vérifications restent manuelles évite de faire croire à une conformité automatique qui n’existe pas encore réellement dans l’écosystème PHP actuel.
