AccueilDocuments PDF accessibles

Guide pratique · Documents & PDF

Documents PDF accessibles : factures, CGV et notices

Mis à jour le 15 juin 2026 Lecture : 11 min Référence : EAA · WCAG 2.1 AA · PDF/UA

En bref — un PDF aussi doit être accessible

Beaucoup l'oublient : l'European Accessibility Act ne s'arrête pas à vos pages web. Les documents qui font partie du service — facture, reçu, conditions générales, bon de livraison, fiche technique, notice — doivent aussi être accessibles. La norme EN 301 549 étend les mêmes exigences WCAG aux documents non-web (son chapitre 10), et le standard PDF/UA (ISO 14289) précise comment faire un PDF accessible. L'essentiel :

  • PDF balisé (tagged PDF) : une structure lisible par un lecteur d'écran, comme un HTML sémantique (critère 1.3.1) ;
  • Du vrai texte, sélectionnable — pas une simple image scannée (critère 1.4.5) ;
  • Un ordre de lecture logique, indépendant de la mise en page visuelle (critère 1.3.2) ;
  • Un texte alternatif pour logos, schémas et images porteurs d'information (critère 1.1.1) ;
  • Un titre, une langue et des métadonnées renseignés dans les propriétés du document (critères 2.4.2 et 3.1.1) ;
  • Tableaux, listes et contraste correctement balisés et lisibles (critères 1.3.1 et 1.4.3).

Bon réflexe : quand c'est possible, proposez l'information en page web accessible plutôt qu'en PDF — c'est presque toujours plus simple à rendre conforme.

On pense « site web » quand on parle d'accessibilité, et on oublie le PDF qui se télécharge à la fin de la commande. Pourtant une facture illisible par un lecteur d'écran, des conditions générales qu'on ne peut pas parcourir, une notice scannée en image : ce sont des barrières au même titre qu'un bouton sans libellé. L'EAA traite ces documents comme une partie du service de commerce électronique. Voici comment savoir lesquels sont concernés, les six règles d'un PDF accessible, et la solution souvent plus simple que le PDF.

Pourquoi vos documents sont concernés

L'EAA s'applique aux services de commerce électronique destinés aux consommateurs depuis le 28 juin 2025. La référence technique, l'EN 301 549, ne couvre pas seulement les pages web : son chapitre 10 « documents non-web » applique les mêmes critères WCAG aux fichiers que vous fournissez — typiquement des PDF. Un document fait partie du service dès lors qu'il est nécessaire pour acheter, recevoir ou utiliser ce que vous vendez : facture et reçu, conditions générales de vente, informations de livraison et de rétractation, fiche produit ou notice d'utilisation téléchargeable.

Tous vos PDF ne sont pas au même niveau de priorité. Un document transactionnel (facture, CGV) est clairement dans le périmètre ; une vieille brochure marketing l'est moins, mais elle suit les mêmes bonnes pratiques. Le standard de référence pour un PDF accessible est PDF/UA (ISO 14289) : il décline les principes WCAG aux spécificités du format PDF. Les six règles ci-dessous en sont le cœur.

Les 6 règles d'un PDF accessible

1 Un PDF balisé (tagged PDF)

Une structure lisible par les technologies d'assistance

Un PDF accessible est balisé : il contient une arborescence de balises (titres, paragraphes, listes, tableaux) qui dit à un lecteur d'écran ce qu'est chaque élément, exactement comme un HTML sémantique. Sans ces balises, le lecteur d'écran ne voit qu'un mur de texte sans hiérarchie, ou rien du tout. C'est la condition de base : titres balisés en vrais titres, paragraphes en paragraphes, listes en listes. La plupart des outils bureautiques (traitement de texte, mise en page) savent exporter un PDF balisé — encore faut-il activer l'option et vérifier le résultat.

Conforme — une facture exportée avec ses balises : en-têtes, lignes d'articles et total sont identifiés comme tels et annoncés dans l'ordre.
À éviter — un PDF « à plat » sans aucune balise, où le lecteur d'écran lit les chiffres pêle-mêle, sans rapport entre libellé et montant.
WCAG 1.3.1 (A)
2 Du vrai texte, pas une image

Le contenu doit être sélectionnable et recherchable

Un PDF qui n'est qu'un scan ou une image exportée est invisible pour un lecteur d'écran et impossible à agrandir sans pixelliser. Le texte doit être du vrai texte : sélectionnable à la souris, recherchable (Ctrl+F), copiable. Test immédiat : si vous ne pouvez pas surligner un mot du document, c'est une image. Pour un document scanné (un contrat signé, par exemple), passez-le à la reconnaissance de caractères (OCR) pour y ajouter une couche de texte. Le critère 1.4.5 demande d'éviter les images de texte chaque fois que le vrai texte peut faire le travail.

