> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/latex/fr/autres-sujets/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md). # Introduction aux fichiers PDF balisés : fonctionnement interne et défis de l'accessibilité ## Mise à jour : janvier 2026 Veuillez consulter [les instructions d'Overleaf sur la création de PDF balisés](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs). Le [l'équipe LaTeX](https://latex-project.org/) a publié de nouvelles fonctionnalités qui permettent le balisage automatique des PDF, condition essentielle de l’accessibilité des PDF. Ces nouvelles fonctionnalités sont disponibles dans Overleaf dans [TeX Live 2025](http://\(https//www.overleaf.com/blog/tex-live-2025-is-now-available), avec des mises à jour plus récentes disponibles dans la version continue de TeX Live accessible via [Overleaf Labs](https://www.overleaf.com/labs/participate). Il est désormais possible de produire à partir de sources LaTeX un PDF balisé conforme au niveau AA des WCAG 2.1 en suivant [notre documentation utilisateur](https://docs.overleaf.com/writing-and-editing/creating-accessible-pdfs) à l’aide des versions de TeX Live disponibles dans Overleaf. L’article ci-dessous, datant de 2020, bien qu’il n’ait pas été mis à jour avec les dernières informations sur l’accessibilité de LaTeX, peut continuer à être lu par intérêt et pour des informations de contexte sur le balisage des PDF. *** ## Que couvre cet article ? L’objectif de cet article est de fournir une introduction au PDF balisé ainsi qu’un aperçu de certains défis techniques auxquels sont confrontés les logiciels, notamment les moteurs TeX et LaTeX, qui visent à produire des fichiers PDF balisés et accessibles. L’accessibilité, en particulier des PDF, est un sujet vaste et complexe, qui comporte aussi des défis techniques n’ayant pas toujours une solution unique, universellement admise ou acceptée — par exemple, comment représenter des mathématiques complexes dans des PDF de manière accessible : en utilisant MathML ou du code LaTeX ? Bien que nous ne puissions pas approfondir chaque sujet ni entrer dans tous les détails, nous pouvons examiner l’intérieur des PDF pour montrer ce que signifie réellement baliser un PDF. Overleaf espère que cet article servira d’introduction utile, en fournissant suffisamment de contexte pour permettre aux lecteurs de mieux comprendre les défis techniques et d’approfondir ensuite le PDF balisé et l’accessibilité. Les ressources de cet article incluent : * [une vidéo de 8 minutes](#video-showing-the-logical-structure-of-a-tagged-pdf) explorant un PDF balisé produit par LaTeX ; * [un projet Overleaf](#using-luatex-an-example-in-the-overleaf-gallery) pour explorer l’utilisation des caractères espace dans LuaTeX ; * [des enregistrements sonores](#tagged-yes-but-the-reading-order-is-incorrect) démontrant des problèmes d’accessibilité des PDF. ## Introduction Il est à juste titre reconnu que garantir l’accessibilité du contenu numérique est un aspect important de la production et de la diffusion de contenu. Par ailleurs, des gouvernements, notamment le [Royaume-Uni](https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps) et le [États-Unis](https://www.hhs.gov/sites/default/files/Intro%20to%20Accessibility%20and%20508.pdf), adoptent des lois qui exigent que le contenu produit sous leur juridiction respecte des critères d’accessibilité définis. La mise en conformité par la diffusion de contenu en HTML n’est pas excessivement contraignante, mais garantir le niveau d’accessibilité requis pour des documents distribués au format PDF peut constituer un défi technique important — selon le logiciel utilisé pour créer le contenu destiné à être exporté en fichier PDF. Le PDF est apparu au début des années 1990 comme une solution aux problèmes liés au transfert fiable de documents, et l’histoire a montré qu’il a connu un succès retentissant. Cependant, le PDF est aussi un format de fichier complexe apparu avant que le besoin de faciliter l’accessibilité du contenu des documents soit largement reconnu et accepté. Néanmoins, au fil du temps, la spécification PDF a évolué pour offrir des fonctionnalités qui permettent et soutiennent la production de documents PDF accessibles à l’aide d’une version « stylisée » du PDF qu’Adobe appelle *PDF balisé*. En pratique, la production de PDF balisés —*et pleinement accessibles*— impose aux logiciels qui produisent des PDF d’importantes exigences techniques supplémentaires, et cela inclut les moteurs TeX ainsi que l’écosystème LaTeX de macros et de paquets LaTeX complémentaires. ## Genèse du PDF comme papier numérique final Le [la genèse du format Portable Document Format (PDF)](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) remonte à une époque où le transfert de documents entre ordinateurs était semé d’embûches, souvent à cause de conversions de fichiers entraînant des réagencements de pages et d’autres écarts, aggravés par l’incompatibilité des polices et des codages de texte utilisés sur différents systèmes d’exploitation (notamment Windows et Macintosh). L’auteur de ce document travaillait alors dans l’édition et garde un souvenir très vif de ces difficultés ! Le PDF a été conçu pour résoudre les problèmes de partage de fichiers en introduisant un papier numérique universel, final (non modifiable), permettant le transfert fluide de documents autonomes qui intégraient les polices nécessaires à leur affichage. Les utilisateurs pouvaient enfin transférer toutes sortes de documents avec une certitude raisonnable que les destinataires, quel que soit leur système informatique, pourraient les ouvrir et les lire — l’intégrité du document était préservée et les réagencements de pages compliqués ainsi que la compatibilité/disponibilité des polices appartenaient au passé. ### Papier numérique : bon pour tous les utilisateurs ? L’ascendance du PDF, en tant que forme de papier numérique, supposait naturellement l’utilisation des numéros de page imprimés, de la typographie ou d’éléments de design comme repères de navigation visuelle de son contenu — à l’écran ou sur papier. Cependant, ces repères/mécanismes visuels sont, bien sûr, dénués de sens pour les personnes souffrant d’une déficience visuelle sévère. Aujourd’hui, l’amélioration de l’accessibilité du contenu numérique est à juste titre reconnue comme un aspect important de la production et de la diffusion de contenu. Le défi du PDF a été de fournir des mécanismes facilitant l’accès non visuel au contenu enfermé dans un « conteneur » conçu à l’origine pour reproduire le support visuel de la page imprimée. La première version de la spécification PDF (PDF 1.0) a été [publiée officiellement le 15 juin 1993](https://theblog.adobe.com/evolution-digital-document-celebrating-adobe-acrobats-25th-anniversary/) suivie de nouvelles versions comportant des mises à jour qui, en 2001 (PDF 1.4), ont inclus l’introduction du « PDF balisé », qui [« ... permettait aux utilisateurs de technologies d’assistance »](https://www.adobe.com/accessibility/pdf.html). Les versions suivantes de la spécification PDF ont étendu et amélioré les fonctionnalités du PDF, aboutissant à la dernière version (PDF 2.0) qui, d’après [des rapports](https://www.pdfa.org/tagged-pdf-2-0/), a profondément remanié les fonctionnalités d’accessibilité — bien que PDF 2.0 ne soit pas encore bien pris en charge par les moteurs TeX. ## Contenu à l’intérieur des PDF Pour bien comprendre les enjeux, il vaut la peine d’examiner comment les fichiers PDF représentent réellement le contenu des pages qu’ils contiennent. Au plus profond d’un fichier PDF, le contenu de chaque page réside dans le *flux de contenu*: une suite d’opérateurs PDF (« commandes ») qui placent du texte ou des graphiques à un emplacement particulier de la page pour leur rendu (affichage) par le logiciel utilisé pour *visualiser* le PDF. En pratique, le flux de contenu fournit une description graphique ou une « recette » qui indique aux applications de lecture de PDF comment « dessiner » chaque page — en définissant ce qui doit être affiché sur la page et à quel endroit. Naturellement, cette série d’opérateurs comprend des instructions pour choisir des polices particulières à une taille précise, sélectionner des couleurs, définir des largeurs de ligne, tracer des lignes, des courbes, etc. — tout ce qui est nécessaire pour fournir une description graphique complète pour la présentation visuelle d’une page. Pour réduire la taille du fichier, les flux de contenu PDF sont compressés et stockés dans un format binaire compact, mais si vous avez accès à un logiciel approprié, tel qu’Adobe Acrobat Pro DC, vous pouvez l’utiliser pour afficher une version texte brut « décompressée » des flux de contenu des pages. Voyons comment les opérateurs PDF pourraient « dessiner » un tableau : le flux de contenu PDF contiendrait une séquence appropriée d’opérateurs pour produire des lignes horizontales/verticales, sélectionner différentes polices et afficher du texte placé à divers emplacements de la page afin de produire le contenu du tableau. Pour le démontrer, examinons un document PDF simple non balisé ne contenant rien d’autre qu’un tableau de base avec du texte — créé dans Microsoft Word pour des raisons qui apparaîtront plus loin dans l’article. Voici une capture d’écran affichant notre PDF simple : ![Un tableau créé dans Microsoft Word](/files/0cc9cf3f0ad7e88dffeab777c179fc8a7ac3d69f) Si nous extrayons le flux de contenu de page (décompressé) de ce fichier et collons les premières lignes dans un éditeur de texte, nous pouvons résumer certains des opérateurs PDF afin de donner un aperçu de la manière dont les fichiers PDF « décrivent » le contenu affiché sur cette page. ![Image du flux de contenu dans un fichier PDF](/files/6cbaf7f1c13daa1f2f23ffc8c95700c8ba92915b) Si vous avez accès à Adobe Acrobat Pro DC, vous pouvez l’utiliser pour lister les opérateurs contenus dans le flux de contenu d’une page PDF. Voici la vue *Structure interne du PDF* d’Acrobat sur le même PDF, qui fournit utilement une description en une ligne de chaque opérateur utilisé pour « dessiner » notre page unique contenant un tableau de base — notez que ces courtes descriptions sont fournies par Adobe Acrobat Pro DC, elles ne sont pas *ne* présentes dans le fichier PDF lui-même : ![Image d’un flux de contenu PDF affiché dans Adobe Acrobat Pro DC](/files/a19eabb3fb44eb432a50440f06a730f23b3b51e3) Cependant, remarquez qu’aucune de ces instructions de dessin (opérateurs) ne stocke de « signification » ni de « description » de ce qu’elles produisent réellement : ce ne sont qu’un ensemble d’opérateurs graphiques qui aboutissent à la construction de ce qu’un *observateur voyant reconnaît* comme un tableau. Manifestement, pour les personnes souffrant d’une déficience visuelle sévère, afficher le tableau résultant de ces opérateurs graphiques dans le flux de contenu du PDF n’est pas une méthode viable pour accéder à ce contenu. Ce qu’il faut, c’est un mécanisme permettant aux fichiers PDF de contenir une description non visuelle appropriée (lisible par machine) de ce tableau — et, bien sûr, de tous les autres éléments de contenu contenus dans les pages d’un fichier PDF. Pour permettre un accès non visuel au contenu, les fichiers PDF doivent contenir des données supplémentaires qui attribuent une « signification » ou une sémantique à des collections ou groupes d’opérateurs utilisés pour « dessiner » un contenu particulier. Nécessairement, ce principe d’attribution ou de fourniture d’une « signification » doit s’étendre à toutes les formes de contenu contenues dans un PDF : ce mécanisme existe et s’appelle *le balisage* du PDF pour produire une « variante » du PDF appelée, sans surprise, *PDF balisé*. ## Présentation du PDF balisé Le PDF balisé est le nom donné à un type spécifique de fichier PDF qui contient des données supplémentaires (et des structures de données) absentes des fichiers PDF non balisés. Bien que les principes/idées derrière le PDF balisé puissent être décrits de façon générale, les détails complets sont complexes et occupent de nombreuses pages dans la spécification PDF officielle. Adobe a conçu le PDF balisé pour atteindre un certain nombre d’objectifs, notamment rendre le contenu accessible aux utilisateurs ayant une déficience visuelle, mais cela comprend aussi la liste suivante tirée de la section 10.7 de [la spécification PDF 1.7 d’Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf): * l’extraction simple du texte et des graphiques pour les coller dans d’autres applications ; * le réagencement automatique du texte et des graphiques associés pour s’adapter à une page d’une taille différente de celle supposée pour la mise en page d’origine ; * le traitement du texte à des fins de recherche, d’indexation et de vérification orthographique ; * la conversion vers d’autres formats de fichiers courants (tels que HTML, XML et RTF) en conservant la structure du document et les informations de style de base. En outre, le PDF balisé exige aussi : * que le texte du contenu PDF soit représenté dans une forme pouvant être convertie en Unicode ; * que les coupures de mots soient représentées explicitement — notez que les moteurs TeX n’utilisent pas des caractères espace pour séparer les mots, ils utilisent l’espacement flexible de TeX appelé glue (voir ci-dessous) ; * que le contenu réel (« véritable ») soit distingué des artefacts de mise en page et de pagination. Le PDF balisé repose sur deux concepts clés que nous allons examiner : * la définition de la structure logique du contenu dans un fichier PDF ; * le balisage du contenu PDF à l’aide d’un ensemble de types de contenu standard. ## Structure logique Dans les documents plus longs, le contenu est généralement réparti en une séquence de petits éléments de contenu ; par exemple, les livres sont généralement divisés en chapitres eux-mêmes divisés en sections et sous-sections contenant des paragraphes, des tableaux, des figures/graphes, des listes à puces ou numérotées, des notes de bas de page et des références, etc. La structure et l’organisation du contenu d’un tel livre, ou de tout autre type de document, sont appelées sa *structure logique*. La notion de structure logique d’un document joue un rôle important dans l’accessibilité des PDF mais, en tant que concept, elle peut sembler un peu vague et délicate à comprendre. La définition suivante de l’ [Encyclopedia of Database Systems](https://link.springer.com/referenceworkentry/10.1007%2F978-0-387-39940-9_213) apporte un éclairage utile : > « La structure logique désigne la façon dont les informations d’un document sont organisées ; elle définit la hiérarchie des informations et la relation entre les différentes parties du document. La structure logique indique comment un document est construit, par opposition à ce que contient un document. » Notez que cette définition de la structure logique ne fait pas référence précisément à *comment* l’endroit où ces informations structurelles sont stockées physiquement ; elle indique seulement qu’elle fournit une représentation de la structure et de l’organisation d’un document. Les détails précis de la manière dont la structure logique d’un document est stockée ou représentée dépendent de l’implémentation : une fonction du logiciel utilisé pour la générer et la traiter. ### Structure logique dans les PDF La spécification PDF fournit des mécanismes grâce auxquels la structure logique d’un document peut être enregistrée dans un fichier PDF — pour être utilisée par des logiciels qui, par exemple, souhaiteraient exporter le contenu du PDF vers d’autres formats tels que XML, HTML ou Microsoft Word. Ces processus d’export doivent produire un document texte correctement structuré, conforme aux règles du format de fichier cible — ce qui peut être réalisé au mieux lorsque le traitement d’export est guidé par les informations de structure logique fournies dans le PDF. En outre, la structure logique d’un fichier PDF est essentielle pour les logiciels d’accessibilité qui, par exemple, souhaiteraient effectuer des opérations de synthèse vocale et lire le contenu à voix haute à une personne ayant une déficience visuelle. Le processus de synthèse vocale doit garantir que le contenu est lu à voix haute dans le bon ordre/séquence, sinon il produirait des résultats absurdes. Notez aussi que la notion même de page peut ne présenter aucun sens pertinent pour des applications d’accessibilité qui ne s’intéressent qu’au contenu et à la structure du document PDF, et non à sa partition visuelle et à sa présentation en blocs de taille page. #### Nommer les éléments de contenu Enregistrer (stocker) la structure logique d’un document PDF nécessite un ensemble de noms significatifs attribués aux différents *types* d’éléments de contenu susceptibles de se trouver dans un document PDF typique — identifiant les sections de contenu qui représentent des titres, des paragraphes, des tableaux, des listes, etc. En outre, certains éléments de contenu comme les tables des matières, les listes numérotées/à puces et les tableaux ont leurs propres structures assez complexes, de sorte qu’il faut aussi des indications/règles pour préciser comment ces éléments de contenu plus complexes sont construits — leur sous-structure. Une autre exigence est d’identifier clairement tout contenu PDF qui doit être ignoré par les logiciels d’assistance traitant le PDF ; par exemple, les en-têtes et pieds de page sont des artefacts de pagination contenant du texte superflu pour les personnes ayant une déficience visuelle sévère : ce contenu devrait être ignoré. Les mécanismes utilisés par le PDF pour définir la structure logique d’un document sont conçus pour être flexibles, de sorte qu’en principe, différentes applications qui génèrent et traitent des fichiers PDF pourraient utiliser des noms pour les types de contenu selon la convention de leur choix. Toutefois, afin de maximiser l’interchangeabilité des documents et de permettre à différentes applications de traitement de PDF de fournir des résultats cohérents, Adobe a défini un ensemble de noms standard pour les types d’éléments de contenu que les logiciels de génération de PDF devraient respecter. Dans la spécification PDF, ces noms standard sont appelés des balises, d’où la notion de *PDF* balisé. ### Balisage du contenu PDF : un coup d’œil « sous le capot » Pour rendre la discussion un peu moins abstraite, nous allons jeter un bref coup d’œil aux rouages internes des fichiers PDF balisés — bien que nous ne puissions pas couvrir tous les détails, car le PDF balisé est un sujet vaste et complexe. #### Séquences de contenu balisé : les blocs de construction du PDF balisé Au niveau le plus bas, le processus d’enregistrement de la signification du contenu contenu dans une page PDF (c’est-à-dire dans son flux de contenu) commence avec *des séquences de contenu balisé* qui sont utilisées pour identifier (donner une « signification » à) des grappes ou groupes d’opérateurs PDF. Les séquences de contenu balisé se voient attribuer un identifiant numérique appelé son `MCID` (*identifiant de contenu balisé*) qui est un entier allant de 0 à un certain maximum N sur chaque page. Ces `MCID` valeurs fournissent un moyen d’identifier de manière unique des séquences d’opérateurs contenues dans le flux de contenu d’une page particulière. Pour clarifier, pour chaque page les `MCID` identifiants commencent à 0 et augmentent séquentiellement jusqu’à une certaine valeur maximale, qui dépend du nombre de séquences de contenu balisé contenues dans le flux de contenu d’une page particulière. Les séquences de contenu balisé sont, en pratique, des « blocs de construction » fondamentaux utilisés pour assembler des structures de données de plus haut niveau appelées *éléments de structure*. Ces éléments de structure contiennent une balise, qui est le nom utilisé pour identifier le type d’élément de contenu qu’ils représentent. #### Exemple d’éléments de structure Nous faisons ici un léger saut en avant, mais cela vaut la peine d’examiner un exemple. Supposons que vous ayez 3 petits fragments de texte du contenu d’une page, et que chacun soit identifié dans le flux de contenu par une séquence de contenu balisé différente. Chacun de ces 3 fragments de texte peut être empaqueté dans son propre élément de structure, avec une balise, et les trois peuvent être « reliés » à l’aide d’un autre élément de structure pour représenter un élément de contenu de niveau supérieur, tel qu’une ligne dans une table des matières. ![Image expliquant les éléments de structure et les séquences de contenu balisé](/files/53fe872d9ea622fa8a49de5596eefe8c8624f184) Grâce à une forme de relation de données parent-enfant, des collections d’éléments de structure sont combinées pour créer des structures de données liées qui représentent des éléments de données plus complexes comme des listes numérotées et à puces, des tableaux, des mathématiques, etc. En fin de compte, l’ensemble de la collection d’éléments de structure contenue dans tout le fichier PDF est ensuite relié et combiné pour créer la structure logique du document PDF — nous y reviendrons plus loin dans l’article. ### Qu’est-ce qu’une séquence de contenu balisé ? Dans la discussion ci-dessus, nous avons utilisé un document PDF simple non balisé contenant un tableau (créé dans Microsoft Word), mais si nous demandons à Word de créer un PDF balisé, nous pouvons voir qu’un balisage supplémentaire est apparu dans le flux de contenu de la page. Ici, nous ne considérons que les premières lignes du flux de contenu (il y en a des centaines), mais notez la présence d’opérateurs supplémentaires tels que `/P <> BDC` et `EMC` qui sont utilisés pour identifier une séquence de contenu balisé. Nous n’explorerons pas la syntaxe complète des séquences de contenu balisé, mais nous renvoyons le lecteur à la page 862 de [la spécification PDF 1.7 officielle d’Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf). ![Image montrant des séquences de contenu balisé dans un flux de contenu PDF balisé](/files/0c1629ceef51c45c43f78021c10d8dc705fe17dc) Pour faciliter la consultation, nous montrons à nouveau la version non balisée : ![Image montrant un flux de contenu PDF](/files/6cbaf7f1c13daa1f2f23ffc8c95700c8ba92915b) Dans l' *non balisé* PDF, des opérateurs tels que `/P <> BDC` et `EMC` sont absents mais les opérateurs restants sont inchangés : le PDF non balisé ne comporte pas le balisage supplémentaire utilisé pour identifier certaines séquences/collections d’opérateurs. Là encore, nous pouvons également utiliser la fonctionnalité d’Adobe Acrobat *Structure interne du PDF* pour afficher les séquences de contenu balisé dans un flux de contenu — ici, nous les avons mises en évidence à l’aide d’une bordure verte : ![Image montrant des séquences de contenu balisé dans un flux de contenu PDF balisé affiché dans Adobe Acrobat Pro DC](/files/dc0c7f11ef710408652f5e25324b01b831899c25) Notez que certains éléments de contenu sont marqués `/Artifact` ce qui identifie le matériel sur la page PDF qui devrait être *ignorés* ignoré par les applications logicielles d’assistance, telles que celles qui lisent à haute voix pour les personnes malvoyantes. La capture d’écran suivante montre une vue développée de la première séquence de contenu balisé — celle avec `MCID` une valeur de `0`. La fin de la séquence de contenu balisé est identifiée par l’opérateur PDF `EMC`. ![Image montrant les détails des opérateurs compris dans un flux de contenu balisé](/files/42572e12fc9527cb3c4a76ce36727540a9b5459e) ### Stocker la structure logique Comme indiqué, en plus de fournir une description des éléments de contenu individuels (paragraphes, listes, tableaux, etc.), il est nécessaire pour les PDF accessibles de contenir une représentation de l’ensemble du document sous la forme de sa structure logique. Les éléments de contenu individuels doivent être reliés entre eux pour créer un document complet, navigable et accessible — un peu comme un document HTML unique est construit à partir de paragraphes, de graphiques, de tableaux pour créer une page web. De plus, il est essentiel que la structure logique d’un document PDF garantisse que tout le contenu puisse être parcouru dans le bon *ordre de lecture*, indépendamment de l’ordre dans lequel le contenu de la page a été écrit dans les flux de contenu de la page PDF. Nous examinerons plus en détail l’ordre de lecture ci-dessous. #### Structure logique : un « arbre » d’éléments de structure Nous avons noté que les PDF utilisent quelque chose appelé un *élément de structure* pour représenter des éléments de contenu individuels, et qu’un élément de structure contient une balise pour identifier le type de contenu qu’il représente. Pour fournir une représentation de la structure logique du document, tous les éléments de structure sont reliés entre eux, à l’aide de relations parent-enfant, et organisés en un « arbre de structure ». En interne, les fichiers PDF balisés contiennent un objet appelé `StructTreeRoot` qui contient (pointe vers) des éléments de structure qui servent de point de départ ou de « racine » de l’arbre de structure logique du document. En général, la « racine » de l’arbre de structure commence par un seul élément de structure balisé `Document` qui contient de nombreux *enfants* éléments de structure qui, ensemble, représentent l’intégralité du contenu du document. Tout logiciel conçu pour produire des PDF accessibles par balisage doit construire cette structure de données très complexe (et d’autres encore !) — et cela inclut les moteurs TeX et LaTeX. Un exemple d’un tel arbre de structure de document (`StructTreeRoot`) est montré dans la capture d’écran suivante d’un PDF balisé ouvert dans Adobe Acrobat Pro DC : ![Image montrant le StructTreeRoot dans un PDF balisé](/files/cc5b2ef4917f141eb9f061aca35399b5cce1b1f3) Comparez la structure ci-dessus à la version PDF non balisée : ![Image montrant l’absence de StructTreeRoot dans un PDF non balisé](/files/0a31dd1bb86cb8648f4e361432ccecf26e1c2d2b) ### Explorer la structure logique des PDF Nous commençons par quelques graphiques pour résumer ce que nous avons couvert, puis nous concluons avec une vidéo qui utilise Adobe Acrobat Pro DC pour montrer plus en détail la structure logique d’un fichier PDF balisé. D’abord, nous commençons par un schéma illustrant les principes généraux : une page PDF avec son flux de contenu balisé par des séquences de contenu balisé (MCS). ![Graphique illustrant le concept de séquences de contenu balisé dans les pages d’un document PDF](/files/f7eeb591b2cff60b8c02cc58892c6bc142e5d92e) Ces MCS sont ensuite combinées en *éléments de structure* qui constituent la base de types de contenu plus vastes qui sont eux-mêmes reliés entre eux pour stocker la structure logique du PDF dans un objet appelé `StructTreeRoot`. ![Graphique illustrant la structure logique d’un fichier PDF balisé](/files/4c44108c3924e73876ba9df72476cdc1025cf3c4) #### Vidéo montrant la structure logique d’un PDF balisé La vidéo suivante (8 minutes) utilise Adobe Acrobat Pro DC pour vous proposer une « visite guidée » permettant d’explorer les détails de la structure logique d’un fichier PDF balisé produit avec LaTeX. Le fichier PDF balisé utilisé dans la vidéo s’appelle `tagpdf.pdf`, qui est un excellent exemple contenant la documentation du paquet LaTeX expérimental [`tagpdf`](https://ctan.org/pkg/tagpdf?lang=en). L’objectif du `tagpdf` paquet {% embed url="" %} ### Remarque sur le balisage et la flexibilité La spécification HTML fournit un grand nombre de balises prédéfinies destinées à être utilisées pour construire des pages web, mais elle autorise aussi une certaine flexibilité dans la manière dont vous les combinez pour créer le document HTML souhaité. De même, la spécification PDF balisé d’Adobe fournit un ensemble de noms de balises prédéfinis, mais impose très peu de restrictions sur la façon dont vous combinez ces balises pour représenter des éléments de contenu complexes dans un PDF — par conception, elle offre une grande flexibilité. En outre, avec toute spécification aussi vaste et complexe que le PDF, il est inévitable que certaines ambiguïtés ou problèmes de clarté se glissent dans la spécification écrite. Les développeurs de logiciels chargés d’implémenter une spécification aussi complexe peuvent devoir prendre des « décisions d’interprétation » lorsqu’ils la traduisent en code fonctionnel, car ils doivent convertir des descriptions écrites en code opérationnel. La flexibilité inhérente du PDF balisé, combinée à l’interprétation des spécifications (ou des normes d’accessibilité), a naturellement un impact sur les développeurs d’applications de création de documents : quelles combinaisons de balises faut-il utiliser pour représenter le contenu créé par l’utilisateur lors de l’export vers un fichier PDF balisé ? Si l’on ajoute à cela la capacité illimitée des utilisateurs à créer toutes sortes de contenus en exploitant les fonctionnalités du logiciel de création, on comprend que la production automatisée de PDF balisés accessibles est un véritable défi ! Peut-être en raison des complexités inévitables liées à la production de PDF balisés conformes aux normes d’accessibilité, le web regorge de « mode d’emploi », de « conseils » et de recommandations de « bonnes pratiques » sur la création de PDF balisés via des logiciels tels qu’Adobe InDesign ou Microsoft Word. En outre, la PDF Association a produit un document utile intitulé [Guide des bonnes pratiques pour le PDF balisé](https://www.pdfa.org/wp-content/uploads/2015/12/StructureElementsBestPracticeGuide_2016-01-19.pdf) rédigé pour aider les développeurs confrontés aux défis de l’implémentation du PDF balisé et du PDF/UA. ## Vous avez un PDF, mais est-il accessible ? Pour déterminer si un fichier PDF donné respecte les normes d’accessibilité requises, telles que PDF/A ou PDF/UA (voir ci-dessous), il doit être *validé* à l’aide d’un processus de validation ou d’un outil logiciel convenu. Cependant, la validation a généralement lieu une fois le document terminé, mais ce processus peut ne pas être réalisé par l’auteur du document, mais par des spécialistes de l’accessibilité au sein de l’organisation ou de l’entité ayant exigé la conformité. Si le PDF échoue à la validation, une intervention manuelle qualifiée via Adobe Acrobat Pro DC peut être nécessaire pour corriger le balisage (si possible). Sinon, il peut même falloir renvoyer le document à l’auteur afin qu’il modifie son document original, éventuellement en évitant d’utiliser les fonctionnalités du logiciel de création qui ont causé les problèmes — ce qui peut s’avérer extrêmement difficile à réaliser, car cela peut être hors du contrôle de l’auteur. ### Ordre de lecture et ordre du contenu Comme indiqué, la production de PDF réellement accessibles impose des exigences techniques supplémentaires au logiciel de création et, potentiellement, aux auteurs de documents également, en imposant une « discipline d’auteur » dans la manière dont ils utilisent/appliquent les fonctionnalités du logiciel de création. Bien que le PDF balisé soit le mécanisme qui *permet* la production de PDF pleinement accessibles, le simple fait qu’un PDF soit balisé ne *ne* signifie pas automatiquement qu’il est pleinement accessible, comme nous le verrons dans un exemple ci-dessous. Pour produire des PDF pleinement accessibles, tous les éléments de contenu du PDF doivent être balisés afin de créer une structure logique qui garantit que le contenu peut être consulté et lu dans la bonne séquence — appelée l’ *ordre de lecture*ordre de lecture *ordre de lecture* de : 1. text 2. table 3. graphique Lorsqu’il est écrit dans un PDF, le logiciel générant un flux de contenu pour cette page pourrait commencer par des opérateurs pour dessiner le tableau, puis produire des opérateurs pour générer le graphique, suivis d’opérateurs pour le texte, ce qui, dans le flux de contenu, produirait un *ordre du contenu* de : 1. table 2. graphique 3. text Bien entendu, tout sera placé au bon endroit lorsque cette page sera affichée. Pour un lecteur voyant, l’ordre dans lequel ces éléments sont stockés à l’intérieur du flux de contenu de la page n’a aucun intérêt : il voit une page rendue complète avec tout au bon emplacement. Cependant, si un logiciel d’assistance devait se fier à l’ordre des éléments dans un flux de contenu (l’ordre du contenu), il rencontrerait des difficultés si l’ordre du contenu différait de l’ordre naturel de lecture ; par exemple, les outils de lecture à voix haute liraient le contenu dans le mauvais ordre. Heureusement, les logiciels d’assistance peuvent utiliser l’ordre logique (la structure) d’un PDF balisé, qui doit être organisé de manière à refléter la séquence dans laquelle le contenu doit être lu. C’est pour ces raisons que les données représentant la structure logique du document sont stockées séparément du contenu réel affiché sur les pages visibles, afin de permettre > « ... l’ordre et l’imbrication des éléments logiques de contenu d’être entièrement indépendants de l’ordre et de l’emplacement des objets graphiques sur les pages du document. » (page 856 de [The PDF Reference, sixième édition, novembre 2006](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf)) En pratique, garantir un ordre logique qui préserve l’ordre de lecture est bien plus difficile qu’il n’y paraît, alors utilisons un exemple simple, bien qu’inventé, qui donne une idée des problèmes en jeu. #### Ordre de lecture incorrect : un exemple utilisant Microsoft Word L’auteur d’un document peut utiliser les fonctionnalités du logiciel de création choisi pour obtenir un effet visuel précis — par exemple en utilisant des tableaux pour créer une mise en page de texte particulière. Par exemple, la capture d’écran suivante montre le document Microsoft Word utilisé dans les exemples précédents. Il contient un tableau qui a été utilisé pour créer un ensemble de paragraphes numérotés placés côte à côte. Mais lorsqu’il s’agit de baliser ce contenu, comment faut-il le traiter : comme un tableau ou comme une liste numérotée ? Ces deux types de contenu nécessitent une structure de balisage complexe pour être représentés correctement. Dans l’image suivante, notez l’ordre dans lequel les paragraphes numérotés sont censés être lus : colonne par colonne, et non ligne par ligne. ![Image d’un tableau créé dans Microsoft Word](/files/559bee1a1f1f12958028876847fb2f65b832366b) Si nous demandons à Word d’enregistrer ce document en PDF en utilisant son export intégré — et non le module complémentaire Acrobat PDFMaker — nous pouvons lui demander de créer un PDF balisé : ![Boîte de dialogue Options du processus d’exportation de Microsoft Word](/files/7f38636e04e461e4ce428bc4237c5141bee6bcce) Alors, comment Word balise-t-il cette mise en page ? Dans la très courte vidéo suivante (14 secondes), nous utilisons Adobe Acrobat Pro DC pour examiner la structure de balisage produite par Microsoft Word. {% embed url="" %} Pour ce document, Word a créé un document PDF balisé qui utilise un `Tableau` balise contenant deux sous-balises : `THead` pour le groupe de lignes d’en-tête du tableau et et `TBody` pour représenter le groupe de lignes du corps du tableau. `THead` et `TBody` contiennent tous deux `TR` des balises pour représenter les lignes individuelles de contenu. Les `TR` balises contiennent d’autres balises pour représenter l’élément de liste numérotée présent dans chaque cellule. L’image d’écran suivante montre la structure de balisage profondément imbriquée et la structure logique tout aussi complexe nécessaire pour représenter même ce document extrêmement basique ! ![Image montrant une structure de balisage profondément imbriquée et la structure logique d’un tableau simple créé dans Microsoft Word](/files/11d0d4de5fa681fda68ecefddcac7af90659a4a9) Comparé aux PDF générés par TeX et LaTeX, cet exemple de Word est un document extrêmement simple, mais il nécessite néanmoins une structure logique complexe pour le représenter. Imaginez le niveau de complexité du balisage nécessaire pour représenter des PDF générés par LaTeX contenant des mathématiques et des tableaux complexes ! #### Balise présente, oui, mais l’ordre de lecture est incorrect Même si Word produit bien un [PDF balisé](https://assets.ctfassets.net/nrgyaltdicpt/3vcgZmG5mkCPYUPTjV30CF/4c34ae919212fa19e979e4cf852e66c1/ReadAloud.pdf) cela illustre l’un des défis fondamentaux auxquels est confrontée toute application cherchant à produire des PDF pleinement accessibles : représenter correctement l’ordre de lecture prévu du contenu. Lors de la création du PDF balisé, les processus internes de Word ont décidé d’écrire le flux de contenu correspondant en affichant le tableau ligne par ligne, et non colonne par colonne. Pour un lecteur voyant consultando le PDF, ces détails de bas niveau ne font aucune différence : le tableau s’affiche correctement. Cependant, pour les personnes malvoyantes, la structure logique du document de Word produit un résultat incorrect, car l’ordre de lecture souhaité (colonne par colonne) n’est pas préservé : le contenu est lu à voix haute dans le mauvais ordre. L’enregistrement audio suivant a été produit à l’aide de la fonctionnalité « Read Out Loud » d’Adobe Reader DC. Comme on peut le constater, le texte est lu dans le mauvais ordre : ligne par ligne, et non colonne par colonne : ![Un tableau créé dans Microsoft Word](/files/2ca6445bc35f05f61f6cafda6286c1758e70aa2f) Comme indiqué ci-dessus, cet exemple est quelque peu artificiel, mais il montre à quel point il est facile d’appliquer des combinaisons de fonctionnalités logicielles qui déclenchent des problèmes d’accessibilité — mais comment l’auteur du document est-il censé le savoir à l’avance ? Il est probable que ce problème ne serait détecté que si le PDF résultant était soumis à des tests pratiques d’accessibilité — par exemple, à l’aide d’un logiciel d’assistance. Il est possible que de tels documents passent les tests de conformité/validation PDF/A mais échouent dans une utilisation « réelle ». Garantir le bon ordre de lecture d’un fichier PDF comme celui-ci nécessiterait une intervention manuelle qualifiée à l’aide d’outils avancés d’édition PDF tels qu’Adobe Acrobat Pro DC : un processus long et coûteux. Sinon, l’auteur du document pourrait s’abstenir d’utiliser cette forme particulière d’expression du contenu ou de mise en page — mais seulement s’il savait qu’elle posait problème ! ### Utilisation de caractères d’espace pour séparer les mots Lorsque vous saisissez du texte dans des traitements de texte ou des éditeurs de texte, vous utilisez le caractère espace pour marquer la fin d’un mot et le début du suivant. Si vous créez ensuite un PDF à partir d’un tel document, les caractères d’espace que vous avez saisis seront bien sûr produits et feront partie du texte stocké dans le PDF. Cependant, les moteurs TeX n’utilisent pas les caractères d’espace pour séparer les mots dans le texte composé ; à la place, ils convertissent les caractères d’espace en une forme d’espacement flexible appelée glue (voir ce [article Overleaf](/latex/fr/articles-approfondis/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md) pour plus d’informations sur les boîtes TeX et la glue). Dans le flux de contenu des pages PDF créées par les moteurs TeX, la séparation des mots individuels est obtenue en se déplaçant vers une autre position sur la page et en commençant le texte du mot suivant — plutôt qu’en produisant un caractère d’espace pour obtenir cet espacement. De plus, la quantité d’espace entre les mots dans les paragraphes de texte composés par les moteurs TeX varie d’une ligne à l’autre en raison de l’algorithme de césure de TeX. Cette variation se reflète dans les données de positionnement écrites dans le flux de contenu des pages PDF. Cet aspect de la composition de TeX a des implications pour le copier/coller de texte depuis ses PDF et pour les logiciels d’assistance qui tentent de lire à voix haute le texte composé dans les PDF produits par les moteurs TeX. Les logiciels d’assistance doivent analyser le flux de contenu d’une page PDF pour extraire le texte qu’ils doivent traiter. De toute évidence, de tels logiciels ont besoin d’un mécanisme pour détecter le début et la fin des mots — la solution la plus évidente étant d’utiliser un caractère espace. Dans cette optique, les normes d’accessibilité exigent que les mots individuels soient clairement délimités (par exemple, par des caractères espace), ce qui pose problème aux moteurs TeX en raison de leur utilisation de glue intermot. #### Mais tout n’est pas perdu ! En 2014, pdfTeX a introduit 2 nouvelles primitives pour améliorer la prise en charge de l’accessibilité en permettant l’utilisation de caractères espace entre les mots dans les PDF qu’il produit : * `\pdfinterwordspaceon` * `\pdfinterwordspaceoff` Ces commandes utilisent une « police factice » ne contenant qu’un glyphe espace. Des détails et un exemple se trouvent à la page 29 du [Manuel de l’utilisateur de pdfTeX](http://texdoc.net/texmf-dist/doc/pdftex/manual/pdftex-a.pdf). #### Utilisation de LuaTeX : un exemple dans la galerie Overleaf LuaTeX ne prend pas en charge ces primitives pdfTeX, mais il peut être programmé pour obtenir des résultats très similaires à ceux de pdfTeX en utilisant le mécanisme dit de callbacks de LuaTeX. Un projet Overleaf permettant de convertir la glue en caractères espace est disponible dans la galerie Overleaf sous le titre [Utilisation de LuaTeX pour convertir la glue intermot en espaces et en kerns](https://www.overleaf.com/latex/examples/using-luatex-to-convert-interword-glue-to-spaces-and-kerns/sfdkdkybrvkv). Si vous composez votre code LaTeX à l’aide de LuaTeX (c’est-à-dire l’option de compilateur LuaLaTeX sur Overleaf), alors, en utilisant du code Lua, vous pouvez post-traiter un paragraphe composé pour y trouver toute glue intermot et la remplacer par un caractère espace plus un kern approprié. L’espacement fourni par la largeur du caractère espace peut être ajouté à (ou réduit de) en calculant une valeur de kern appropriée afin de préserver la quantité d’espace fournie par la glue intermot, ce qui n’entraîne aucune différence visuelle dans le résultat composé. Pour comprendre la différence que cela fait pour les utilisateurs de logiciels d’accessibilité, écoutez cet enregistrement sonore capturé à partir de la fonctionnalité d’Adobe Reader DC *Read Out Loud* . Il enregistre les deux lignes de texte de ce projet lues à voix haute, avant et après la conversion de la glue en espaces. Remarquez comment la deuxième lecture de la ligne, qui utilise des espaces, est lue rapidement et fluidement par rapport à la ligne utilisant la glue intermot. Le projet Overleaf est un fichier TeX simple compilé avec LuaTeX et fourni uniquement à des fins expérimentales ; il n’est pas destiné à constituer une solution complète, de qualité production. Il est principalement conçu pour aider à comprendre les problèmes techniques liés aux PDF accessibles. Le code Lua utilisé dans ce projet est basé sur un travail contenu dans un article Overleaf bien plus ancien [Boîtes et colle : une introduction brève, mais visuelle, à l'aide de LuaTeX](/latex/fr/articles-approfondis/11-boxes-and-glue-a-brief-but-visual-introduction-using-luatex.md). Remarque : pour simplifier, le projet utilise son propre chargeur de police OpenType très minimal, dérivé de ce code : . ### Autres problèmes d’accessibilité et PDF balisé Bien que le balisage permette d’identifier les éléments de contenu présents dans un PDF, certains types de contenu, tels que les graphiques ou les mathématiques complexes, nécessitent des données ou des informations supplémentaires pour être rendus accessibles via un logiciel conçu pour aider les personnes malvoyantes. Afin de fournir et de prendre en charge l’accessibilité pour un large éventail de types de contenu, la spécification PDF offre la possibilité d’attacher des « descriptions alternatives » ou du « texte réel » aux éléments de contenu, en fournissant des descriptions textuelles appropriées ou d’autres représentations lisibles par machine. Par exemple, MathML a été désigné à cette fin dans la spécification PDF 2.0. #### S’agit-il de « vrai contenu » ou simplement d’un artefact ? Pour les personnes malvoyantes, le processus de partitionnement et d’affichage du contenu en blocs rectangulaires de taille page a des effets secondaires indésirables, comme la césure des mots. En outre, des aspects de la conception ou de la mise en page de la page utilisés pour améliorer la présentation visuelle n’ont guère de sens pour celles et ceux qui ne peuvent pas les voir. Pour ces raisons, le balisage du contenu PDF doit reconnaître qu’une partie du contenu d’un PDF doit être traitée comme un *artefact* de présentation visuelle ou de pagination. Par exemple, les numéros de page, les en-têtes et pieds de page, les arrière-plans colorés ou d’autres éléments de conception doivent être identifiés afin que le logiciel d’accessibilité traitant le contenu sache les ignorer. ## Aperçu des normes PDF/A Les demandes visant à produire des PDF accessibles font généralement référence à une norme ISO appelée [ISO 19005](https://www.iso.org/standard/38920.html) , plus couramment désignée sous le nom de PDF/A. Cependant, comme PDF/A est une *de la famille* famille de normes, demander simplement une « conformité PDF/A » peut ne pas spécifier complètement les exigences réelles. Pour comprendre pourquoi, commençons par un bref aperçu de PDF/A tiré du site Web de l’ [PDF Association](https://www.pdfa.org/resource/iso-19005-pdfa/) (consulté le 21 mai 2020), qui décrit ISO 19005 (PDF/A) comme suit : > « L’objectif principal d’ISO 19005 est de définir un format de fichier basé sur PDF, connu sous le nom de PDF/A, qui fournit un mécanisme pour représenter des documents électroniques d’une manière qui préserve leur apparence visuelle statique dans le temps, indépendamment des outils et systèmes utilisés pour créer, stocker ou restituer les fichiers. > > Un objectif secondaire d’ISO 19005 est de définir un cadre pour représenter la structure logique et d’autres informations sémantiques des documents électroniques dans des fichiers conformes. > > Un autre objectif d’ISO 19005 est de fournir un cadre pour enregistrer le contexte et l’historique des documents électroniques dans les métadonnées des fichiers conformes. » Clairement, PDF/A poursuit plusieurs objectifs fondamentaux. ### Évolution et croissance de PDF Le [La spécification PDF 1.0](https://web.archive.org/web/20150617123515/http://acroeng.adobe.com/PDFReference/PDF%20Reference%201.0.pdf) a été publiée en 1993 et ne contenait que 230 pages. Cependant, 13 ans plus tard, la spécification pour [la version 1.7 de PDF d’Adobe](https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdf_reference_archive/pdf_reference_1-7.pdf) dépasse largement 1000 pages ! Au fil du temps, la taille et la complexité de la spécification PDF ont augmenté en enrichissant l’ensemble des fonctionnalités prises en charge : englobant de nouvelles technologies et les exigences de flux de travail et de cas d’usage basés sur PDF, de plus en plus sophistiqués, dans différents marchés et communautés. Cependant, il est probable qu’aucun utilisateur, ni groupe d’utilisateurs, n’exploite jamais toutes les possibilités : PDF doit « couvrir tous les cas » pour s’assurer qu’il peut répondre aux besoins du plus large marché possible. Par exemple, de nombreuses fonctionnalités PDF conçues pour prendre en charge l’impression commerciale haut de gamme ne sont pas nécessaires à l’utilisation quotidienne typique en bureau comme format de stockage ou de partage de documentation. ### PDF/A : un retour aux fondamentaux du PDF L’objectif principal de PDF/A est de garantir que les PDF conformes sont adaptés à l’archivage à long terme ou contiennent un contenu accessible aux personnes utilisant diverses technologies d’assistance pour « consommer » ces PDF. Pour atteindre ces objectifs, PDF/A restreint l’ensemble des fonctionnalités PDF autorisées dans les fichiers PDF conformes, en interdisant l’utilisation de fonctionnalités qui pourraient compromettre l’archivabilité ou l’accessibilité. On peut considérer PDF/A comme un ensemble de normes qui spécifient comment les fichiers PDF conformes utilisent un *sous-ensemble* sous-ensemble de la spécification PDF complète afin de produire des fichiers adaptés à l’archivage à long terme ou garantissant que leur contenu est accessible. Les restrictions de PDF/A permettent d’utiliser les PDF comme un « papier numérique d’archivage » indépendant de la technologie de lecture PDF et de l’environnement informatique utilisés pour accéder à leur contenu. Les PDF conformes ne doivent contenir rien dont le comportement soit « dépendant de l’implémentation » — c’est-à-dire dépendant du logiciel ou des systèmes d’exploitation spécifiques utilisés pour les afficher ou les traiter. Les PDF doivent également être *complets* : les ressources documentaires clés doivent être incorporées dans le fichier — telles que les polices ou les profils colorimétriques. ### Versions de PDF/A et niveaux de conformité Il existe différentes *les versions* versions de la norme PDF/A, chacune reflétant une version particulière de la spécification PDF formelle (PDF 1.4, 1.7 et 2.0). En outre, il existe divers *niveaux de conformité* qui précisent à quel(s) aspect(s) de la norme PDF/A un fichier PDF se conforme. Par conséquent, lorsque vous affirmez ou exigez une « conformité PDF/A », vous devez penser à des fichiers PDF conformes à **PDF/A-** Par exemple * PDF/A-1a : signifie PDF/A version 1, niveau de conformité a * PDF/A-2b : signifie PDF/A version 2, niveau de conformité b Nous les examinons un peu plus en détail. #### Versions de PDF/A La norme PDF/A est placée sous l’égide de l’ISO, publiée comme une norme appelée ISO 19005. Comme indiqué, la spécification PDF a évolué au fil du temps et cela a, à son tour, nécessité des mises à jour d’ISO 19005, ce qui a abouti au tableau ci-dessous : | | | | | ----------------- | ---------------- | --------------------------- | | **Version PDF/A** | **Norme ISO** | **Basé sur la version PDF** | | PDF/A-1 | ISO 19005-1:2005 | PDF 1.4 | | PDF/A-2 | ISO 19005-2:2011 | PDF 1.7 | | PDF/A-3 | ISO 19005-3:2012 | IS0 32000-1 (PDF 1.7) | Au moment de la rédaction (avril/mai 2020), un PDF/A-4 mis à jour (ISO 19005-4) est [en préparation](https://www.iso.org/standard/71832.html). #### Niveaux de conformité PDF/A En plus de trois versions de PDF/A (PDF/A-1, PDF/A-2 et PDF/A-3), il existe trois *niveaux de conformité*: * Niveau A (accessible) pour l’accessibilité (inclut les exigences d’archivage du niveau B) * Niveau B (de base) pour l’archivage * Niveau U (Unicode) (= archivage plus utilisation d’Unicode pour le texte) Voici une brève description de ces niveaux de conformité : * **Niveau B (de base)** constitue l’exigence minimale de conformité au regard de PDF/A. Il définit les exigences visant à garantir que les documents PDF conformes sont adaptés à l’archivage à long terme — qu’ils puissent toujours être consultés ou imprimés de manière fiable, indépendamment de logiciels, d’outils ou de systèmes d’exploitation spécifiques. * **Niveau A (accessibilité)** inclut les exigences de conformité du niveau B, mais exige en outre l’utilisation de PDF balisé pour fournir une structure logique et des informations sur l’ordre de lecture, ainsi que l’utilisation d’Unicode pour permettre l’accès au texte du document. * **Niveau U (Unicode)** la conformité était un niveau ajouté à PDF/A-2 et s’appuie sur le niveau B en exigeant en plus l’utilisation d’Unicode pour le texte du document, mais n’allez pas aussi loin que le niveau A en imposant des informations de structure. Les versions de PDF/A et les niveaux de conformité peuvent être résumés dans un tableau : | | | | | | ------------------------ | --------------------------------- | -------- | -------- | | **Niveau de conformité** | **PDF/A-** | | | | Niveau A (accessible) | PDF/A-1a | PDF/A-2a | PDF/A-3a | | Niveau B (de base) | PDF/A-1b | PDF/A-2b | PDF/A-3b | | Niveau U (Unicode) | S/O (n’existait pas pour PDF/A-1) | PDF/A-2u | PDF/A-3u | ### PDF/UA (« Universal Accessibility ») Bien que la conformité de niveau A de la norme PDF/A aille dans une certaine mesure dans la définition des exigences pour les PDF accessibles, une autre norme ISO appelée [ISO 14289](https://www.iso.org/standard/64599.html), appelée PDF/UA, va plus loin. PDF/UA renforce les exigences d’accessibilité et clarifie les recommandations contenues dans les normes PDF/A et est devenue la norme privilégiée pour les PDF accessibles. #### Protocole Matterhorn Les lecteurs profondément intéressés par la conformité PDF/UA voudront peut-être consulter le [Protocole Matterhorn](https://www.pdfa.org/resource/the-matterhorn-protocol-1-02/) qui est « une liste de toutes les façons possibles d’échouer à la conformité PDF/UA ». ### Logiciel de validation Pour vérifier si un fichier PDF est conforme à une norme particulière, il doit être *validé* à l’aide d’un logiciel de conformité qui analyse le PDF pour vérifier si son contenu et sa structure sont conformes aux exigences de cette norme — comme PDF/UA ou PDF/A-*x*a (où *x* = 1, 2 ou 3). Notez que la validation des PDF — leur traitement à l’aide d’un outil de validation préféré — peut produire des messages de diagnostic ou des avertissements qui peuvent être assez obscurs pour l’utilisateur non expert — peut-être en raison de certaines données PDF de bas niveau (ou de structure) qui ne respectent pas la norme pertinente. Pour de nombreux auteurs, interpréter ces avertissements et les transformer en correctifs exploitables pour leur(s) document(s) peut être un véritable défi. #### Logiciel de validation gratuit * [veraPDF](https://verapdf.org/) qui, selon leur site Web (consulté le 28 mai 2020), est un « validateur de format de fichier open source spécialement conçu couvrant toutes les parties et tous les niveaux de conformité de PDF/A ». * (Windows uniquement) [PDF Accessibility Checker (PAC 2024)](https://pac.pdf-accessibility.org/en/download) qui est un « ...outil gratuit de vérification de l’accessibilité des PDF qui a été essayé et testé depuis 2010 ». #### Logiciel de validation commercial * [Adobe Acrobat](https://acrobat.adobe.com/uk/en/acrobat/pricing.html) propose une suite de tests de validation PDF ainsi que des outils pour modifier et corriger les balises dans les fichiers PDF non conformes. ### PDF Association : une excellente source d’informations Le [PDF Association](https://www.pdfa.org/) produit de nombreuses *excellente* ressources sur PDF/A, PDF/UA et bien d’autres sujets liés aux PDF — y compris des vidéos sur leur [chaîne YouTube](https://www.youtube.com/user/ThePDFAssociation/playlists) ainsi que des articles et des publications techniques gratuites disponibles sur leur site Web. L’une de ces publications est [PDF/UA en un mot](https://www.pdfa.org/resource/pdfua-in-a-nutshell/) qui fournit une introduction précieuse à la norme PDF/UA et à ses exigences. ## PDF accessibles à partir des moteurs TeX et de LaTeX Espérons que les discussions précédentes ont montré que la production de fichiers PDF entièrement accessibles et correctement balisés constitue un défi technique exigeant. De plus, même le simple exemple de Microsoft Word a montré que les auteurs peuvent très facilement utiliser des combinaisons de fonctionnalités logicielles qui entraînent des documents PDF balisés ne satisfaisant pas les critères d’accessibilité. En tant qu’outil de rédaction, LaTeX offre aux auteurs une flexibilité quasi illimitée quant à la gamme et à la complexité des documents que vous pouvez créer — ce qui peut être précisément la raison de l’avoir choisi au départ. LaTeX prend également en charge l’extensibilité via des milliers de paquets additionnels que les auteurs peuvent utiliser dans leurs documents. En plus de tout cela, les auteurs ont la liberté d’écrire de nouvelles macros TeX ou LaTeX, ou de redéfinir celles existantes, afin d’obtenir des effets spécifiques. Cependant, peut-être cette liberté et cette flexibilité ont-elles un prix, car le contenu produit par les myriades d’interactions de tous ces paquets et macros LaTeX doit « d’une manière ou d’une autre » être orchestré si LaTeX doit générer automatiquement un PDF correctement balisé et accessible. En pratique, l’extensibilité, la puissance, la polyvalence et la « liberté » de rédaction conférées par LaTeX posent des défis techniques à la production fluide et transparente (« automatique ») de documents PDF balisés pleinement accessibles conformes aux normes PDF/UA ou PDF/A-{1|2|3}a. La communauté TeX et LaTeX au sens large s’efforce de relever ces défis et le TeX User Group (TUG) coordonne les efforts de recherche et développement par l’intermédiaire du groupe de travail PDF accessibility and PDF standards [groupe de travail](https://www.tug.org/twg/accessibility/). Il existe une [liste de discussion](https://tug.org/mailman/listinfo/accessibility) qui offre un moyen aux parties intéressées de discuter de la production de fichiers PDF balisés à l’aide de TeX et de LaTeX. Dans ces discussions, il convient de se rappeler que LaTeX n’est pas en réalité un programme de composition exécutable ; c’est une vaste collection de macros sophistiquées (commandes) écrites dans un langage de plus bas niveau appelé TeX. Entre votre document LaTeX soigneusement élaboré et le PDF final composé se trouve un logiciel appelé moteur TeX, dont le travail consiste à « exécuter » l’ensemble des commandes LaTeX (c.-à-d. les macros) utilisées pour écrire et construire votre document — en les convertissant en la représentation composée de votre document enregistrée sous forme de fichier PDF. Ceux qui découvrent l’écosystème TeX/LaTeX sont souvent, et à juste titre, déconcertés par la pléthore de noms à consonance cryptique utilisés pour les outils qu’ils rencontrent : TeX, LaTeX, pdfTeX, pdfLaTeX, XeTeX, XeLaTeX, LuaTeX et LuaLaTeX. Si vous ressentez la même chose, une aide est disponible dans l’article Overleaf [Ce qu’il y a dans un nom : guide des nombreuses variantes de TeX](/latex/fr/articles-approfondis/55-what-s-in-a-name-a-guide-to-the-many-flavours-of-tex.md) qui explique l’origine et la signification de tous ces termes. Les moteurs TeX tels que pdfTeX, XeTeX ou LuaTeX sont une catégorie de logiciels appelée *compilateurs de documents*: ils prennent votre code LaTeX et le compilent dans sa forme composée en « convertissant » les macros (commandes) LaTeX en instructions du langage TeX de plus bas niveau qui sont « exécutées » pour produire le résultat composé. Les systèmes de composition basés sur TeX sont capables de produire un contenu exceptionnellement complexe — y compris des mathématiques avancées, de la notation musicale, des structures chimiques, des graphiques et du texte composé multilingue sophistiqué. Pour garantir que ces documents complexes respectent les normes et réglementations d’accessibilité, les moteurs TeX, ainsi que la collection de macros LaTeX et les paquets LaTeX, doivent générer des fichiers PDF correctement balisés en incorporant une grande quantité de données supplémentaires dans les fichiers PDF qu’ils produisent. Bien que les moteurs TeX puissent générer des fichiers PDF extrêmement complexes, leurs processus internes, algorithmes et fonctions ne disposent pas de *la prise en charge intégrée* fonctionnalités *spécialement conçues* pour prendre en charge la production de PDF balisés et accessibles. À la place, la prise en charge du balisage et de l’accessibilité doit être obtenue par une programmation complexe de macros qui « injecte » des données supplémentaires dans les PDF générés par les moteurs TeX — créant les séquences de contenu marqué, les éléments de structure et les structures de données de structure logique stockés dans `StructTreeRoot`. Et c’est là que cette « orchestration » prend tout son sens : le code du cœur (kernel) de LaTeX, ainsi que le code de milliers de paquets et d’innombrables macros créées par les auteurs, devraient coopérer très soigneusement pour garantir que l’exécution des macros produise un balisage correct du contenu des documents résultants. Cette « orchestration » devrait être fiable — quelle que soit la manière dont les auteurs choisissent de combiner et d’utiliser les fonctionnalités, commandes et fonctions de LaTeX, son système de paquets et la puissance des macros TeX. ### Les besoins des auteurs Pour la plupart des gens, LaTeX n’est qu’un outil qui vous permet de créer des documents magnifiquement composés avec la liberté de choisir les paquets qui vous aident à y parvenir. La grande majorité des auteurs LaTeX veulent simplement que leurs documents « fonctionnent » : qu’ils se composent sans erreur afin qu’ils puissent soumettre leur thèse, article, rapport ou terminer ce livre tant attendu. Sans que cela soit déraisonnable, les utilisateurs de LaTeX s’attendent à ce que la collection choisie de paquets LaTeX coexiste paisiblement, en interopérant de façon fluide et transparente pour fournir les commandes et fonctionnalités nécessaires à la production de leurs documents. Ces mêmes attentes sont susceptibles d’exister lorsqu’il s’agit de produire un PDF balisé à partir de LaTeX : cela devrait « simplement fonctionner », de manière transparente et avec une intervention minimale de l’auteur. Malheureusement, nous sommes encore loin de l’expérience « Eh presto ! le balisage se produit, quoi que je fasse de bizarre ». Concilier les exigences techniques de l’accessibilité et du PDF balisé avec LaTeX et la liberté de rédaction est intrinsèquement complexe et, peut-être, il est inévitable qu’une certaine forme de « discipline de l’auteur » soit nécessaire si l’on veut rendre les défis techniques praticables pour une mise en œuvre et une résolution concrètes. Un autre problème, distinct mais lié, est qu’un balisage incorrect peut n’avoir aucun impact visuel sur le PDF final : visuellement, il peut paraître parfait et il s’imprimera probablement sans problème lui aussi, mais, à l’insu de l’auteur, le balisage peut être « cassé », et ne sera découvert qu’à la suite d’un échec ultérieur des vérifications de conformité/validation PDF/A et/ou d’autres tests pratiques via des logiciels d’accessibilité tels que les lecteurs d’écran. ### Fichiers PDF produits sur Overleaf Overleaf fournit à sa communauté d’utilisateurs un éditeur LaTeX basé sur le navigateur, ainsi que des outils de gestion de projets et de documents qui facilitent l’écriture collaborative — le tout construit sur une installation TeX Live standard. En pratique, Overleaf permet aux utilisateurs de « faire tourner LaTeX à distance » via un navigateur Web, en fournissant une couche d’isolation par rapport aux complexités de gestion et de maintenance d’un système TeX Live complet. Une conséquence de l’utilisation par Overleaf d’une installation TeX/LaTeX standard est que les PDF produits à partir du code LaTeX rédigé dans l’éditeur d’Overleaf sont créés à l’aide des mêmes technologies exactes que celles présentes dans toute autre installation TeX Live de même version — y compris les configurations installées par les utilisateurs sur leurs appareils locaux. La seule différence est que les moteurs TeX qui compilent et traitent le code LaTeX d’Overleaf s’exécutent sur des serveurs distants, et non sur des machines locales. Overleaf linéarise le PDF généré par TeX pour un téléchargement/affichage efficace dans un navigateur, mais ce processus n’a aucun lien avec l’accessibilité du contenu PDF lui-même. La production de PDF accessibles via Overleaf repose sur les capacités et fonctionnalités intégrées aux moteurs TeX standard ainsi que sur la disponibilité de paquets de macros LaTeX adaptés que les utilisateurs peuvent déployer dans leurs documents. Les documents LaTeX créés avec Overleaf doivent rester compatibles avec d’autres installations TeX et LaTeX, car les utilisateurs ont fréquemment besoin d’exporter leur projet LaTeX depuis Overleaf pour le soumettre à un large éventail de systèmes de publication de revues. Introduire des fonctionnalités spécifiques à Overleaf dans ses documents LaTeX, ou dans les moteurs TeX sous-jacents, limiterait sérieusement la liberté des utilisateurs d’utiliser leur travail ailleurs. Overleaf reconnaît et soutient le besoin de PDF pleinement accessibles générés à partir de systèmes d’édition TeX/LaTeX : nous consacrons du temps à la recherche sur les problèmes d’accessibilité, à l’exploration des dernières avancées des moteurs TeX et des paquets LaTeX expérimentaux qui prennent en charge le PDF balisé. En fin de compte, au moment de la rédaction, il n’existe pas de solution « prête à l’emploi » que les auteurs LaTeX puissent utiliser (via `\usepackage`) pour générer de manière fluide et transparente des PDF pleinement accessibles et conformes à PDF/UA à partir de documents LaTeX génériques. Lorsque ces solutions seront disponibles via les mises à jour de TeX Live, elles seront bien sûr mises à la disposition de la communauté des utilisateurs d’Overleaf. ### Quelques paquets LaTeX pour explorer le balisage et l’accessibilité Pour beaucoup de gens, [tex.stackexchage](https://tex.stackexchange.com/) est le premier réflexe pour obtenir de l’aide sur TeX, LaTeX ou ConTeXt. C’est une ressource incroyable qui contient de nombreuses questions sur le sujet de [l’accessibilité](https://tex.stackexchange.com/questions/tagged/accessibility?tab=Newest) et de la production de PDF accessibles via LaTeX. Si vous lisez et parcourez ces questions, ainsi que le flot de réponses et de commentaires qui s’ensuit, une seule conclusion s’impose : à l’heure actuelle, il n’existe pas de solution complète, de niveau production, pour créer automatiquement des PDF pleinement accessibles, conformes aux normes et balisés, à partir de tout type de document LaTeX. Il existe cependant quelques paquets qui prennent en charge le balisage — mais peut-être dans un éventail limité de cas d’usage et de types de documents. La liste suivante est fournie aux lecteurs souhaitant explorer le balisage PDF basé sur LaTeX : * [`tagpdf` package](https://ctan.org/pkg/tagpdf) (Ulrike Fischer) : paquet très performant conçu pour expérimenter le balisage PDF. Prend en charge pdfTeX et LuaTeX et fournit une documentation extrêmement utile et intéressante contenant d’excellentes notes sur les défis techniques de la création de PDF balisés via les moteurs TeX ; c’est une lecture vivement recommandée à toute personne souhaitant mieux comprendre les problèmes en jeu. L’orientation future se concentrera probablement sur LuaTeX. * [`axessibility` package](https://ctan.org/pkg/axessibility?lang=en) (Boris Doubrov et Université de Turin) : offre l’accès aux formules dans les fichiers PDF par des technologies d’assistance. * [`l’accessibilité` package](https://ctan.org/pkg/accessibility) (Andy Clifton) : crée des fichiers PDF balisés et structurés. Les notes CTAN indiquent que ce paquet est « destiné aux utilisateurs des classes de documents KOMA-Script ». * [`accsupp` package](https://ctan.org/pkg/accsupp) (Heiko Oberdiek) : paquet expérimental visant à offrir un meilleur support de l’accessibilité pour les fichiers PDF. Une autre référence notable est un article de 2018 [Mise en œuvre des normes PDF pour l’édition mathématique](http://web.science.mq.edu.au/~ross/TaggedPDF/PDF-standards-v2.pdf) du Dr Ross Moore, du Département de mathématiques de l’Université Macquarie. Dans cet article, le Dr Moore donne un bref aperçu des défis du balisage des PDF dans LaTeX : > « La principale source de difficulté réside dans la manière dont différents environnements peuvent interagir les uns avec les autres. Il existe de nombreuses situations dans LaTeX où un environnement ou une structure n’est pas vraiment achevé avant que le suivant n’ait commencé. Il ne s’agit donc pas simplement d’encadrer chaque élément de contenu fourni par des balises de début et de fin. Il faut plutôt comprendre les subtilités de la façon dont les différents environnements et autres structures commencent et se terminent réellement, dans le contexte établi par le matériel environnant. » Le Dr Moore est également l’actuel mainteneur du [`pdfx`](https://ctan.org/pkg/pdfx) paquet et un expert et pionnier du PDF balisé à l’aide de TeX/LaTeX. Son travail mérite vraiment d’être recherché — y compris cette vidéo sur YouTube qui fournit des éclairages intéressants : {% embed url="" %} #### Note sur le paquet pdfx Le [`pdfx`](https://ctan.org/pkg/pdfx) paquet (Ross Moore et al.) offre un excellent support pour PDF/A-1|2|3b (archivage), et d’autres options, mais ne produit pas encore de PDF balisé. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://overleaf-pro.ayaka.space/latex/fr/autres-sujets/04-an-introduction-to-tagged-pdf-files-internals-and-the-challenges-of-accessibility.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.