La décision unique qui conditionne toutes les étapes suivantes est l’environnement de création. Un PDF généré depuis un document InDesign correctement structuré avec l’action Rendre accessible appliquée transporte 80 pour cent de ses métadonnées d’accessibilité avant même qu’on ouvre Acrobat. Un PDF exporté depuis un document Word dont les titres ont été simulés avec du texte en gras et en plus grande taille n’en transporte presque aucune, et aucune correction en aval ne pourra pleinement le récupérer. Le choix de l’outil de création, autrement dit, n’est pas esthétique. Il est structurel.

Trois chaînes de production dominent l’édition institutionnelle en 2026. Adobe InDesign avec l’action Rendre accessible est le standard pour les documents mis en page — rapports annuels, manuels scolaires, dépôts réglementaires — où la mise en page est fixe et le fichier quitte l’équipe de conception une seule fois. Microsoft Word avec Enregistrer en PDF accessible est le cheval de bataille pour les documents de bureau — politiques, contrats, courriers — où la source est modifiée en continu et le PDF est un rendu plutôt qu’une destination. LibreOffice avec la remise au vérificateur d’accessibilité PDF est la voie open source utilisée par les gouvernements et universités qui ont des raisons politiques d’éviter les stacks Microsoft et Adobe.

Sous tout PDF accessible se trouve une structure logique parallèle — l’arbre de balises — qui n’a rien à voir avec la mise en page visuelle. Le PDF visible est un ensemble d’instructions de rendu adressées par coordonnées. L’arbre de balises est un modèle objet documentaire hiérarchique distinct qui indique cette opération de rendu est le premier titre, celle-là est le troisième point de la deuxième liste, cette image est décorative, cette autre image a le texte alternatif « Chiffre d’affaires trimestriel par segment, exercice 2024 ». Un lecteur d’écran lit l’arbre de balises, pas le rendu visuel.

Six catégories de balises portent l’essentiel du sens dans les documents réels : les titres (H1 à H6) forment le plan navigable ; les paragraphes (P) sont les blocs de texte courant ; les listes (L, LI, Lbl, LBody) sont les énumérations ordonnées ou non ordonnées ; les tableaux (Table, TR, TH, TD) sont les grilles de données dont les en-têtes de colonnes et de lignes sont exposés via l’attribut Scope ; les figures (Figure) portent le texte alternatif sur leur attribut Alt ou ActualText ; et l’ordre de lecture, qui est le parcours en profondeur de l’arbre lui-même, dicte la séquence dans laquelle le lecteur d’écran prononce le document. Une page qui paraît correcte en deux colonnes peut se lire dans le mauvais ordre si l’arbre de balises place la colonne droite avant la gauche.

Deux autres attributs importent sur toutes les balises d’un fichier correctement produit. L’attribut de langue (Lang) indique au lecteur d’écran quel dictionnaire de prononciation utiliser — du français cité dans un paragraphe anglais a besoin de son propre attribut Lang sur une balise Span, sinon il sera lu avec une phonologie anglaise. Et le marqueur d’artefact distingue le contenu décoratif du contenu structurel ; les en-têtes, pieds de page, numéros de page et filets décoratifs doivent tous être marqués comme artefacts pour que le lecteur d’écran les ignore.

PDF/UA est la norme internationale pour les PDF accessibles, publiée sous la référence ISO 14289-1 en 2014 et mise à jour en 2024. Là où WCAG est neutre vis-à-vis de la technologie et de la plateforme, PDF/UA est spécifique aux PDF — c’est le contrat entre le logiciel producteur de documents, le logiciel consommateur de documents et la technologie d’assistance qui stipule que l’arbre de balises, les métadonnées et la structure de ce fichier sont conformes à un ensemble de conditions vérifiables, de sorte qu’un lecteur conforme peut s’y fier.

La norme est mise en œuvre par le biais du protocole Matterhorn, maintenu par la PDF Association, qui décompose PDF/UA en 31 conditions d’échec numérotées avec des variantes vérifiables par machine et vérifiables par des personnes. Les échecs vérifiables par machine comprennent l’absence de titre de document dans les métadonnées, la présence de figures sans Alt ni ActualText, des listes structurées hors des balises L/LI, et des attributs de langue manquants sur le document ou sur les passages de changement de langue. Les échecs vérifiables par des personnes couvrent ce que les logiciels ne peuvent pas vérifier seuls — si le texte alternatif d’une Figure décrit réellement la figure, si l’ordre de lecture correspond à la séquence logique, si les titres sont imbriqués logiquement plutôt que sautés.

La mise à jour de 2024 a aligné PDF/UA sur les critères de succès WCAG 2.2 et a clarifié le traitement des signatures numériques et des formulaires — les formulaires PDF accessibles doivent exposer les libellés de champ, les infobulles de champ et l’ordre de tabulation, et les PDF signés ne doivent pas bloquer l’accès du lecteur d’écran à l’arbre de balises sous-jacent après la signature.

