PDF accessible : vérifier un document

Ce que demande le RGAA

Le critère 13.3 du RGAA 4.1.2 porte sur les documents bureautiques proposés en téléchargement. Chacun doit remplir l’une de ces trois conditions :

• le document lui-même est compatible avec l’accessibilité ;
• une autre version, elle aussi téléchargeable, l’est ;
• une version au format HTML l’est.

Le critère 13.4 complète le premier : quand un document a une version accessible, elle doit offrir la même information que l’original. Sa méthode consiste à ouvrir les deux fichiers et à les comparer. Aucun outil automatique ne fait ce travail, celui-ci non plus.

Le glossaire cite les formats reconnus compatibles : Microsoft Office (Word 2003, OOXML), OpenOffice (ODF), Adobe PDF et EPUB/Daisy. Un fichier texte (.txt) ne peut pas servir de version accessible. Les deux critères sont rattachés à des critères de niveau A des WCAG 2.1, dont 1.1.1 (alternatives des contenus non textuels), 1.3.1 (structure) et 3.1.1 (langue).

Un cas particulier figure au critère 13.3 : pour les personnes de droit privé visées par la loi de 2005, les fichiers publiés avant le 23 septembre 2018 sont exemptés, sauf s’ils servent à accomplir une démarche administrative. Le critère est alors non applicable.

Le RGAA 5, annoncé pour la fin de 2026, doit définir des critères et des tests propres aux documents bureautiques ( annonce de la Dinum ). Ce qui suit vaut pour le RGAA 4.1.2, en vigueur.

Comment la méthode officielle vérifie un document

Pour un PDF, la méthode du critère 13.3 fait analyser le fichier avec l’outil PAC (PDF Accessibility Checker) et vérifier l’absence d’erreur. Elle précise que PAC contrôle aussi des exigences de qualité, comme la norme PDF/UA, et que seules les erreurs liées aux critères des documents bureautiques rendent le critère non conforme. PAC ne fonctionne que sous Windows ; sur Mac, le contrôle se fait à la main. Pour un fichier Word, la méthode cite le vérificateur d’accessibilité de Microsoft Office.

Pour un fichier OpenDocument (.odt), la méthode demande de vérifier à la main que tout le contenu respecte la liste des critères « Liste document bureautique en téléchargement ». Elle note qu’OpenOffice et LibreOffice ne possèdent pas de vérificateur d’accessibilité, et admet un raccourci pour un document très simple : l’enregistrer en .docx et passer le vérificateur de Microsoft Office, en sachant que la langue, certaines alternatives d’images et les en-têtes fusionnés des tableaux sont mal convertis.

Cet outil ne remplace ni l’un ni l’autre. Il sert avant : trier une série de documents, repérer ceux qui ne sont pas balisés ou n’ont ni titre ni langue, depuis n’importe quel appareil.

Ce que l’outil relève, point par point

Pour un PDF, chaque point s’appuie sur une technique PDF des WCAG ou sur la norme PDF/UA :

• Balisage : la présence d’un arbre de structure et de l’indicateur qui déclare le document balisé. Sans balises, un lecteur d’écran reçoit le texte sans titres, sans listes, parfois dans le désordre. La norme PDF/UA (ISO 14289) fixe les exigences d’un PDF accessible ; un fichier qui s’en réclame le déclare dans ses métadonnées, ce que l’outil signale sans le prendre pour une preuve.
• Texte réel : un document sans police n’est fait que d’images, comme une numérisation. La technique PDF7 décrit la reconnaissance de caractères qui lui donne du texte.
• Titre : l’entrée Title des propriétés, et l’option qui l’affiche à l’ouverture à la place du nom de fichier ( technique PDF18). Un titre comme « Microsoft Word - rapport.docx » est signalé : c’est un nom de fichier.
• Langue : l’entrée Lang du catalogue du document ( technique PDF16), qui fixe la prononciation d’une synthèse vocale.
• Titres de section : les balises H1 à H6 ( technique PDF9), y compris celles qu’un logiciel nomme autrement et rattache aux balises standard.
• Images : chaque balise Figure doit porter un texte de remplacement, l’entrée Alt (technique PDF1). Un texte de substitution, l’entrée ActualText, est aussi accepté par le protocole Matterhorn de PDF/UA (point 13-004) ; l’outil le compte, en signalant qu’il convient à une image de texte plutôt qu’à une illustration.
• Tableaux : un tableau balisé sans cellule d’en-tête TH est signalé ( technique PDF6).
• Champs de formulaire : chaque champ doit avoir un nom restitué, souvent porté par son info-bulle, l’entrée TU (technique PDF12).
• Signets : ils permettent d’aller à une section sans parcourir tout le document (technique PDF2). L’outil ne les demande qu’à partir de 10 pages : c’est notre seuil, pas une règle.

