Accessibilité des PDF

Ces derniers mois, j’ai accompagné beaucoup d’équipes qui se sont posés la même question : « Est-ce que mes PDF sont accessibles ? ». La première fois, je ne savais pas trop comment répondre à cette question. Mais après quelques recherches, j’ai les idées plus claires, et je suis capable de répondre bien plus précisément :

1. C’est quoi un PDF accessible ?
2. Comment savoir si mon PDF est accessible ?
3. Comment faire un PDF accessible ?
4. Et maintenant ?

C’est quoi un PDF accessible ?

Un PDF accessible, c’est un peu comme un site accessible : pour être accessible, il doit être correctement balisé :

• pour être lisible par des lecteurs d’écrans (hiérarchie des titres, langue du document, ordre de lecture des éléments)
• pour être personnalisé par les personnes qui en ont besoin (contraste des couleurs, zoom élevé…)
• pour être navigable au clavier.

Cette question de balisage, AccedeWeb en parle très bien dans ses notices dédiées aux PDFs.

Mais la ressemblance avec le web s’arrête là, car il y a une grosse différence :

• Le web (en tout cas, le HTML) est une belle technologie ouverte, avec des standards communs 🥰.
• Le PDF par contre, c’est une technologie initialement propriétaire (devenue un standard plus tard), avec son écosystème fortement propriétaire 💩. Et ça change la donne. On en reparle juste après.

Comment savoir si mon PDF est accessible ?

D’un point de vue légal, le PDF a son référentiel technique (en tout cas au Luxembourg) : le RAPDF qui permet de s’assurer si oui ou non, le document est accessible. À l’international, les standards reconnus sont PDF/UA, et les WCAG bien sûr.

Bon, ceci dit, un référentiel technique et pointu, c’est chouette mais c’est un outil plutôt destiné aux professionnel de l’accessibilité. Ce n’est pas la première étape idéale pour répondre à la question « Au fait, est-ce que ce qu’on produit dans mon équipe peut être lu par des personnes handicapées ? »

C’est là que la différence avec le web se fait cruellement sentir. Pour le web, il existe de nombreux outils qui permettent aux équipes non expertes de tester automatiquement l’accessibilité d’une page, pour identifier les erreurs évidentes (Lighthouse, Wave, Axe…). Mais côté PDF, le panorama est beaucoup plus restreint.

Il existe le logiciel PAC (pour PDF Accessibility Checker). Malheureusement, il est seulement disponible pour Windows 🤪. N’ayant pas accès à ce système d’exploitation, je ne l’ai jamais testé… Mais je garde toutefois sous le coude la page PAC, comprendre et corriger les erreurs d’accessibilité. Cette page est une traduction de Tanaguru. Elle liste en français de toutes les erreurs et avertissements possibles dans PAC.

Sinon, en ligne le service axesCheck PDF permet d’avoir quelques informations (le nombre d’erreurs mais pas leur détail notamment 🤔).

Voilà, et je crois que c’est tout en terme d’outillage 🤷‍♀️.

Comment faire un PDF accessible ?

Identifier des problèmes d’accessibilité, c’est bien. Les corriger, c’est mieux. Et si déjà, côté diagnostic, le panorama était tristounet, c’est encore pire côté création de PDF, pour plusieurs raisons :

Il existe de nombreuses manières de générer des PDF :

• via des outils visuels (Canva, Figma…)
• via des exports (Word to PDF, Googles Slides to PDF…)
• de manière programmatique (PDF-Lib).

Pour chaque nouvel outil, il faut réapprendre à faire accessible. Ou plutôt : découvrir si l’outil nous permet de faire accessible.

C’est là le deuxième problème : le combo « techno proprio » + « manque de communication autour de l’accessibilité des services tiers », il est très difficile de trouver des ressources sur le sujet. Voici quelques unes de mes recherches :

• Canva permet de faire des PDF relativement accessible, à condition de bien trouver les petites options planquées un peu partout dans l’interface (configurer la langue du document, renseigner les alternatives images, utiliser des styles pour la hiérarchie des titres…). Une documentation existe, incroyable !
• Google Slides ne permet pas vraiment de générer des PDF accessible. Par exemple, l’ordre de lecture dans un lecteur d’écran correspond à l’ordre de « tri » (arrière/avant plan). Hors, aucune interface ne permet de visualiser (ou corriger) cet ordre facilement. D’ailleurs, même leur documentation conseille de « publier sur le web ».
• PDF-Lib est une librairie permettant de créer et modifier des documents en Javascript. Certaines méthodes permettent de baliser le document (par exemple setLanguage permet de renseigner la langue dans laquelle le document devrait être vocalisé). Mais l’API d’images ne semble pas permettre de renseigner des alternatives…

Et maintenant ?

Je n’ai pas connaissance de chiffres sur l’accessibilité des PDFs en France, mais je pense qu’ils sont majoritairement inaccessibles (côté service public du Luxembourg, c’est 59 % des PDFs qui ne sont pas balisés). Ce qui est malheureusement peu étonnant puisque :

L’accessibilité est peu enseignée. L’accessibilité des PDFs encore moins. Les rares formations disponibles sont exclusivement orientée « fabrication artisanale » (via InDesign ou Acrobat Pro). Ce qui ne correspond pas du tout à la réalité des équipes que j’accompagne.

Les outils qui nous permettent de générer des PDFs ne sont pas vraiment prévus pour faire accessible. Réussir à faire accessible demande beaucoup de pugnacité (il va falloir faire des recherches, tester et bidouiller) pour finalement tomber de haut (et découvrir que l’outil n’a rien prévu pour tel ou tel élément…).

Bref, voilà voilà. Si vous vous lancez dans les PDFs accessible, bon chance, comme on dit. Ou bien proposez une alternative en HTML sémantique. C’est bien le HTML sémantique 🥰.