PDF accessible : comment faire, les 8 points à vérifier et les outils

Publié le 10 septembre 2026 · Mis à jour le 10 septembre 2026 · L'équipe Vérif RGAA

Rendre un PDF accessible consiste à lui donner une structure lisible par les technologies d'assistance : balisage, hiérarchie de titres, ordre de lecture, alternatives textuelles, langue, titre de document, tableaux avec en-têtes et texte réel plutôt qu'image. Sur un site soumis au RGAA, le critère 13.3 exige que tout document en téléchargement soit accessible ou dispose d'une alternative. Déposez votre fichier dans le vérificateur de PDF pour lancer la vérification complète.

Pourquoi les PDF posent-ils problème ?

Un PDF décrit l'apparence d'une page, pas sa structure. Sans balisage, un lecteur d'écran reçoit un flux de caractères sans savoir ce qui est un titre, une colonne, une cellule ou une image. Les PDF issus de scans sont pires : ce sont des images, sans aucun texte. La directive EAA vise les services dans leur ensemble, documents compris, et le RGAA traite les documents en téléchargement dans sa thématique 13. Un contrat, une facture, un guide ou un formulaire PDF inaccessible fait donc échouer un audit.

Les huit points à vérifier

S'y ajoutent les formulaires (champs étiquetés, ordre de tabulation), les liens (intitulés explicites), les contrastes (les mêmes seuils que pour le web : 4,5:1 pour le texte normal, voir le test de contraste) et les signets pour les documents longs.

Produire un PDF accessible à la source

La méthode la plus économique est de soigner le document d'origine. Dans un traitement de texte : utiliser les styles de titres plutôt que du gras, renseigner l'alternative de chaque image, créer les tableaux avec l'outil tableau et une ligne d'en-tête, définir la langue, renseigner le titre dans les propriétés, puis exporter en PDF avec l'option de balisage activée. Dans un outil de PAO : articuler les blocs dans l'ordre de lecture, définir les styles exportés en balises, marquer les éléments décoratifs comme artefacts. Un document bien structuré à la source produit un PDF accessible sans retouche.

Corriger un PDF existant

Un PDF non balisé peut être traité a posteriori dans un éditeur PDF professionnel : ajout automatique des balises, puis correction manuelle de l'ordre, des alternatives et des tableaux. Un PDF scanné passe d'abord par une reconnaissance de caractères. Pour un volume important de documents anciens, l'alternative la plus raisonnable est souvent de publier une version HTML ou de reconstruire le document à partir de la source. Notre vérificateur renvoie vers un partenaire qui automatise la vérification et la correction.

Cas concrets

Collectivité publiant des délibérations. Documents longs, souvent scannés : OCR, balisage et signets, ou publication du texte en HTML.

Banque envoyant des relevés PDF. Documents générés automatiquement : le gabarit de génération doit produire des PDF balisés ; c'est un chantier informatique, pas éditorial.

PME diffusant une brochure commerciale. Un seul document, produit par une agence : exiger un PDF balisé dans le devis et vérifier les huit points à la livraison.

Site marchand avec conditions générales en PDF. Sous l'EAA, préférer une page HTML aux conditions en PDF, plus simple à rendre accessible et à maintenir.

Vérifier avant de publier

Les erreurs les plus fréquentes dans les PDF « accessibles »

Un PDF peut afficher « balisé : oui » tout en étant inutilisable. Quatre erreurs reviennent. Le balisage automatique qui transforme chaque ligne en paragraphe et chaque mise en gras en titre : l'arbre des balises existe mais ne reflète pas la structure. L'ordre de lecture des documents en colonnes ou avec encadrés, où le lecteur d'écran saute d'un bloc à l'autre. Les alternatives d'images copiées du nom de fichier (« image1.jpg ») ou absentes des logos porteurs d'information. Les tableaux dessinés avec des tabulations, sans balises Table, qui deviennent une suite de nombres sans en-têtes. Un test avec un lecteur d'écran révèle ces défauts en quelques minutes.

PDF ou HTML : comment choisir

Le RGAA n'impose pas le PDF ; il impose que le document en téléchargement soit accessible ou dispose d'une alternative. Pour un contenu destiné à être lu en ligne (conditions générales, guide, notice), une page HTML est plus simple à rendre accessible, à maintenir et à indexer. Le PDF garde sa place pour les documents destinés à être imprimés, signés ou archivés : factures, attestations, contrats. Une bonne pratique consiste à publier le HTML comme version de référence et le PDF balisé comme version imprimable.

Vérifier un lot de documents

Pour un site qui publie des centaines de PDF, une vérification manuelle document par document n'est pas réaliste. Commencez par un inventaire (nombre, date, source, audience), puis classez : documents encore utiles à rendre accessibles ou à convertir en HTML, documents d'archive à laisser avec une mention et une alternative sur demande, documents à retirer. Traitez en priorité ceux qui font partie d'un parcours (formulaires, conditions, factures) : ce sont ceux qu'un audit RGAA et une action en justice viseront en premier.

Ouvrez le document avec un lecteur d'écran et écoutez-le du début à la fin : c'est le test le plus fiable. Complétez par la checklist développeur pour la page qui héberge le lien, et par le test d'accessibilité pour le site dans son ensemble.