Conforme — une CGV dont chaque mot se surligne et se recherche ; un document scanné repassé en OCR avec couche texte.
À éviter — une facture « imprimée puis scannée » livrée comme image, sans aucune couche de texte.
WCAG 1.4.5 (AA)
3 Un ordre de lecture logique

Le contenu s'annonce dans l'ordre où on le comprend

La mise en page visuelle (colonnes, encadrés, en-têtes) ne dit pas au lecteur d'écran dans quel ordre lire. L'ordre de lecture balisé doit suivre la logique du document : titre, puis corps, puis pied de page — et non sauter d'une colonne à l'autre au hasard. Le critère 1.3.2 exige que la séquence de lecture soit correcte quand l'ordre a un sens. Sur une facture multi-colonnes ou un document à blocs, c'est le point qui casse le plus souvent : vérifiez l'ordre des balises après export.

Conforme — sur un reçu en deux colonnes, le lecteur d'écran lit d'abord les coordonnées, puis le détail des articles, puis le total, dans un ordre cohérent.
À éviter — un document où le lecteur d'écran mélange l'en-tête, le filigrane et le tableau, rendant le sens incompréhensible.
WCAG 1.3.2 (A)
4 Un texte alternatif des éléments visuels

Logos, schémas et images porteurs de sens sont décrits

Comme sur le web, toute image qui porte de l'information dans le document a besoin d'un texte alternatif : logo de l'entreprise, schéma de montage d'une notice, graphique, tampon ou cachet. Les éléments purement décoratifs (filet, motif de fond) doivent au contraire être marqués comme artéfacts pour que le lecteur d'écran les ignore. Le critère 1.1.1 s'applique aux documents exactement comme aux pages web.

Conforme — dans une notice, chaque schéma porte une alternative qui décrit le geste ; le motif de fond est marqué comme décoratif.
À éviter — une fiche technique où un graphique clé n'a aucune description, et où le logo est lu « image1.png ».
WCAG 1.1.1 (A)
5 Un titre, une langue et des signets

Les propriétés du document sont renseignées

Trois réglages dans les propriétés du PDF font une grande différence : un titre de document explicite (qui s'affiche dans l'onglet et que le lecteur d'écran annonce, critère 2.4.2) ; la langue du document déclarée (fr) pour que la synthèse vocale prononce correctement (critère 3.1.1) ; et, pour les documents longs (CGV, catalogue), des signets qui servent de sommaire navigable (critère 2.4.5, plusieurs moyens d'accès). Réglages rapides, souvent oubliés à l'export.

Conforme — propriétés du PDF : titre « Facture n°2026-0042 — Boutique X », langue « français », signets sur chaque article des CGV.
À éviter — un PDF dont le titre est le nom de fichier « doc_final_v3.pdf » et dont la langue n'est pas déclarée.
WCAG 2.4.2 (A) · 3.1.1 (A) · 2.4.5 (AA)
6 Tableaux, listes et contraste

Les structures de données et la lisibilité sont soignées

Une facture est avant tout un tableau : il doit être balisé comme un vrai tableau avec ses cellules d'en-tête (article, quantité, prix), pour que le lecteur d'écran relie chaque montant à sa colonne. Les énumérations doivent être de vraies listes, pas des tirets manuels. Enfin, le contraste du texte s'applique aussi dans un PDF (critère 1.4.3, 4,5:1 pour le texte courant) : attention au gris pâle des mentions légales et aux montants en couleur claire. Ne transmettez jamais une information par la couleur seule (critère 1.4.1).

Conforme — un tableau de facture avec en-têtes de colonnes balisés, des listes réelles, et un texte à contraste suffisant y compris les mentions du bas.
À éviter — un tableau « dessiné » avec des espaces et des tabulations, et des mentions légales en gris très clair illisibles.
WCAG 1.3.1 (A) · 1.4.3 (AA) · 1.4.1 (A)

Ce qui s'applique selon le document

Priorité indicative pour un e-commerce. Tous ces critères sont de niveau A ou AA des WCAG 2.1, étendus aux documents par le chapitre 10 de l'EN 301 549.
Type de documentPrioritéPoints clés
Facture / reçuÉlevéeBalisage + tableau à en-têtes + vrai texte + ordre de lecture
Conditions générales (CGV/CGU)ÉlevéeBalisage + titres + signets + langue
Fiche produit / notice téléchargeableÉlevéeBalisage + alternatives des schémas + ordre de lecture
Bon de livraison / rétractationMoyenneBalisage + vrai texte + titre du document
Document scanné (contrat signé)MoyenneOCR pour ajouter une couche de vrai texte
Brochure / catalogue marketingPlus faibleMêmes bonnes pratiques ; envisager une version web
La solution souvent plus simple : avant de rendre un PDF accessible, demandez-vous s'il a besoin d'être un PDF. Pour une facture, des CGV ou une fiche produit, une page web accessible (ou une facture HTML) est presque toujours plus facile à rendre conforme, plus légère sur mobile et plus simple à mettre à jour. Réservez le PDF aux cas où le format figé est vraiment nécessaire — et balisez-le.
Un overlay « accessibilité » posé sur votre site ne touche pas vos fichiers : il ne balise pas un PDF, n'ajoute pas de couche OCR et ne corrige pas l'ordre de lecture d'un document — ce sont des propriétés du fichier lui-même. Rappel : la FTC américaine a sanctionné un éditeur d'overlay d'un million de dollars pour des allégations de conformité trompeuses. Voir pourquoi les overlays ne suffisent pas.

