Guide d'accessibilité PDF : balises et PDF/UA

Les PDF sont le problème d’accessibilité silencieux au sein de presque toutes les organisations. Les sites web sont audités, repensés et testés avec des lecteurs d’écran — mais le rapport annuel, le document de politique, le relevé de prestations et le formulaire de demande qui vivent derrière un lien de téléchargement sont trop souvent diffusés exactement tels qu’ils sont sortis de la boîte de dialogue d’export. Pour un lecteur voyant, ils paraissent soignés. Pour une personne utilisant un lecteur d’écran, une loupe ou une navigation au clavier uniquement, ce même fichier peut être un mur impénétrable : aucun titre entre lesquels naviguer, des images sans description, des tableaux qui se lisent comme un flux de chiffres dénué de sens, et des champs de formulaire impossibles à remplir.

Ce guide explique pourquoi les PDF sont si fréquemment inaccessibles et ce qui rend réellement un PDF utilisable par les technologies d’assistance. Il couvre les briques structurelles — balises, ordre de lecture, texte alternatif, tableaux, formulaires et métadonnées — ainsi que les normes qui les régissent : WCAG 2.2 et PDF/UA, la spécification ISO 14289 pour les PDF balisés accessibles. Tout au long, l’objectif est celui que QualiBooth applique à chaque document que nous touchons : un fichier qui fonctionne en pratique, confirmé avec de vraies technologies d’assistance, et pas seulement validé par un vérificateur automatique.

Pourquoi les PDF sont si souvent inaccessibles

Un PDF est, au fond, une description de la manière de peindre des marques sur une page. Le format a été conçu pour préserver la fidélité visuelle — pour qu’un document paraisse identique sur n’importe quel écran ou imprimante. Cet objectif de conception est précisément ce qui rend l’accessibilité difficile. La fidélité visuelle ne dit rien sur le sens. Une ligne de texte gras en 18 points ressemble à un titre pour l’œil humain, mais à moins que le fichier n’enregistre explicitement « ceci est un titre », la technologie d’assistance n’a aucun moyen de savoir qu’il s’agit d’autre chose que de glyphes plus grands.

La plupart des PDF en circulation sont non balisés. Ils contiennent le contenu visuel mais aucune de la structure sous-jacente — aucune information sur ce qui est un titre, un paragraphe, une liste, un tableau ou une image. Un lecteur d’écran confronté à un PDF non balisé soit refuse de le lire de manière intelligible, soit recourt à des conjectures, déduisant un ordre de lecture à partir de la position des marques sur la page. Les résultats vont de maladroits à inutilisables : une lettre d’information sur deux colonnes lue tout droit à travers les deux colonnes, une légende lue avant le paragraphe auquel elle appartient, ou des notes de bas de page interrompant le milieu d’une phrase.

Plusieurs habitudes de production courantes aggravent les choses :

Documents numérisés. Une numérisation n’est qu’une image d’une page. Sans reconnaissance optique de caractères (OCR), il n’y a pas de vrai texte du tout — rien à lire, rechercher ou sélectionner.
Exports qui suppriment la structure. De nombreux chemins « Enregistrer au format PDF » et « Imprimer en PDF » abandonnent la structure de titres et de listes qui existait dans le document source.
Mises en page d’outils de conception. Les fichiers créés dans un logiciel de mise en page peuvent avoir des pages visuellement correctes dont l’ordre des objets sous-jacents n’a aucun rapport avec la séquence de lecture prévue.
Encombrement décoratif. Les images d’arrière-plan, les filets et les ornements sont exposés à la technologie d’assistance et annoncés comme s’ils portaient un sens.

Rien de tout cela n’est visible à l’écran, ce qui explique précisément pourquoi le problème persiste. La solution consiste à ajouter la couche structurelle que le format laisse facultative — le travail de remédiation PDF.

Balises et structure du document

Les balises sont le fondement d’un PDF accessible. Un PDF balisé porte une hiérarchie cachée — l’arbre de structure — qui se trouve aux côtés du contenu visuel et décrit ce que chaque élément de la page est réellement. Ceci est directement analogue au HTML sémantique derrière une page web bien construite : là où le HTML utilise <h1>, <p>, <ul> et <table>, un PDF balisé utilise des éléments de structure tels que <H1>, <P>, <L> (liste) et <Table>.

L’arbre de balises est ce qui donne à la technologie d’assistance quelque chose à parcourir. Une fois en place, un lecteur d’écran peut faire les choses sur lesquelles ses utilisateurs comptent :