Quand un PDF arrive sans arbre de balises utilisable — ce qui est le cas de la plupart des PDF patrimoniaux — le choix de l’ingénieur se réduit à quatre environnements de correction. Chacun présente une combinaison différente de points forts en matière d’édition de l’arbre de balises, de reconnaissance optique de caractères pour les originaux numérisés, de traitement par lots et de rapports PDF/UA. La matrice ci-dessous met en regard les capacités et les outils.

Un PDF correctement balisé ne représente que la moitié de la chaîne côté producteur. L’autre moitié est le lecteur d’écran, et les quatre lecteurs qu’utilisent réellement la plupart des utilisateurs traitent le même fichier de manière subtilement différente. Ces différences importent car un document qui se lit bien dans JAWS peut trébucher dans NVDA, et un fichier qui fonctionne dans VoiceOver sur macOS peut se comporter différemment quand le même fichier est ouvert par ChromeVox dans la visionneuse PDF intégrée à Chrome.

JAWS dispose du support PDF le plus profond et le plus ancien de tous les lecteurs d’écran commerciaux. Son mode PDF rend les PDF balisés via Acrobat ou Acrobat Reader et expose directement l’arbre de balises — liste des titres (Insertion+F6), liste des formulaires (Insertion+F5), navigation dans les cellules de tableau avec les touches de tableau JAWS standard. Quand un PDF n’a pas de balises, JAWS proposera de déduire la structure, mais le résultat déduit est peu fiable ; les ingénieurs ne doivent pas valider sur la base de lectures déduites par JAWS.

NVDA lit les PDF balisés également via Acrobat ou Acrobat Reader, avec une navigation en mode navigation qui reproduit son modèle de page web — H pour sauter les titres, K pour les liens, T pour les tableaux. Le support PDF de NVDA s’est nettement amélioré depuis 2022, mais reste en retrait de JAWS pour les tableaux complexes et les champs de formulaire. NVDA donne un retour plus honnête sur les documents aux balises malformées : là où JAWS peut persévérer, NVDA tend à se taire, ce qui est utile pour le diagnostic.

VoiceOver sur macOS lit les PDF via Aperçu et Safari avec navigation par le rotor (VO + U) sur les titres, liens, tableaux et champs de formulaire. VoiceOver est le plus tolérant des quatre — il reconstruit un ordre de lecture même pour des fichiers mal balisés — mais cette tolérance peut masquer de vrais problèmes. Un document qui se lit de manière acceptable dans VoiceOver doit tout de même être vérifié dans JAWS ou NVDA, et non l’inverse.

ChromeVox sur ChromeOS, et plus généralement le comportement de tout lecteur d’écran interagissant avec la visionneuse PDF intégrée à Chrome, appartient à une catégorie différente. La visionneuse PDF de Chrome rastérise et réextrait le texte plutôt que de rendre l’arbre de balises original, de sorte qu’un PDF avec un arbre de balises propre peut perdre une grande partie de sa structure quand il est ouvert directement dans Chrome. Le contournement pour les contextes critiques en matière d’accessibilité est de forcer le téléchargement du fichier et de l’ouvrir dans Acrobat Reader, ou de fournir une alternative HTML.

Pour assembler la chaîne : un PDF accessible unique passe par six étapes concrètes. Elles sont séquentielles — sauter l’une d’elles produit un fichier qui échouera à l’une des étapes ultérieures ou entre les mains de l’utilisateur.

Les équipes qui traitent l’accessibilité des PDF comme un problème de correction en passe finale finissent par payer deux fois — une fois pour corriger un fichier produit sans intention structurelle, et à nouveau chaque fois que ce fichier est mis à jour. Les équipes qui le traitent comme un problème de création construisent l’arbre de balises à la source, le régénèrent proprement à chaque révision, et utilisent PAC et un lecteur d’écran comme vérification plutôt que comme réparation. La différence de coût entre les deux postures est importante ; la différence d’accessibilité est plus grande encore.

La chaîne documentée ci-dessus est délibérément agnostique vis-à-vis des outils à chaque maillon. Que l’amont soit InDesign ou LibreOffice, l’éditeur Acrobat ou Foxit, le vérificateur PAC, et le lecteur d’écran JAWS ou NVDA, la logique structurelle est la même : les styles de paragraphe se mappent sur des balises, les balises se conforment à PDF/UA, PDF/UA est vérifié par PAC, et les lecteurs d’écran lisent le résultat. Les outils changent ; la chaîne ne change pas.

Pour les équipes responsables des marchés publics et de la mise en conformité, l’implication opérationnelle est que les déclarations d’accessibilité des PDF doivent référencer la chaîne de production — l’outil de création, l’action d’export, le vérificateur — et pas seulement un résultat du vérificateur Acrobat. Pour les équipes d’ingénierie, l’implication est que l’arbre de balises est la source de vérité, et que l’arbre de balises est construit en amont de tout PDF que l’utilisateur verra jamais. Pour un guide de production pas-à-pas qui complète ce primer, voir le playbook étape par étape sur l’accessibilité des PDF.