Comment vérifier un PDF

Quelques contrôles simples repèrent l'essentiel, sans outil payant :

  • Surlignez du texte : si rien ne se sélectionne, c'est une image — il manque le vrai texte (et probablement le balisage).
  • Ouvrez les propriétés du document : le titre est-il explicite ? La langue est-elle renseignée ?
  • Cherchez le panneau « balises » dans votre lecteur PDF : existe-t-il une arborescence de titres, listes et tableaux ?
  • Lancez le vérificateur d'accessibilité intégré à votre outil de création PDF (la plupart en proposent un), ou un vérificateur PDF/UA gratuit comme PAC.
  • Écoutez-le avec un lecteur d'écran (NVDA, VoiceOver) : l'ordre et le sens tiennent-ils ?

→ Méthode générale : comment tester l'accessibilité de son site. Pour une vue d'ensemble des points à couvrir, voir la checklist de conformité EAA.

Vérifiez l'accessibilité de votre boutique gratuitement

DeclareAccess analyse une page de votre site avec le moteur axe-core selon les WCAG 2.1 AA, repère les manquements (structure, contraste, clavier, formulaires…) et génère la déclaration d'accessibilité prête à publier — modèle français (RGAA), allemand (BFSG), italien ou espagnol. Gratuit, sans carte bancaire.

Rapport WCAG par e-mail sous 24 h ouvrées.

C'est noté. Votre client e-mail va s'ouvrir avec la demande pré-remplie — il vous suffit de l'envoyer.

Questions fréquentes

Mes factures PDF générées automatiquement sont-elles concernées ?

Oui, la facture fait partie du service. Le point pratique : ces PDF sont produits par votre plateforme ou votre module de facturation, pas à la main. Vérifiez donc ce que votre générateur produit : un PDF balisé avec du vrai texte, ou une image à plat ? Beaucoup de modules sortent un PDF non balisé par défaut. Deux pistes : activer l'option « PDF accessible / balisé » si elle existe, ou proposer la facture aussi en page web / HTML accessible, souvent plus simple à corriger côté boutique.

Un PDF scanné ou signé peut-il être accessible ?

Pas en l'état : un scan est une image, donc invisible pour un lecteur d'écran. Pour le rendre accessible, passez-le à la reconnaissance de caractères (OCR) afin d'ajouter une couche de vrai texte, puis vérifiez le balisage et l'ordre de lecture. Pour les documents à signer, privilégiez quand c'est possible un formulaire ou un document nativement numérique (texte réel) plutôt qu'un aller-retour « imprimer / signer / scanner » qui détruit l'accessibilité.

Dois-je convertir tous mes PDF en pages web ?

Non, ce n'est pas une obligation : un PDF correctement balisé et conforme PDF/UA est accessible. Mais en pratique, pour un contenu transactionnel (facture, CGV, fiche produit), une page web accessible est souvent plus simple à rendre et à maintenir conforme qu'un PDF, et plus confortable sur mobile. C'est un choix de priorité : là où vous le pouvez facilement, préférez le web ; là où le PDF s'impose, balisez-le.

Word ou Google Docs exportent-ils des PDF accessibles ?

Ils le peuvent, mais pas automatiquement à coup sûr. Si le document source est bien structuré (vrais styles de titres, vraies listes, vrais tableaux, alternatives sur les images) et que vous exportez en cochant l'option « PDF accessible / balisé », le résultat est généralement balisé. Un document mal structuré au départ (titres en gros gras, tableaux faits d'espaces) produira un PDF inaccessible quel que soit l'outil. La règle : l'accessibilité se gagne dans le document source, puis se vérifie après export.

Comment savoir rapidement si un PDF est accessible ?

Trois tests en moins d'une minute : (1) essayez de surligner un mot — si c'est impossible, c'est une image ; (2) ouvrez les propriétés et regardez si un titre et une langue sont renseignés ; (3) cherchez le panneau des balises. Pour un diagnostic complet, lancez le vérificateur d'accessibilité de votre outil PDF ou un contrôleur PDF/UA gratuit comme PAC, et écoutez le document avec un lecteur d'écran.