Chapitre 12.4 — Documents accessibles (PDF, Office)

⏱️ TL;DR — Sur une plateforme de formation, une grande part du contenu arrive sous forme de documents déposés : PDF, Word, PowerPoint. Un PDF n’est accessible que s’il est balisé (tagué) : structure de titres, ordre de lecture, alternatives d’images, langue. Un PDF scanné (une image de page) est totalement inaccessible sans OCR. La règle d’or : privilégier le HTML natif quand c’est possible, et quand un document est nécessaire, le produire accessible dès la source (Word/PowerPoint) plutôt que de « réparer » un PDF après coup.

🎯 Objectifs

Comprendre ce qui rend un PDF accessible (ou non).
Distinguer un PDF balisé d’un PDF scanné.
Produire des documents Office accessibles à la source.
Savoir quand préférer le HTML au document téléchargeable.

Pourquoi les documents sont un angle mort

Une plateforme peut être parfaitement accessible et servir des cours inaccessibles parce que le formateur y a déposé un PDF illisible pour un lecteur d’écran. C’est la couche « documents » du modèle en trois couches vu en 12.1. Et c’est souvent la plus négligée, car les auteurs ne savent pas qu’un document a des exigences d’accessibilité propres.

Le PDF : balisé vs scanné

Un PDF accessible est un PDF balisé (tagged), qui expose une structure comparable à du HTML :

une hiérarchie de titres (pour naviguer) ;
un ordre de lecture correct (l’ordre visuel ne suffit pas) ;
des alternatives textuelles pour les images ;
la langue du document déclarée ;
des tableaux avec en-têtes, des liens explicites.

La norme dédiée est PDF/UA (Universal Accessibility). À l’opposé, un PDF scanné — une photo ou un scan de page — n’est qu’une image : aucun texte réel, donc rien à lire pour un lecteur d’écran. Il faut lui appliquer une reconnaissance de caractères (OCR) puis le baliser, ce qui est fastidieux.

⚠️ Piège — Le PDF scanné. C’est le cas le plus fréquent et le pire : un support de cours photocopié puis scanné en PDF est un mur infranchissable pour une personne aveugle (et souvent illisible au zoom pour un malvoyant). Si tu ne devais retenir qu’une chose de ce chapitre : jamais de document scanné sans le passer par OCR et vérification.

Produire des documents Office accessibles

Le meilleur moment pour rendre un document accessible, c’est à sa création, dans Word ou PowerPoint — pas après export en PDF. Les bons réflexes, qui recoupent tout le cours :

Utiliser les styles de titres intégrés (Titre 1, Titre 2…) et non du texte agrandi en gras — c’est ce qui crée la structure navigable.
Renseigner le texte alternatif des images (menu dédié).
Écrire des intitulés de liens explicites (pas « cliquez ici »).
Vérifier le contraste et ne pas coder l’info par la seule couleur.
Utiliser de vrais tableaux avec ligne d’en-tête, pas des colonnes faites à la tabulation.
Lancer le vérificateur d’accessibilité intégré (Word et PowerPoint en ont un, comme Moodle).

À l’export en PDF, choisir l’option qui conserve les balises (« PDF accessible / balisé »). Un PDF exporté depuis un Word bien structuré est presque accessible d’emblée.

💡 Réflexe — L’accessibilité d’un document se décide à la source. Structurer un Word avec de vrais styles de titres coûte quelques secondes ; rebaliser un PDF mal exporté coûte des heures. Forme les auteurs à produire propre en amont — c’est le même principe de shift-left que pour le code (1.5).

Quand préférer le HTML

Souvent, la meilleure décision d’accessibilité est de ne pas produire de document : une page HTML native (une leçon dans l’éditeur Moodle, un article) est par défaut plus accessible, plus facile à zoomer, à lire au lecteur d’écran et sur mobile qu’un PDF. Réserve le PDF aux cas où le format figé est vraiment nécessaire (document à imprimer, attestation officielle). Pour un contenu de cours, le HTML d’abord.

🧭 Sur A11yLearn — Sur A11yLearn, les supports de cours étaient distribués en PDF. On bascule le contenu pédagogique en pages HTML dans la plateforme (accessibles, responsives, indexables), et on ne garde en PDF que l’attestation de fin de formation — elle-même générée balisée, avec la langue et un titre corrects.

✏️ Exercices

Exercice 1 — Diagnostique le document. Un formateur dépose un support en « PDF ». Quelles questions poses-tu pour savoir s’il est accessible ?

✅ Solution

Est-il balisé (tagué) ou scanné (image) ? On peut vite le tester : essayer de sélectionner le texte — si c’est impossible, c’est un scan, donc inaccessible. Ensuite : a-t-il une structure de titres, un ordre de lecture correct, des alternatives d’images, une langue déclarée ? En pratique, on remonte à la source : de quel Word/PowerPoint vient-il, et a-t-il été structuré avec de vrais styles de titres ?

Exercice 2 — HTML ou PDF ? Un cours de 20 pages doit être publié sur la plateforme. Que recommandes-tu ?

✅ Solution

Le HTML (pages de leçon dans le LMS) : par défaut plus accessible, plus lisible au zoom et au lecteur d’écran, responsive sur mobile, et indexable. Le PDF n’apporte ici que des inconvénients (téléchargement, format figé, risque de mauvais balisage). On réserve le PDF aux documents qui doivent être figés/imprimés — et on les produit balisés.

🧠 Quiz de révision

1. Qu’est-ce qui rend un PDF accessible ?

Le balisage (PDF tagué) : hiérarchie de titres, ordre de lecture correct, alternatives d’images, langue déclarée, tableaux avec en-têtes. La norme dédiée est PDF/UA. Un PDF sans balises est difficilement exploitable par un lecteur d’écran.

2. Pourquoi un PDF scanné est-il inaccessible ?

Parce que c’est une image de page : il ne contient aucun texte réel, donc rien à lire pour un lecteur d’écran ni à agrandir proprement. Il faut lui appliquer un OCR puis le baliser pour le rendre exploitable.

3. Où se joue surtout l’accessibilité d’un document Office ?

À la source, lors de sa création : styles de titres réels, textes alternatifs, liens explicites, vrais tableaux, vérificateur d’accessibilité, puis export en PDF balisé. Corriger après export coûte beaucoup plus cher.

4. Comment tester rapidement si un PDF a du vrai texte ?

Essayer de sélectionner le texte avec la souris. Si c’est impossible (rien ne se surligne), c’est un scan/image, donc inaccessible sans OCR.

5. Pour un contenu de cours, quel format privilégier ?

Le HTML natif (page dans le LMS) : plus accessible par défaut, zoomable, lisible au lecteur d’écran et sur mobile, responsive. On réserve le PDF aux documents qui doivent être figés ou imprimés, et on les produit balisés.

Chapitre suivant : Média pédagogique — sous-titrer et rendre accessibles vidéos, diapositives et contenus interactifs.