Vos PDF font partie de l’accessibilité de votre site web
Dernière mise à jour:
Toute organisation qui ne publierait jamais une page web inaccessible publie couramment des PDF inaccessibles : le rapport annuel, le manuel du produit, le formulaire de demande, la liste de prix. Pour la visiteuse qui les télécharge, il n’y a aucune différence — un document qu’elle ne peut pas lire est un service qu’elle ne peut pas utiliser. Cet article traite les PDF publiés comme ce qu’ils sont, une partie de la surface d’accessibilité du site web, et parcourt les six signaux structurels qui décident si la technologie d’assistance peut travailler avec un document : le balisage, la langue, le titre, la structure et les titres, le texte alternatif des images et les signets. Il trace aussi la ligne avec honnêteté : un contrôle structurel léger est un test rapide, pas une validation PDF/UA, et savoir quand vous avez besoin de la validation complète fait partie de bien faire les choses.
Les documents font partie du site
Le travail d’accessibilité a tendance à s’arrêter au bord du HTML. Le site reçoit un audit, les gabarits sont corrigés, le contraste est vérifié — puis la section « documents » continue silencieusement à servir des formulaires numérisés, des exports non balisés et des manuels dont tout le texte est une image incorporée. Pourtant, du côté de l’écran de l’utilisatrice, le PDF est le site web : c’est là que vit le formulaire de pension, là que vivent les consignes de sécurité, là que vit la liste de prix détaillée. Une utilisatrice de lecteur d’écran qui traverse vos pages accessibles et heurte un rapport de 90 pages non balisé n’a pas vécu un service accessible ; elle a vécu un hall accessible et une pièce verrouillée.
La bonne nouvelle, c’est que l’accessibilité des documents échoue de façons prévisibles et vérifiables. Contrairement aux jugements de valeur dans l’accessibilité web — ce motif d’interaction est-il compréhensible, cet ordre de focus est-il logique — les échecs PDF les plus courants sont des faits structurels qu’une machine peut vérifier : les balises sont là ou ne le sont pas, la langue est déclarée ou ne l’est pas. C’est exactement ce que lit le vérificateur d’accessibilité PDF de ce site, localement dans le navigateur, et il s’associe naturellement au contrôle de santé du site web : l’un couvre les pages, l’autre couvre les fichiers que les pages distribuent.
La loi européenne sur l’accessibilité a changé les enjeux
Depuis le 28 juin 2025, la loi européenne sur l’accessibilité s’applique à un large éventail de produits et de services offerts aux consommateurs dans l’UE — y compris le commerce électronique, la banque, les livres électroniques, la billetterie et une grande partie des affaires numériques quotidiennes. Ses exigences sont habituellement satisfaites par la conformité à la norme harmonisée EN 301 549, qui renvoie à son tour aux WCAG — et les WCAG s’appliquent aux documents non web comme aux pages web. En termes clairs : pour les services couverts, un PDF inaccessible dont une cliente a besoin n’est plus seulement un problème de qualité ou d’éthique ; c’est une question de conformité, sur laquelle les autorités de surveillance du marché peuvent agir.
Il convient d’énoncer clairement deux limites, car le droit de l’accessibilité est souvent à la fois exagéré et sous-estimé. La loi ne couvre pas toutes les organisations ni tous les documents — il existe des exemptions (les microentreprises fournissant des services, par exemple) et des dispositions transitoires, et les détails diffèrent selon l’État membre. Et aucun contrôle automatisé, y compris celui de ce site, n’établit la conformité légale ; la conformité est une propriété de l’ensemble du service tel que les utilisateurs le vivent, évalué correctement. Ce que la loi change pour la plupart des équipes est plus simple : les documents sont désormais sans ambiguïté dans le champ de la conversation sur l’accessibilité, si bien que « nous corrigerons les PDF plus tard » a cessé d’être une phrase sûre.
Les six contrôles, un par un
1. PDF balisé. Le balisage est l’arbre de structure caché qui marque les titres, les paragraphes, les listes, les figures et les cellules de tableau, et qui enregistre l’ordre de lecture. C’est la fondation : sans balises, un lecteur d’écran reçoit un flux de contenu dans l’ordre de stockage, ce qui, pour les mises en page multicolonnes et les rapports exportés, peut frôler la salade de mots. Ce que le contrôle ne peut pas vous dire : si les balises sont correctes — un document peut être balisé et avoir quand même des titres marqués comme paragraphes. Balisé est nécessaire, pas suffisant.
2. Langue du document. L’entrée /Lang du catalogue indique à la synthèse vocale dans quelle langue prononcer. Sans elle, un lecteur d’écran en anglais lira joyeusement un rapport en allemand avec une phonétique anglaise, ce qui va du comique à l’incompréhensible. Le contrôle est binaire — une langue est déclarée ou ne l’est pas — et il ne peut pas vous dire si la langue déclarée est la bonne, ni si les passages dans d’autres langues sont marqués individuellement, comme l’exige la bonne pratique.
3. Titre du document. Le titre dans les propriétés du document (ou les métadonnées XMP) est la première chose qu’annonce la technologie d’assistance, ce qu’affiche l’onglet du navigateur et ce qu’un dossier de téléchargements devrait afficher — au lieu de « export_final_v3.pdf ». La préférence du lecteur associée, DisplayDocTitle, décide si les lecteurs PDF affichent ce titre plutôt que le nom de fichier ; le vérificateur la signale séparément, car un titre présent mais caché est une correction à moitié faite. Ce que le contrôle ne peut pas juger, c’est la qualité du titre : « Rapport » réussit, et n’aide personne.
4. Arbre de structure et titres. Un arbre de structure avec de vrais éléments de titre (H, H1–H6) est la façon dont les lecteurs non visuels survolent : la navigation par titres est la stratégie la plus utilisée pour trouver une information dans les documents longs. Le contrôle compte les éléments de titre lorsque l’arbre peut être récupéré. Il ne peut pas vous dire si les niveaux de titre sont dans un ordre sensé ni si les titres décrivent leurs sections — un arbre plein de titres « Sans titre » réussit le comptage et échoue auprès du lecteur.
5. Texte alternatif des images. Le vérificateur compte les XObjects d’image dans les pages face aux éléments de structure /Figure portant un /Alt non vide, et étiquette le résultat comme une approximation — parce qu’une figure peut envelopper plusieurs images, que les images décoratives portent à juste titre un alternatif vide, et que la correspondance entre images dessinées et éléments de structure n’est pas biunivoque. Traitez-le comme une alarme de fumée de couverture, pas comme un audit. Et il ne peut jamais juger le texte alternatif lui-même : « image123.jpg » est un texte alternatif non vide, et il ne vaut rien.
6. Signets. Le plan du document est la main courante des documents longs : un manuel de 200 pages avec des signets est navigable, sans eux c’est un défilement. Le contrôle lit le nombre déclaré du plan. Il ne peut pas vous dire si les signets sont libellés utilement ni s’ils pointent vers les bonnes pages — seulement que la navigation existe. Pour les documents courts, c’est le moins important des six ; pour les rapports et les manuels, c’est la différence entre une référence et une botte de foin.
Un test rapide n’est pas une validation PDF/UA
PDF/UA (ISO 14289) est la norme complète pour les PDF accessibles : structure balisée, ordre de lecture correct, en-têtes de tableau, annotations de liens, libellés de champs de formulaire, contraste et davantage, vérifiés par des validateurs et par des tests humains. Le validateur de référence gratuit et open source veraPDF est un outil de bureau qui vérifie un fichier en profondeur par rapport aux règles PDF/UA vérifiables par machine. Un contrôle navigateur à six signaux ne rivalise pas avec cela, et l’outil de cet article le dit sur sa propre page : c’est le test rapide que vous lancez sur toute une bibliothèque de documents en un après-midi, pour trouver à quels fichiers il manque les bases, pas la certification que vous citez.
Vous avez besoin de la validation complète lorsque le document est essentiel (un formulaire qu’une cliente doit remplir, des informations légales, un sujet d’examen), lorsqu’un processus d’achat ou de conformité demande des preuves, lorsque le document est long et structurel (manuels, rapports annuels), ou chaque fois que les « impossible à déterminer » et les approximations du contrôle léger ne suffisent pas à la décision que vous prenez. La correction professionnelle — corriger l’ordre de lecture, les tableaux et les formulaires dans un outil dédié, puis valider — est une discipline réelle avec un coût réel, et c’est exactement pour cela que le test rapide et bon marché gagne sa place en premier : il vous dit où cet argent doit réellement aller.
Un ordre pragmatique de corrections
Corrigez dans cet ordre, à la source chaque fois que possible. D’abord, la chaîne de production : activez l’export PDF balisé dans Word, InDesign ou votre outil de rapports, et définissez la langue et le titre du document dans les propriétés du gabarit — la plupart des bibliothèques de PDF échouent aux mêmes trois contrôles parce qu’elles partagent un gabarit cassé, si bien qu’une correction de gabarit republie des fichiers propres pour toujours. Ensuite, les titres : utilisez de vrais styles de titre à la source et régénérez les signets à partir d’eux ; cela corrige les contrôles 4 et 6 ensemble. Troisièmement, les images : rédigez le texte alternatif à la source pour les images informatives et marquez les décoratives comme décoratives — ne remplissez pas l’alternatif par lots avec des noms de fichiers. Quatrièmement, l’arriéré : triez la bibliothèque existante par téléchargements et par importance, soumettez tout au test rapide avec le vérificateur, corrigez correctement les documents essentiels, et remplacez ou retirez la longue traîne que vous ne soutenez plus.
Enfin, gardez les documents dans la routine qui garde les pages honnêtes. Quand un nouveau PDF est publié, lancez les mêmes six contrôles avant sa mise en ligne — cela prend moins d’une minute — et relancez le contrôle de santé du site web sur la page qui le lie. Les régressions d’accessibilité arrivent rarement comme des refontes spectaculaires ; elles arrivent comme un export non balisé, téléversé un vendredi, que personne n’a vérifié. Les documents font partie du site. Vérifiez-les comme tels.