La loi exige les WCAG. PDF/UA est nécessaire, mais ne suffit pas.
Deux normes reviennent dès qu’on parle de PDF accessible, et on les présente souvent comme deux options entre lesquelles il faudrait choisir. Ce n’en sont pas. Elles ne répondent pas à la même question, elles ne sont pas citées par les mêmes textes, et un document qui vise l’une sans l’autre échoue presque toujours quelque part.
Notre position tient en deux phrases. La loi exige les WCAG. PDF/UA est nécessaire, mais ne suffit pas. Le reste de cet article explique pourquoi, en s’appuyant sur les textes eux-mêmes.
Deux normes, deux questions
PDF/UA (ISO 14289) répond à la question : le fichier est-il bien construit ? Ses contenus sont-ils balisés, dans le bon ordre, avec une langue déclarée et une alternative pour chaque image ? C’est une norme propre au format PDF, que nous détaillons dans PDF/UA : ce que la norme exige, et ce qu’elle ne garantit pas.
Les WCAG, règles pour l’accessibilité des contenus web publiées par le W3C, répondent à une autre question : la personne comprend-elle ? Le texte se distingue-t-il de son fond, l’alternative décrit-elle vraiment l’image, l’intitulé du lien garde-t-il son sens hors contexte ? Écrites pour le web, elles s’appliquent aux documents par l’intermédiaire de la norme européenne EN 301 549 et, en France, du RGAA.
La première question se pose sur la forme du fichier, et une bonne partie de la réponse s’obtient avec un validateur. La seconde se pose sur le sens, et elle demande un jugement humain.
Où elles se recouvrent, où elles divergent
| Exigence | PDF/UA | WCAG |
|---|---|---|
| Contenu structuré et balisé | exigé, avec la balise sémantiquement la plus juste | exigé : l’information et les relations doivent être restituables |
| Ordre de lecture logique | exigé | exigé |
| Alternative textuelle des images | présence exigée | pertinence exigée |
| Langue du document | exigée | exigée |
| Information portée par la seule couleur ou la mise en forme | interdite si le balisage ne la reflète pas | interdite |
| Contraste du texte | non traité (simple renvoi aux WCAG dans une note) | exigé, avec des seuils chiffrés |
| Clignotement | interdit | encadré |
| Pertinence des intitulés de liens et de titres | non traitée | exigée |
| Déclaration de la norme dans les métadonnées du fichier | exigée | sans objet |
Le tableau dit l’essentiel. Là où les deux normes se recouvrent, PDF/UA exige que l’élément existe et les WCAG qu’il serve. Là où elles divergent, c’est presque toujours sur ce qui demande un jugement : PDF/UA, qui ne traite pas la couleur, laisse passer un contraste de 2:1 que les WCAG refusent ; une alternative « image1.png » satisfait PDF/UA, puisqu’elle existe, sans rien apprendre à personne.
Ce que disent les textes
Nous avons lu les textes eux-mêmes, et non leurs résumés. Voici ce qu’ils disent des documents.
| Texte | Version des WCAG | Place de PDF/UA |
|---|---|---|
| Directive (UE) 2019/882, dite European Accessibility Act | aucune version citée par la directive elle-même | aucune |
| EN 301 549 V3.2.1, norme européenne en vigueur, clause 10 « documents non web » | WCAG 2.1, critère par critère | aucune |
| EN 301 549 V4.1.1, publiée en septembre 2026, effective une fois citée au Journal officiel | WCAG 2.2 | une note informative : PDF/UA-1 et PDF/UA-2 sont « les normes techniques des PDF accessibles » et « seraient utiles » pour satisfaire EN 301 549 |
| RGAA 4.1.2, critère 13.3 | WCAG 2.1 | aucune ; le PDF figure parmi les formats « dont la compatibilité est reconnue » |
Trois points méritent d’être soulignés.
La clause 10 d’EN 301 549 vise explicitement les documents téléchargeables. Ses exigences s’appliquent aux documents qui ne sont pas des pages web, y compris ceux qui sont fournis avec une page web sans y être intégrés : le PDF d’un relevé, d’une facture ou de conditions générales mis en téléchargement.
Aucun de ces textes n’impose PDF/UA. On lit parfois que PDF/UA serait devenu un format obligatoire en 2025 ; ce n’est pas ce que disent les textes. Le seul qui le cite, la nouvelle version d’EN 301 549 publiée en septembre 2026, le fait dans une note informative, comme un moyen utile et non comme une exigence.
La référence bouge. Le RGAA est en cours de refonte, avec une version 5 annoncée pour la fin 2026, et EN 301 549 passe aux WCAG 2.2 dans sa version 4.1.1, publiée en septembre 2026. Un programme de mise en accessibilité lancé aujourd’hui a intérêt à viser 2.2, pour ne pas reprendre ses documents dans deux ans.
Côté calendrier, la directive s’applique depuis le 28 juin 2025. Pour les services qu’elle vise, les fichiers bureautiques publiés avant cette date sont exclus de ses exigences relatives aux sites et aux applications : un document publié depuis y entre. Notre page accessibilité des documents détaille le champ de la directive, les secteurs concernés et l’articulation avec le RGAA.
Ce rappel est donné à titre d’information et ne constitue pas un conseil juridique.
Viser les deux : la structure d’abord, le jugement ensuite
En pratique, PDF/UA et les WCAG ne se traitent pas l’un après l’autre comme deux projets. Ils s’ordonnent.
D’abord la structure. Balisage, ordre de lecture, langue, en-têtes de tableaux, artefacts : tout ce que PDF/UA exige, et qu’un validateur sait en grande partie contrôler. Sans cette base, aucun critère des WCAG ne peut être satisfait dans un PDF : un lecteur d’écran ne restitue pas ce que le fichier ne déclare pas.
Ensuite le jugement. Les alternatives décrivent-elles l’image dans son contexte ? La hiérarchie des titres épouse-t-elle la logique du document ? Un tableau reste-t-il compréhensible lu cellule par cellule ? Le contraste tient-il, y compris sur les fonds de couleur de la charte ? Cette part ne s’automatise pas, et c’est elle qui fait la différence entre un document conforme et un document utilisable.
L’outillage n’est pas une alternative à l’expertise : il en est la condition. Il absorbe le volume pour que le jugement se concentre là où il est irremplaçable. Sur des documents produits en série, ce jugement s’exerce une fois, sur le modèle, et non sur chacun des documents qu’il produit.
Prouver et déclarer la conformité
Un PDF peut déclarer dans ses métadonnées qu’il revendique PDF/UA. La norme le prévoit, et précise aussitôt que cette déclaration ne suffit pas, à elle seule, à établir la conformité. Un fichier qui s’annonce PDF/UA ne l’est donc pas pour autant : c’est une revendication, pas une preuve.
Prouver la conformité demande trois pièces :
- le rapport d’un validateur, qui couvre ce qu’une machine sait trancher ;
- une revue humaine, consignée, qui couvre le reste : pertinence des alternatives, logique de la structure, contraste, compréhension ;
- pour une production de masse, la description de la méthode : jeu de données de validation du modèle, taille et règle de l’échantillon contrôlé en production, revalidation à chaque version.
C’est cet ensemble, et non une case cochée dans un logiciel d’export, qui permet de répondre à un acheteur, à un auditeur ou à un client qui demande si vos documents sont accessibles.
Questions fréquentes
Un PDF conforme PDF/UA est-il conforme aux WCAG ?
Pas nécessairement. PDF/UA garantit que le fichier est construit pour être restitué par les technologies d’assistance ; les WCAG demandent en plus que le contenu soit perceptible et compréhensible. Un PDF peut être conforme PDF/UA avec un contraste insuffisant, que la norme ne traite pas, ou avec des alternatives textuelles présentes mais vides de sens. L’inverse est également vrai : on ne satisfait pas les WCAG dans un PDF mal construit.
Faut-il viser PDF/UA et les WCAG ?
Oui. La loi exige les WCAG : c’est à elles que renvoient la norme européenne EN 301 549 et le RGAA. PDF/UA est la manière technique d’y parvenir dans un PDF. Viser PDF/UA seul produit des documents conformes mais parfois inutilisables ; viser les WCAG sans PDF/UA revient à chercher la compréhension sans la structure qui la rend possible.
Quelle version des WCAG faut-il viser ?
La version 2.1, niveau AA, est aujourd’hui la référence des textes applicables : EN 301 549 dans la version citée jusqu’ici au Journal officiel (V3.2.1) et le RGAA 4.1.2 s’y réfèrent. La nouvelle version d’EN 301 549, V4.1.1, publiée en septembre 2026, passe aux WCAG 2.2 ; elle ne vaudra présomption de conformité qu’une fois citée au Journal officiel. Viser 2.2 dès maintenant coûte peu sur des documents, les critères ajoutés portant sur l’interaction (focus, cibles, saisie, authentification), et évite de refaire le travail plus tard.
Les documents publiés avant juin 2025 sont-ils concernés ?
Pour les services visés par la directive européenne sur l’accessibilité, les fichiers bureautiques publiés avant le 28 juin 2025 sont exclus de ses exigences relatives aux sites et aux applications. A contrario, un document publié depuis cette date sur le site ou l’application d’un service visé entre dans le champ. Les organismes soumis au RGAA relèvent, eux, de règles plus anciennes et distinctes.
Comment traiter des milliers de relevés ou de factures ?
Dans le modèle qui les produit, pas fichier par fichier. Pour des documents à données variables, la structure accessible se règle une fois dans le modèle de composition, se valide sur un jeu de données qui met à l’épreuve ses cas limites, puis se contrôle en production par échantillonnage. Chaque évolution du modèle impose une nouvelle validation, comme pour son exactitude.