Pour un fichier Word ou OpenDocument, l’outil lit le titre et la langue déclarés dans le fichier, les paragraphes mis en forme avec un style de titre, les textes de remplacement des images (ou leur marquage décoratif, dans Word comme dans LibreOffice) et les lignes d’en-tête des tableaux. Dans ces formats, l’ordre des titres est celui du document : un saut de niveau, un titre 3 juste après un titre 1, est donc signalé. Dans un PDF, l’ordre des objets du fichier n’est pas celui de la lecture : l’outil n’y compte pas les sauts.

Un point « à vérifier » n’est pas une erreur : l’outil ne peut pas trancher seul. Un tableau sans en-tête est une faute pour un tableau de données, pas pour un tableau de mise en page.

Ce que l’outil ne voit pas

• L’ordre de lecture : il suit l’arbre des balises, que seul un lecteur d’écran ou un outil comme PAC permet de parcourir.
• La justesse des textes : un texte de remplacement « image1.png » compte comme présent, un titre de section mal choisi aussi.
• Les contrastes, les couleurs, la taille des caractères, les liens et leur intitulé, les listes, le contenu décoratif marqué comme artefact.
• L’usage d’un formulaire au clavier, l’ordre de tabulation, les messages d’erreur d’un formulaire.
• Un document protégé : chiffré, ses textes et ses flux compressés ne se lisent pas sans la clé. L’outil n’en lit alors ni le titre ni la langue, les met « à vérifier », et passe « à vérifier » tout point qu’il aurait mis « à corriger ».
• La comparaison entre un document et sa version accessible (critère 13.4), et le reste des formats : présentations, tableurs, EPUB.

Corriger à la source

Un PDF accessible se prépare dans le logiciel qui l’a produit. Dans le document d’origine, utilisez les styles de titre, ajoutez un texte de remplacement aux images qui portent une information, déclarez la ligne d’en-tête des tableaux, renseignez le titre et la langue. Puis exportez avec l’option prévue :

• Word : Enregistrer sous, format PDF, Options, case « Balises de structure de document pour l’accessibilité » ( Microsoft ) ;
• LibreOffice : Exporter au format PDF, option « Accessibilité universelle (PDF/UA) », qui active le balisage ( aide LibreOffice ).

Corriger le PDF lui-même reste possible avec un éditeur PDF, mais la correction est perdue au prochain export : elle est à refaire à chaque nouvelle version du document.

Sources

RGAA 4.1.2, critère 13.3 (version accessible d’un document en téléchargement) ; RGAA 4.1.2, critère 13.4 (même information dans la version accessible) ; RGAA 4.1.2, glossaire : Version accessible (pour un document en téléchargement) ; DesignGouv, Nouvelle version du RGAA (2 mars 2026) ; Techniques PDF des WCAG 2.1 (PDF1, PDF2, PDF6, PDF7, PDF9, PDF12, PDF16, PDF18), en anglais ; WCAG 2.1, critères 1.1.1, 1.3.1, 2.4.2 et 3.1.1, en anglais ; Bibliothèque du Congrès, fiche PDF/UA-1 (ISO 14289-1), en anglais ; PDF Association, points de contrôle du protocole Matterhorn (PDF/UA), en anglais ; Microsoft, Créer des PDF accessibles ; Aide LibreOffice, options d’export PDF (PDF/UA) .

Page mise à jour le 11 novembre 2026.