PDF accessibles : l’essentiel et quand préférer le HTML

Quand un PDF devient un obstacle

Un PDF peut sembler parfait et être pourtant inutilisable. Un lecteur d’écran ne voit pas la mise en page. Il a besoin de structure : quel texte est un titre, lequel est une liste, lequel est un tableau, et dans quel ordre tout est lu. Si ces informations manquent, le contenu sort comme un long flux de texte, dans le mauvais ordre, ou pas du tout.

Problèmes typiques : une page scannée qui n’est qu’une image, une mise en page sur deux colonnes lue en travers des deux colonnes, un tableau sans cellules d’en-tête, un formulaire dont les champs n’ont pas de nom, et des images sans alternative textuelle. Le W3C décrit comment éviter chacun de ces problèmes dans ses techniques PDF pour les WCAG. Ces techniques sont des exemples de manières de satisfaire aux WCAG, pas une exigence en soi.

Ce qui rend un PDF accessible

• Balises : un PDF balisé possède une arborescence de structure dans laquelle les titres, les paragraphes, les listes et les tableaux sont marqués comme tels. Sans balises, les technologies d’assistance n’ont presque rien sur quoi s’appuyer.
• Ordre de lecture : l’ordre des balises décide de ce qui est lu en premier. Vérifie-le surtout pour les colonnes, les zones de texte et les encadrés. L’ordre de tabulation des liens et des champs de formulaire doit suivre la même logique.
• Titre du document : définis un titre parlant dans les propriétés du document et fais en sorte que la visionneuse l’affiche à la place du nom de fichier.
• Langue du document : définis la langue principale, pour qu’un lecteur d’écran utilise la bonne prononciation. Marque séparément les passages dans une autre langue.
• Texte alternatif des figures : les images informatives reçoivent une alternative textuelle sur leur balise de figure. Les images purement décoratives sont marquées comme artefacts, pour que les lecteurs d’écran les ignorent.
• Du vrai texte plutôt que des scans : une page scannée est une image de texte. Crée le PDF à partir du fichier source quand tu le peux. S’il n’y en a pas, la reconnaissance de texte (OCR) transforme le scan en vrai texte. Vérifie ensuite que tout le texte est là et dans le bon ordre.
• En-têtes de tableau : les tableaux de données sont construits à partir de cellules de tableau, de ligne, d’en-tête et de données. Les cellules d’en-tête doivent être marquées comme en-têtes, pas seulement affichées en gras.
• Signets : les documents de plus de quelques pages reçoivent des signets, idéalement créés à partir des titres. Ils aident tout le monde à avoir une vue d’ensemble sans feuilleter tout le fichier.
• Champs de formulaire : chaque champ a un nom qui lui est lié par programmation, par exemple via l’info-bulle du champ. Une étiquette simplement imprimée à côté du champ ne suffit pas.

Ce qu’un contrôle automatique trouve, et ce qu’il ne trouve pas

Un outil peut lire des propriétés techniques : y a-t-il un titre, une langue, une arborescence de structure, les figures ont-elles une entrée alt ? Ce sont de bonnes premières questions, et une réponse manquante est un constat clair.

Un outil ne peut pas juger si un texte alternatif dit la bonne chose, si l’ordre de lecture a du sens, si les bonnes cellules sont marquées comme en-têtes, ni si la reconnaissance de texte a bien lu chaque chiffre. Le W3C le dit clairement : les outils d’évaluation ne peuvent pas déterminer l’accessibilité, ils peuvent seulement aider, et le jugement humain est nécessaire. Quatre contrôles manuels ne prennent que quelques minutes :

1. 1Ouvre le PDF. La fenêtre affiche-t-elle un vrai titre au lieu du nom de fichier ?
2. 2Écoute les premières pages avec un lecteur d’écran ou une fonction de lecture à voix haute. Les titres, les colonnes et les tableaux sont-ils lus dans un ordre logique ?
3. 3Enregistre le PDF en texte. Tout le texte est-il là, dans le bon ordre, et les chiffres sont-ils corrects ?
4. 4Parcours les liens et les champs de formulaire avec la touche Tab. L’ordre a-t-il du sens, et chaque champ annonce-t-il son nom ?

Quand une page HTML est le meilleur choix

Demande-toi ce que les visiteurs veulent faire du contenu. Les horaires d’ouverture, les menus, les listes de prix, les instructions courtes et tout ce qui change souvent fonctionnent en général mieux comme page web normale. Une page s’adapte aux petits écrans et au zoom, peut être trouvée et liée directement, et il n’y a qu’une seule version à tenir à jour.

Un PDF reste pertinent pour les documents que les gens impriment, signent ou classent, ou qui doivent garder une mise en page fixe. Si tu gardes le PDF, propose aussi le contenu essentiel sous forme de page web, ou assure-toi au moins que le PDF est balisé et vérifié.

Travailler avec Do4U

L’outil Vérifier l’accessibilité du PDF lit un PDF de 2 Mo maximum et indique le titre, la langue, les balises de structure et les figures sans alternative. L’ordre de lecture est toujours signalé pour un contrôle manuel, car un outil ne peut pas en juger.

Convertir des documents en HTML crée un brouillon à partir d’une page PDF ou d’une image à la fois : du HTML sémantique avec titres, listes et tableaux, plus du texte brut. Compare chaque mot, chaque chiffre et chaque tableau avec l’original, et répète l’opération pour chaque page dans l’ordre de lecture.

Les deux outils te donnent des constats et des brouillons. Ils ne remplacent pas une relecture par des personnes, idéalement avec quelqu’un qui utilise un lecteur d’écran. Vérifie à nouveau après chaque nouvelle version du document.