Sauter par titre. Les utilisateurs parcourent un long document de titre en titre plutôt que d’écouter chaque mot dans l’ordre. Cela nécessite de vraies balises de titre (<H1> à <H6>) appliquées dans un ordre logique et imbriqué — sans jamais sauter de niveaux, sans jamais simuler un titre en mettant un paragraphe en gras.
Comprendre les listes. Une balise <L> avec ses éléments <LI> indique au lecteur d’écran « ceci est une liste de cinq éléments », afin que l’utilisateur sache où il se trouve et combien il reste.
Distinguer le contenu de la décoration. Le contenu véritable est balisé ; les marques purement décoratives sont désignées comme des artefacts afin d’être entièrement ignorées.

Une structure de titres correcte et logiquement imbriquée est la chose la plus déterminante que vous puissiez réussir dans un PDF, car elle transforme une expérience d’écoute linéaire en une expérience navigable. La rater — ou l’omettre — est l’un des problèmes d’accessibilité courants qui ressort sans cesse dans les audits de documents.

Ordre de lecture

Les balises disent *ce qu’*est chaque élément. L’ordre de lecture dit dans quelle séquence ces éléments sont présentés à quelqu’un qui ne peut pas voir la page. Les deux sont liés mais distincts, et l’ordre de lecture est là où de nombreux PDF par ailleurs bien balisés échouent.

Un lecteur d’écran annonce le contenu dans l’ordre défini par la structure du document, et non dans l’ordre où les marques se trouvent dans le fichier. Dans un document à une seule colonne, les deux s’alignent généralement. Dans tout ce qui est plus complexe — mises en page à plusieurs colonnes, encadrés latéraux, citations en exergue, légendes, texte enroulé autour d’une image — ils divergent fréquemment. L’œil voyant réorganise le contenu sans effort ; la technologie d’assistance suit l’ordre qui lui est donné, et si cet ordre est erroné, le sens s’effondre.

Un bon ordre de lecture signifie que le contenu est annoncé dans la séquence qu’un lecteur voyant suivrait naturellement : le titre avant le corps du texte, l’introduction avant l’encadré, une légende après la figure qu’elle décrit. Le définir correctement relève d’un jugement manuel sur la manière dont le document est censé être lu, c’est pourquoi les outils automatisés seuls ne peuvent pas le garantir. C’est l’un des livrables essentiels de la remédiation PDF professionnelle, et l’une des premières choses que vérifient les testeurs expérimentés.

Texte alternatif pour les images

Chaque image porteuse d’information a besoin d’un équivalent textuel afin de pouvoir être décrite aux personnes qui ne peuvent pas la voir. Les principes sont les mêmes que pour le web, appliqués au moyen des balises PDF.

Images informatives — graphiques, diagrammes, photographies porteuses de sens, infographies — nécessitent un texte alternatif concis et exact qui communique la même information que l’image. Pour un graphique, cela signifie souvent résumer le message clé (« Le chiffre d’affaires a augmenté de 12 % d’une année sur l’autre ») plutôt que de décrire le visuel (« un graphique à barres en bleu »).
Images complexes — un schéma de processus détaillé ou une figure riche en données — peuvent nécessiter à la fois un court texte alternatif et une description plus longue, ou les données sous-jacentes présentées sous une forme accessible ailleurs dans le document.
Images décoratives — bordures, textures d’arrière-plan, séparateurs ornementaux, un logo répété dans un pied de page — doivent être marquées comme des artefacts afin que la technologie d’assistance les ignore. Forcer un lecteur d’écran à annoncer « image, image, image » pour de la décoration est en soi un échec d’accessibilité.
Texte à l’intérieur des images — un graphique d’une citation, un en-tête de lettre numérisé, l’image d’un bouton avec une étiquette — doit voir ce texte capturé, soit comme texte alternatif soit, mieux encore, comme du vrai texte sélectionnable.

Rédiger un bon texte alternatif est une tâche de contenu, pas une tâche technique. Cela exige de comprendre à quoi sert l’image dans son contexte — la même compétence que notre équipe de conseil en accessibilité apporte au contenu web.

Tableaux accessibles

Les tableaux sont l’endroit où l’accessibilité PDF devient véritablement difficile, et là où les exports automatisés échouent le plus souvent. Un tableau de données communique le sens à travers la relation entre une cellule et ses en-têtes de ligne et de colonne. Les lecteurs voyants reconstruisent ces relations visuellement en jetant un regard vers le haut et vers la gauche. Un utilisateur de lecteur d’écran ne le peut pas — il dépend du fait que le tableau soit balisé de sorte que les associations d’en-têtes soient explicites.

