Ce qui rend un PDF accessible

Ce que sont les balises

Visuellement, une page de PDF est un ensemble d’instructions de dessin : place ces glyphes à ces coordonnées. Rien là-dedans ne dit quels glyphes forment un titre, ni lesquels appartiennent au même paragraphe, ni que ces douze suites de texte sont les cellules d’un tableau. Un lecteur voyant déduit tout cela de la taille, de la graisse et de la position. Un logiciel ne le peut pas.

Un PDF balisé ajoute un arbre de structure parallèle — titres, paragraphes, listes, tableaux, figures — assez semblable à la structure d’un document HTML. Grâce à lui, une technologie d’assistance peut annoncer « titre de niveau 2 », permettre de sauter d’une section à l’autre, lire un tableau par ligne et par colonne, et lire le texte alternatif d’une figure. Sans lui, le même logiciel se rabat sur des suppositions tirées de la mise en page, et il suppose mal dès que la page n’est plus une simple colonne unique.

La couche de balises porte trois autres choses, qui comptent toutes et dont aucune n’est visible :

• L’ordre de lecture, qui n’est pas l’ordre dans lequel les éléments ont été dessinés. Une mise en page sur deux colonnes dessinée colonne par colonne se lit correctement ; dessinée ligne par ligne à travers les deux colonnes, elle se lit comme du charabia, et elle a exactement la même apparence.
• Le texte alternatif des images, sans lequel une figure est annoncée comme « graphique » et rien de plus.
• La langue du document, qui indique au lecteur d’écran quelles règles de prononciation employer. Un document français lu avec les règles de l’anglais est quasiment incompréhensible.

Pourquoi l’OCR n’est pas l’accessibilité

C’est le malentendu le plus fréquent et le plus coûteux, il vaut donc la peine d’être direct à son sujet.

Passer un document scanné à l’OCR ajoute une couche de texte reconnu derrière l’image. Le document devient consultable, le texte devient sélectionnable, et un lecteur d’écran lira désormais quelque chose plutôt que rien. C’est une amélioration réelle et importante, et ce n’est pas de l’accessibilité.

Ce que produit l’OCR, c’est un flux de mots indifférencié. Il ne sait pas qu’une ligne était un titre ; il produit une ligne de texte. Il ne sait pas qu’un tableau est un tableau ; il produit le contenu des cellules dans l’ordre où il les a balayées, ce qui, pour un tableau, est fréquemment le mauvais ordre, et il l’annonce sans la moindre indication de la colonne à laquelle appartient un nombre. Il ne peut pas rédiger le texte alternatif d’une photographie, parce qu’il ne sait pas ce que la photographie représente.

Donc : l’OCR est la première étape nécessaire pour un scan, et une fois effectuée, le document n’a toujours aucune des structures qui le rendent utilisable. Prendre « nous avons passé l’OCR dessus » pour « nous l’avons rendu accessible » est la façon dont des organisations en viennent à croire qu’un fonds documentaire est conforme alors qu’il ne l’est pas.

Vérifier honnêtement un document

Une partie de tout cela se vérifie rapidement, et cela vaut la peine de le faire avant de supposer qu’un fichier va bien.

• Y a-t-il seulement du texte ? Essayez de sélectionner une phrase. Si rien ne se sélectionne, la page est une image et doit passer par l’OCR avant toute autre chose. Extraire le texte d’un PDF répond à la même question — un résultat vide signifie qu’il n’y a pas de couche de texte.
• L’ordre de lecture est-il correct ? Sélectionnez tout le texte d’une page complexe et collez-le dans un éditeur de texte brut. Ce que vous obtenez est proche de l’ordre qu’utilisera un lecteur d’écran. Si une page sur deux colonnes ressort entrelacée, l’ordre de lecture est faux, quelle que soit son apparence.
• Le document est-il balisé ? Les lecteurs de bureau l’indiquent dans les propriétés du document, généralement sous la forme « PDF balisé : Oui/Non ». Un « Non » est sans appel ; un « Oui » signifie seulement que des balises existent, pas qu’elles sont correctes.
• La langue est-elle définie ? L’éditeur de métadonnées montre les propriétés au niveau du document enregistrées dans le fichier.

Les vérificateurs automatiques sont utiles et limités d’une manière précise : ils vérifient que les structures sont présentes et bien formées, pas qu’elles sont justes. Un vérificateur ne peut pas vous dire qu’un titre a été balisé comme un paragraphe, ni que le texte alternatif d’une photographie dit « image1.jpg ». Cela demande une personne.

Ce que les outils de navigateur peuvent et ne peuvent pas y faire

Soyons clairs sur les limites : iBuildPDF ne rend pas les PDF accessibles, et aucun outil qui se contente de modifier un fichier existant ne le peut vraiment. L’accessibilité se joue en grande partie là où le document est rédigé — un style de titre appliqué dans un traitement de texte devient une balise de titre à l’export ; du texte saisi dans une zone de texte devient un fragment non balisé. Exporter correctement depuis la source vaut plus que tout ce qui peut être fait après coup.

Ce que les outils proposés ici peuvent faire, c’est le travail préparatoire et le diagnostic :

• L’OCR donne à un scan une couche de texte, qui est le prérequis de tout le reste.
• L’extraction de texte vous montre ce qu’une machine voit réellement, y compris l’ordre de lecture.
• PDF en Word transfère un document dans un éditeur où les titres, les textes alternatifs et la structure des tableaux peuvent être appliqués correctement, puis réexportés.
• L’éditeur de métadonnées expose les propriétés au niveau du document, dont le titre que la technologie d’assistance annonce en premier.

Deux opérations dégradent activement l’accessibilité, et toutes deux se pratiquent parfois pour de bonnes raisons : convertir les pages en images détruit entièrement la couche de texte, et l’aplatissement supprime la structure interactive des champs de formulaire. Ni l’une ni l’autre n’est mauvaise en soi, mais aucune ne devrait être appliquée à un document que quelqu’un doit lire avec une technologie d’assistance.

Si un document est soumis à une exigence légale ou contractuelle d’accessibilité, les normes de référence sont le PDF/UA (ISO 14289) et les techniques PDF publiées aux côtés des WCAG, toutes deux référencées ci-dessous.