PDF et accessibilité : pourquoi vos documents administratifs sont hors des clous

Un PDF publié sur un site public est soumis aux mêmes obligations d'accessibilité RGAA qu'une page HTML classique. C'est un point que je vois systématiquement sous-estimé dans les audits, y compris chez des organisations par ailleurs rigoureuses sur l'accessibilité de leur site.

Pourquoi les PDF posent un problème spécifique

Un PDF exporté depuis un logiciel de mise en page (InDesign, Word, PowerPoint) sans attention particulière produit presque toujours un document visuellement correct mais structurellement vide pour un lecteur d'écran : pas de balisage de titres, pas d'ordre de lecture logique, pas de texte alternatif sur les images, parfois même du texte qui n'est en réalité qu'une image scannée, donc totalement invisible pour une technologie d'assistance.

Les erreurs les plus fréquentes

L'absence de structure de titres balisée

Un PDF peut afficher visuellement des titres en gras et en plus grande taille sans que ce soit balisé comme un titre au sens de l'accessibilité. Un lecteur d'écran ne peut alors pas naviguer de titre en titre, ce qui rend la navigation dans un document long extrêmement pénible.

L'ordre de lecture qui ne correspond pas à l'ordre visuel

Les mises en page à plusieurs colonnes ou avec des encadrés produisent souvent un ordre de lecture pour lecteur d'écran incohérent avec l'ordre visuel, ce qui rend le contenu incompréhensible même si chaque élément pris isolément est correctement balisé.

Les tableaux sans en-têtes balisés

Un tableau de données sans en-têtes de colonnes et de lignes correctement identifiés oblige un utilisateur de lecteur d'écran à deviner à quelle colonne correspond chaque valeur, cellule par cellule.

Les formulaires PDF sans étiquettes associées

Un champ de formulaire PDF (à remplir et renvoyer) sans étiquette techniquement associée au champ est aussi problématique qu'un champ de formulaire web sans balise label.

Comment produire un PDF accessible dès la source

La correction la plus efficace se fait en amont, dans le logiciel source, pas après export. Dans Word ou InDesign, utiliser les styles de titre natifs (Titre 1, Titre 2) plutôt qu'une simple mise en forme visuelle, renseigner les textes alternatifs des images avant l'export, structurer les tableaux avec de vrais en-têtes de colonnes.

À l'export, vérifier que l'option de balisage d'accessibilité (accessibility tags) est activée, ce qui n'est pas toujours le réglage par défaut selon le logiciel utilisé. Adobe Acrobat Pro permet de vérifier et corriger un PDF déjà produit via son outil d'accessibilité intégré, plus fiable qu'une correction manuelle.

Le cas des documents déjà publiés

Pour les documents existants qui ne peuvent pas être régénérés facilement (archives, documents historiques), l'obligation RGAA n'impose pas nécessairement une remise en conformité rétroactive de l'ensemble du fonds documentaire, mais demande de documenter cette limite dans la déclaration d'accessibilité et de proposer une alternative accessible sur demande. C'est un point que je détaille dans mon article sur les obligations RGAA des entreprises privées.

Ce que je vérifie en priorité dans un audit

Les documents à fort trafic (formulaires administratifs, notices, rapports publics téléchargés fréquemment) plutôt que l'intégralité d'un fonds documentaire, en cohérence avec la logique de priorisation que j'applique plus largement dans un audit RGAA.