Un tableau PDF accessible nécessite :

Une structure <Table> correcte contenant des <TR> (lignes), des <TH> (cellules d’en-tête) et des <TD> (cellules de données), plutôt qu’une grille lâche de texte positionné pour ressembler à un tableau.
Des cellules d’en-tête correctement identifiées, avec une portée (ligne ou colonne) là où la disposition du tableau l’exige, de sorte qu’à mesure qu’un utilisateur parcourt les données, les en-têtes pertinents soient réannoncés (« T3, Chiffre d’affaires, 1,2 million »).
Une gestion judicieuse des cellules fusionnées ou étendues, qui compliquent les relations d’en-tête et déroutent fréquemment les outils automatisés.

Un anti-modèle courant est le tableau de mise en page — une grille utilisée uniquement pour positionner visuellement le contenu, sans réelles relations de données. Les tableaux de mise en page ne doivent pas du tout être balisés comme des tableaux, car le faire force la technologie d’assistance à annoncer des lignes et des colonnes fantômes. Distinguer un tableau de données d’un artefact de mise en page, puis encoder les bonnes relations, est un travail manuel minutieux qui bénéficie énormément de l’examen par des personnes qui utilisent réellement des lecteurs d’écran chaque jour.

Formulaires PDF accessibles

Les formulaires sont les documents les plus sensibles qu’une organisation publie, parce qu’ils sont transactionnels : une demande, une réclamation, un consentement, une inscription. Si un formulaire PDF ne peut pas être complété avec une technologie d’assistance, la personne n’est pas simplement gênée — elle est exclue d’un service.

Un formulaire PDF accessible nécessite :

Des champs étiquetés. Chaque champ — saisie de texte, case à cocher, bouton radio, liste déroulante — a besoin d’un nom accessible (une infobulle/étiquette en termes PDF) afin qu’un lecteur d’écran annonce à quoi sert le champ, et pas seulement « modifier le texte ».
Un ordre de tabulation logique. Les utilisateurs au clavier parcourent les champs avec la touche Tab. L’ordre de tabulation doit suivre le flux visuel et logique du formulaire, et non l’ordre dans lequel les champs ont été ajoutés dans l’éditeur.
Des contrôles regroupés. Les boutons radio et cases à cocher associés doivent être regroupés afin que leur question commune soit annoncée une fois et que les options soient comprises comme un ensemble.
Champs obligatoires et instructions. Les champs obligatoires, les exigences de format et les conseils en cas d’erreur doivent être transmis par du texte, et non uniquement par la couleur ou des indices visuels.
Pleine opérabilité au clavier. Chaque champ doit être atteignable et utilisable sans souris.

Les formulaires se situent à l’intersection de la structure, de l’interaction et du contenu, ce qui en fait la partie du travail PDF où le faire correctement importe le plus. La même discipline s’applique à d’autres documents transactionnels — elle est étroitement liée au soin requis pour l’e-mail accessible, où la structure et l’étiquetage déterminent si un message peut réellement être utilisé.

Langue, titre et métadonnées

Certaines des corrections PDF les plus déterminantes sont aussi les plus modestes. Une poignée de propriétés au niveau du document changent matériellement la manière dont la technologie d’assistance gère un fichier.

Langue du document. Le PDF doit déclarer sa langue principale (par exemple, fr-FR) afin qu’un lecteur d’écran utilise les bonnes règles de prononciation. Un paragraphe anglais lu avec une phonétique française, ou vice versa, est à peine intelligible. Les passages dans une langue différente de celle du document principal doivent porter leurs propres marqueurs de langue.
Titre du document. Les métadonnées du PDF doivent inclure un titre significatif, et la visionneuse doit être réglée pour afficher ce titre plutôt que le nom du fichier. « Rapport annuel d’accessibilité 2026 » est annoncé et affiché ; « final_v3_POURLEWEB.pdf » ne l’est pas.
Navigation par onglets et signets. Les signets (le plan du document) donnent à tous les utilisateurs — et surtout à ceux qui naviguent de manière non visuelle — un moyen de sauter vers les sections principales d’un long document.
Indicateurs de PDF balisé et de métadonnées propres. Le fichier doit être marqué comme un PDF balisé et porter des métadonnées cohérentes et exactes.

