Une norme de construction
Un PDF est d’abord un dessin : des caractères posés à des coordonnées sur une page. Rien, dans ce dessin, ne dit qu’une ligne en gras est un titre, que trois colonnes alignées forment un tableau, ou que le texte du bas de page doit être lu après celui du haut. Un lecteur voyant reconstitue tout cela d’un coup d’œil. Un lecteur d’écran, lui, ne voit que ce que le fichier déclare.
PDF/UA, pour PDF Universal Accessibility, est la norme internationale ISO 14289 qui fixe ce que le fichier doit déclarer pour être restitué correctement. C’est une norme de construction : elle décrit la forme du fichier, pas l’expérience de la personne qui le lit. Cette distinction commande tout le reste, et la plupart des malentendus sur la norme viennent de ce qu’on l’oublie.
Ce que PDF/UA est, et ce qu’il n’est pas
PDF/UA est la norme technique des PDF accessibles. Elle dit comment baliser le contenu, déclarer l’ordre de lecture, renseigner la langue, rattacher une alternative à chaque image porteuse de sens. Un fichier qui la respecte donne aux technologies d’assistance tout ce dont elles ont besoin pour fonctionner.
PDF/UA n’est pas, en revanche, une garantie que le document sera compris. La norme ne traite pas le contraste : elle s’en remet, dans une simple note, aux règles pour l’accessibilité des contenus web (WCAG). Elle exige qu’une image ait une alternative, pas que cette alternative soit juste. Elle encadre la succession des niveaux de titre, pas la pertinence de ce qu’on a choisi d’en faire un titre.
PDF/UA n’est pas non plus, en Europe, une obligation légale. Les textes nomment les WCAG, et c’est l’objet de notre article PDF/UA et WCAG : deux normes, deux questions. La norme reste pourtant nécessaire : on ne satisfait pas les WCAG dans un PDF sans construire ce PDF correctement, et c’est PDF/UA qui dit comment.
PDF/UA-1 ou PDF/UA-2 : laquelle viser ?
La norme a deux parties. PDF/UA-1 (ISO 14289-1, édition 2014) s’applique aux fichiers construits selon la spécification PDF 1.7. PDF/UA-2 (ISO 14289-2, publiée en mars 2024) s’applique aux fichiers PDF 2.0, dont elle exploite les nouveaux types de structure.
Le choix suit donc d’abord la version de PDF que produit réellement votre chaîne, et non la nouveauté de la norme. Il suit ensuite l’outillage : la prise en charge de PDF/UA-2 progresse dans les validateurs et les logiciels de correction, mais elle n’est pas encore générale. Une organisation qui produit aujourd’hui du PDF 1.7 et dont les outils de contrôle valident PDF/UA-1 n’a aucune raison de basculer pour le principe ; celle qui renouvelle sa chaîne de production a intérêt à poser la question dès le cahier des charges.
Bonne nouvelle pour qui veut aller à la source : la PDF Association met à disposition gratuitement le texte des deux parties, pour un usage individuel.
Ce que la norme exige dans le fichier
Sans reprendre la norme article par article, ses exigences se regroupent en quelques familles :
- Le balisage. Tout le contenu réel est rattaché à un arbre de balises, avec la balise la plus juste sémantiquement : titre, paragraphe, liste, tableau, figure.
- Les artefacts. Ce qui n’est que décor (filets, fonds, numéros de page répétés) est marqué comme tel, pour que le lecteur d’écran ne l’annonce pas.
- L’ordre de lecture. Le contenu est balisé dans l’ordre logique de lecture, qui n’est pas toujours l’ordre d’affichage : une colonne de droite, un encadré, une note de bas de page.
- Les alternatives. Toute image porteuse de sens a une alternative textuelle.
- Les tableaux. Les cellules d’en-tête sont identifiées comme telles, pour qu’une cellule de données puisse être restituée avec ses intitulés.
- La langue et le titre. La langue est déclarée, et le document a un titre dans ses métadonnées.
- Le sens porté par la forme. Aucune information n’est portée par la couleur, le contraste ou la mise en page seuls, sans que le balisage la reflète.
- Les formulaires et les liens. Les champs et les liens sont balisés et décrits.
- L’identification. Le fichier déclare dans ses métadonnées la partie de la norme qu’il revendique.
Le protocole Matterhorn : ce qu’un validateur peut affirmer
Une norme se lit, elle ne se vérifie pas d’elle-même. La PDF Association a donc publié le protocole Matterhorn, qui décline PDF/UA-1 en 31 points de contrôle et 136 conditions d’échec : la liste de toutes les manières dont un fichier peut manquer la norme.
Chaque condition d’échec y est classée selon qu’un logiciel peut la trancher seul ou qu’elle demande un examen humain. C’est l’apport le plus précieux du protocole, et le plus souvent oublié : il dit noir sur blanc qu’un validateur, si bon soit-il, ne peut pas déclarer seul un PDF conforme. Il établit l’absence de balisage, une langue manquante, une alternative absente. Il ne peut pas dire si la balise posée est la bonne, si l’ordre de lecture a un sens, si l’alternative décrit l’image.
Valider un PDF : le fichier d’abord, le rapport ensuite
Deux validateurs gratuits font référence : PAC, et veraPDF, logiciel libre qui couvre aussi bien PDF/UA-1 que PDF/UA-2. Leur rapport est indispensable, mais il trompe souvent ceux qui le lisent en premier.
L’expérience nous a appris à commencer par le fichier. Quel logiciel l’a produit ? S’agit-il de l’export accessible, ou de l’impression PDF du document source envoyée par erreur ? Le fichier est-il balisé du tout, sa langue est-elle déclarée ? Un rapport qui signale chaque objet texte comme « non balisé » ne décrit pas cent défauts à corriger un par un : il décrit un fichier qui n’a jamais été balisé, et la réponse est de repartir de la bonne source. Cette lecture prend trente secondes et évite des jours de correction inutile.
Puis vient le rapport, ligne par ligne. Et après lui, l’écoute : passer le document dans un lecteur d’écran, ou dans l’aperçu de restitution d’un outil de correction. C’est là qu’on entend ce qu’aucun validateur ne signale. Sur des catalogues balisés et déclarés conformes, nous avons ainsi trouvé des alternatives commençant par « Image de… » (redondant : le lecteur d’écran annonce déjà une image) et des prix découpés en « 2 », « 9 », « € », « ,70 », que l’utilisateur aveugle entendait comme quatre fragments sans rapport.
Produire du PDF/UA en masse, sur des documents à données variables
Tout ce qui précède vaut pour un document. Le problème change de nature quand le document n’est pas écrit mais généré : relevés de compte, avis d’échéance, factures, bulletins, contrats, produits par centaines de milliers à partir d’un même modèle et de données différentes à chaque pli.
Dans une chaîne de ce type, corriger les fichiers un par un n’a aucun sens. Le balisage se règle dans le modèle, une fois, et chaque document produit en hérite, avec ses qualités comme avec ses défauts. Trois conséquences en découlent, qui sont le cœur du sujet.
Valider le modèle sur des données qui le mettent à l’épreuve. Un modèle conforme sur le jeu d’essai peut échouer sur le pli réel : un tableau de mouvements qui se coupe sur deux pages et perd ses en-têtes, un bloc conditionnel vide qui laisse un titre orphelin, une langue qui change selon le client. Le jeu de validation doit contenir ces cas limites, pas seulement le cas nominal.
Contrôler la production par échantillonnage. On ne passe pas un million de plis au lecteur d’écran. On valide automatiquement un échantillon large, on écoute un échantillon réduit choisi pour couvrir les variantes du modèle, et on suit la mesure dans le temps.
Revalider à chaque évolution. Une mention légale ajoutée, un bloc déplacé, une nouvelle variante d’offre : chaque modification du modèle peut casser l’ordre de lecture de tous les documents qu’il produit. La conformité d’un modèle se prouve à chaque version, comme son exactitude, par comparaison automatique avant mise en production.
C’est exactement la discipline que demande une migration de plateforme de composition documentaire, et c’est notre métier depuis vingt-cinq ans. Rendre accessible une production de masse n’est pas un projet de correction de fichiers : c’est un projet d’industrialisation, qui se mène dans la chaîne existante plutôt qu’à côté.
Questions fréquentes
PDF/UA est-il la même chose qu’un PDF accessible ?
Non. PDF/UA décrit comment le fichier doit être construit pour que les technologies d’assistance puissent le restituer : balisage, ordre de lecture, langue, alternatives. Un PDF peut respecter cette construction et rester difficile à comprendre, par exemple si ses alternatives textuelles ne décrivent rien ou si son contraste est insuffisant. PDF/UA est une condition de l’accessibilité d’un PDF, pas sa garantie.
PDF/UA est-il obligatoire ?
Aucun des textes que nous avons lus ne l’impose : ni la directive européenne sur l’accessibilité, ni la norme EN 301 549, ni le RGAA. Ce que la loi exige, ce sont les WCAG. PDF/UA reste pourtant nécessaire en pratique, parce que c’est la manière technique de construire un PDF que les technologies d’assistance savent restituer. La nouvelle version d’EN 301 549, publiée en septembre 2026, le cite d’ailleurs, dans une note informative, comme la norme technique utile pour y parvenir.
Un PDF balisé suffit-il ?
Non. Le balisage est la première exigence de PDF/UA, pas la dernière. Un PDF peut avoir un arbre de balises complet et des titres mal hiérarchisés, des tableaux sans en-têtes, des alternatives vides ou des prix découpés en morceaux que le lecteur d’écran annonce un par un. La présence des balises se vérifie en quelques secondes ; leur justesse demande une relecture.
Comment vérifier un PDF gratuitement ?
Deux validateurs gratuits font référence, PAC et veraPDF, ce dernier en logiciel libre. Ils trouvent ce qu’une machine sait trancher. Avant de lire leur rapport, il vaut la peine de regarder le fichier lui-même : quel logiciel l’a produit, s’il est balisé du tout, si sa langue est déclarée. Et après le rapport, il reste à écouter le document avec un lecteur d’écran, ce qu’aucun validateur ne fait à votre place.
Peut-on rendre accessible automatiquement un PDF existant ?
En partie. Le balisage, l’ordre de lecture et la structure des tableaux s’automatisent largement, et c’est indispensable dès qu’il y a du volume. Ce qui ne s’automatise pas : décider si une alternative décrit vraiment l’image, si une hiérarchie de titres épouse la logique du document, si un tableau reste compréhensible lu de gauche à droite. Pour des documents produits en série, il est d’ailleurs plus efficace de corriger le modèle qui les génère que chaque fichier.