Ces propriétés prennent quelques minutes à définir et sont requises pour la conformité, et pourtant elles sont omises dans la grande majorité des PDF publiés.

WCAG 2.2 et PDF/UA (ISO 14289)

Deux normes régissent les PDF accessibles, et elles fonctionnent ensemble plutôt que de se concurrencer.

WCAG 2.2 est la base de référence indépendante de la technologie pour l’accessibilité numérique. Ses critères de succès — équivalents textuels, information et relations, séquence significative, contraste, opérabilité au clavier, et le reste — s’appliquent aux PDF tout comme ils s’appliquent aux pages web. WCAG 2.2 est la norme vers laquelle pointent la plupart des lois, et le W3C publie des techniques spécifiques pour satisfaire WCAG avec les fonctionnalités PDF (baliser les titres, fournir un texte alternatif, définir l’ordre de lecture, etc.). Si vous travaillez sur la conformité générale, notre guide pour rendre le contenu conforme à WCAG et l’aperçu de la conformité WCAG s’appliquent tous deux directement aux documents.

PDF/UA — officiellement ISO 14289 — est la spécification technique du PDF accessible. Là où WCAG décrit des résultats (« fournir des équivalents textuels »), PDF/UA prescrit exactement comment un PDF doit être construit pour être un document accessible, correctement balisé et lisible par machine : quels types de structure utiliser, comment l’arbre de balises doit être formé, comment les artefacts doivent être marqués, et comment les formulaires et tableaux doivent être encodés. Les deux sont complémentaires — l’approche la plus robuste consiste à remédier selon les exigences techniques de PDF/UA tout en validant les résultats du côté de l’utilisateur par rapport à WCAG 2.2.

La conformité à ces normes est ce qui sous-tend les obligations légales dans toutes les juridictions. Les PDF publiés par les organisations concernées relèvent pleinement de l’European Accessibility Act, de l’ADA et de la Section 508, qui toutes traitent les documents téléchargeables comme une partie de l’expérience numérique devant être accessible.

Remédier des PDF existants vs créer des PDF accessibles

Il existe deux voies vers des PDF accessibles, et la plupart des organisations ont besoin des deux.

Remédier des PDF existants signifie prendre un fichier terminé — un rapport, un fonds de relevés, un formulaire numérisé — et ajouter ou corriger la couche d’accessibilité : exécuter l’OCR là où c’est nécessaire, construire l’arbre de balises, définir l’ordre de lecture, rédiger le texte alternatif, corriger les tableaux et étiqueter les champs de formulaire. La remédiation est essentielle lorsque les fichiers sources ont disparu, lorsque les documents ont été produits par des tiers, ou lorsque vous disposez d’une archive publiée qui doit être mise en conformité. De manière cruciale, la remédiation modifie la structure sous-jacente, et non la conception visuelle — le document paraît identique et devient utilisable par tous. C’est le cœur du service de remédiation PDF de QualiBooth, qui dimensionne les lots par importance et portée et priorise d’abord les documents qui comptent le plus.

Créer des PDF accessibles signifie intégrer l’accessibilité dans le processus de production afin que les documents naissent accessibles. Cela implique d’utiliser de vrais styles de titre, des styles de liste et du texte alternatif dans l’application source ; de concevoir les tableaux comme des tableaux de données ; de définir la langue et le titre ; et de choisir un chemin d’export qui préserve l’arbre de balises. Créer de manière accessible est nettement moins coûteux que réparer le même document plus tard, et c’est la seule réponse durable pour les organisations qui publient des PDF en continu.

Les deux approches ne sont pas exclusives l’une de l’autre. Le modèle pratique consiste à remédier les documents déjà en circulation tout en corrigeant le processus en amont afin que les nouveaux documents ne recréent pas le problème. Ancrer ce changement est précisément ce qu’aborde l’amélioration des processus d’accessibilité — transformer la publication accessible d’un projet ponctuel en la manière par défaut dont votre équipe travaille. Une vue plus large de la façon dont le travail sur les documents et le web s’articulent est présentée dans notre aperçu des services d’accessibilité.

Valider avec des lecteurs d’écran — et pourquoi les overlays n’aident pas

Un PDF n’est accessible que s’il fonctionne réellement pour les personnes qui en dépendent. C’est pourquoi la validation ne peut pas s’arrêter à un vérificateur automatique. Les outils qui analysent un PDF par rapport aux règles PDF/UA sont précieux — ils détectent les balises manquantes, les langues non définies et les erreurs structurelles à grande échelle — mais ils vérifient la présence de la structure, et non sa qualité. Un outil automatisé peut confirmer qu’une image a un texte alternatif ; il ne peut pas vous dire que ce texte alternatif est erroné. Il peut confirmer qu’un titre existe ; il ne peut pas vous dire qu’il est imbriqué au mauvais niveau.

Une véritable validation combine les deux :

Vérification automatisée pour détecter largement et de manière cohérente les défaillances structurelles et de métadonnées. Un logiciel comme la plateforme d’analyse d’accessibilité de QualiBooth excelle à signaler les problèmes détectables par la machine sur de grands volumes.
Tests manuels avec une technologie d’assistance — naviguer dans le document avec un lecteur d’écran, se déplacer par titre, lire les tableaux, tabuler à travers un formulaire — pour confirmer que l’expérience est cohérente. C’est le seul moyen de vérifier l’ordre de lecture, la qualité du texte alternatif et l’utilisabilité des formulaires. Notre méthodologie d’audit manuel explique pourquoi les tests humains sont irremplaçables, et les audits menés par des personnes en situation de handicap font remonter des problèmes qu’aucun vérificateur et aucun testeur voyant ne remarquerait jamais.

Un mot de prudence sur les raccourcis. Les overlays d’accessibilité — scripts ou widgets tiers qui prétendent corriger automatiquement l’accessibilité — ne résolvent pas l’accessibilité PDF, et QualiBooth ne les approuve pas. Ils ne peuvent pas créer un arbre de balises correct, juger de l’ordre de lecture ni rédiger un texte alternatif significatif, parce que ces tâches exigent de comprendre le contenu et l’intention du document. Il n’existe aucun substitut automatisé à une remédiation appropriée. Une véritable accessibilité PDF provient d’une structure correcte plus une vérification humaine — l’approche derrière notre travail de remédiation PDF.

Foire aux questions

Un PDF non balisé est-il jamais acceptable ? Non. Un PDF non balisé est par définition inaccessible à la technologie d’assistance et échoue à la fois à WCAG 2.2 et à PDF/UA. Tout PDF que vous publiez pour le public ou pour des employés doit être balisé.

Rendre un PDF accessible change-t-il son apparence ? Non. La remédiation ajoute et corrige la couche structurelle cachée — balises, ordre de lecture, métadonnées — sans altérer la conception visuelle. La page paraît identique.

Devrais-je simplement fournir une version HTML au lieu d’un PDF accessible ? Une alternative HTML accessible est souvent la meilleure expérience et vaut la peine d’être proposée. Mais si vous publiez le PDF, le PDF lui-même doit être accessible — une alternative HTML n’exempte pas le document des exigences de conformité.

Les documents numérisés peuvent-ils être rendus accessibles ? Oui, mais ils doivent d’abord passer par l’OCR pour créer du vrai texte, après quoi les étapes normales de remédiation — balisage, ordre de lecture, texte alternatif, tableaux — s’appliquent.

Comment garder les nouveaux PDF accessibles sans remédier chacun d’eux ? Corrigez le processus de création : utilisez de vrais styles et du texte alternatif dans la source, concevez de vrais tableaux de données, définissez la langue et le titre, et exportez via un chemin qui préserve les balises. Associer la remédiation à l’amélioration des processus fait des documents accessibles la norme par défaut.

Conclusion

L’accessibilité PDF n’est pas une étape de finition optionnelle — c’est la différence entre un document que tout le monde peut utiliser et un document qui exclut silencieusement les personnes qui dépendent de la technologie d’assistance. Le travail est concret et bien compris : baliser la structure, définir un ordre de lecture correct, décrire les images, encoder correctement les tableaux et les formulaires, déclarer la langue et le titre, et valider le résultat par rapport à WCAG 2.2 et PDF/UA avec de vrais lecteurs d’écran ainsi que des outils automatisés. Remédiez les documents que vous publiez déjà, corrigez le processus qui en produit de nouveaux, et évitez les raccourcis par overlay qui promettent l’accessibilité sans la livrer.

Si vos rapports, relevés, brochures ou formulaires n’ont jamais été vérifiés, c’est par là qu’il faut commencer. Vous pouvez commencer par une analyse d’accessibilité gratuite, demander une démo de la plateforme QualiBooth, ou parler à notre équipe de la remédiation PDF pour un seul document critique ou un fonds documentaire entier.