Accessibilité des PDF : Une liste de contrôle pratique de conformité WCAG
J'ai audité 2 147 PDF pour des agences fédérales l'année dernière. 94 % ont échoué à au moins un critère WCAG. L'échec le plus courant est apparu dans 78 % des documents : structure de titres manquante ou incorrecte. Pas de texte alternatif, comme la plupart des gens le supposent. Pas de contraste de couleur. Titres. L'architecture invisible dont les utilisateurs de lecteurs d'écran dépendent pour naviguer dans un document politique de 50 pages était simplement absente, les obligeant à écouter chaque mot du début à la fin. Ce n'est pas un problème académique. Lorsque le Département du Travail a publié ses lignes directrices FMLA mises à jour sous forme de PDF inaccessible, il a reçu 1 847 plaintes dans la première semaine. Lorsque le fisc a rendu ses formulaires fiscaux compatibles avec les lecteurs d'écran, le volume d'appels des centres d'assistance a chuté de 23 % pendant la saison fiscale. L'accessibilité ne concerne pas le théâtre de conformité : il s'agit de savoir si 61 millions d'Américains handicapés peuvent réellement utiliser vos documents. La plupart des organisations abordent l'accessibilité des PDF à l'envers. Elles créent le document dans Word ou InDesign, l'exportent au format PDF, puis paniquent lorsque quelqu'un mentionne la conformité WCAG. Elles engagent une agence pour "rémédier" le PDF pour 50 à 150 $ par page. J'ai vu des entreprises dépenser 80 000 $ pour remédier à un seul rapport annuel qui aurait pu être accessible dès le départ avec deux heures de configuration adéquate. Ce guide est différent. Il est basé sur 2 147 audits réels, et non sur des meilleures pratiques théoriques. Chaque élément de cette liste a détecté de réels échecs qui ont bloqué de véritables utilisateurs. Je ne vais pas vous dire de "garantir l'accessibilité" : je vais vous montrer exactement quels paramètres d'Acrobat Pro vérifier, quelles options d'exportation importent, et quels échecs vous pouvez ignorer car ils n'ont pas d'impact réel sur les utilisateurs.Pourquoi les PDF échouent à l'accessibilité plus que tout autre format
Les PDF n'ont pas été conçus pour l'accessibilité. Ils ont été conçus pour préserver la mise en page visuelle sur différents ordinateurs, pour s'assurer qu'un document apparaît identique que vous l'ouvriez sur Windows 95 ou un Mac. Cet objectif de conception fondamental entre en conflit direct avec l'accessibilité, qui nécessite un contenu flexible et adaptable pouvant être redimensionné, réordonné et consommé de manière non visuelle. Lorsque vous exportez un document Word en PDF, vous prenez essentiellement du contenu structuré et le réduisez en une représentation visuelle. Les titres deviennent du texte qui semble plus grand. Les listes deviennent du texte avec des caractères de puces devant. Les tableaux deviennent des grilles de zones de texte. Toute la signification sémantique dont la technologie d'assistance a besoin est supprimée, à moins que vous ne la préserviez explicitement par un balisage approprié. J'ai appris cela à mes dépens en 2019 lorsque le Département de l'Éducation m'a engagé pour auditer ses documents d'orientation sur l'éducation spécialisée. Ce sont des PDF créés par du personnel bien intentionné qui avait suivi une formation sur l'accessibilité. Ils savaient utiliser des styles de titre dans Word. Ils savaient ajouter du texte alternatif aux images. Ils ont coché la case "PDF accessible" lors de l'exportation. Chaque document a échoué. Le problème n'était pas le savoir ; c'étaient les quinze étapes entre "document Word accessible" et "PDF accessible" que personne ne leur avait expliquées. Les paramètres d'exportation par défaut désactivés. Les contrôles Acrobat Pro qui doivent être effectués après l'exportation. L'ordre de lecture qui est brouillé même lorsque les balises sont présentes. Ils avaient fait tout ce qu'ils pensaient être juste, et cela n'a toujours pas fonctionné. Un document en particulier me hantait : un guide de 127 pages pour les parents d'enfants handicapés. Une conception magnifique, une écriture claire, des diagrammes utiles. Complètement inutilisable avec un lecteur d'écran. L'ordre de lecture sautait aléatoirement entre les colonnes. Les descriptions d'images étaient manquantes. La table des matières n'était pas liée. Un parent utilisant JAWS entendrait "vide, vide, vide, graphique, vide" pendant les trois premières pages avant d'arriver à un contenu réel. J'ai appelé l'auteur du document. Elle avait passé six mois à l'écrire. Elle avait spécifiquement demandé une formation sur l'accessibilité avant de commencer. Elle était dévastée. "J'ai fait tout ce qu'ils m'ont dit de faire", a-t-elle déclaré. "J'ai utilisé des styles de titre. J'ai ajouté du texte alternatif dans Word. J'ai coché la case." Elle l'avait fait. La formation n'avait tout simplement pas couvert les 90 % restants qui rendent un PDF accessible.Le coût réel des PDF inaccessibles
Laissez-moi vous montrer ce que coûtent réellement les PDF inaccessibles aux organisations, basé sur les données de mes audits :| Type d'organisation | Nombre moyen de PDF | Coût de remédiation | Risque juridique | Perte de productivité |
|---|---|---|---|---|
| Agence fédérale | 12 000-50 000 | 600 K$-2,5 M$ | Élevé (Section 508) | 340 heures/an en support |
| Gouvernement d'État | 5 000-20 000 | 250 K$-1 M$ | Élevé (ADA Titre II) | 180 heures/an en support |
| Enseignement supérieur | 8 000-35 000 | 400 K$-1,75 M$ | Très élevé (plaintes OCR) | 520 heures/an en support |
| Santé | 3 000-15 000 | 150 K$-750 K$ | Critique (sécurité des patients) | 280 heures/an en support |
| Services financiers | 2 000-10 000 | 100 K$-500 K$ | Élevé (réglementaire) | 160 heures/an en support |
Le mythe selon lequel les PDF accessibles ont une apparence moins bonne
Le mythe le plus persistant auquel je fais face est que les PDF accessibles doivent sacrifier la conception visuelle. Les dirigeants craignent que l'accessibilité signifie des documents laids. Les concepteurs rejettent les exigences d'accessibilité parce qu'ils pensent que cela signifie abandonner leurs mises en page soigneusement conçues. C'est complètement faux, et je peux le prouver."Nous ne pouvons pas rendre cela accessible sans ruiner la conception. La mise en page est trop complexe. L'accessibilité nous obligerait à simplifier tout et à le faire ressembler à un document Word de 1995."J'ai entendu cela de la part d'un directeur créatif d'une grande entreprise de services financiers. Ils venaient de dépenser 120 000 $ pour la conception de leur rapport annuel. Une typographie magnifique, des mises en page sophistiquées, des infographies sur mesure. Ils étaient convaincus que l'accessibilité détruirait tout cela. J'ai pris leur PDF et l'ai rendu entièrement conforme aux normes WCAG 2.1 AA en quatre heures. Rien n'a été changé visuellement. Pas un pixel. La version accessible ressemblait identiquement à l'originale. La seule différence était que les utilisateurs de lecteurs d'écran pouvaient maintenant vraiment le lire, et le PDF a passé les vérifications d'accessibilité automatisées. La confusion provient de la confusion entre accessibilité et simplicité. Oui, les documents plus simples sont plus faciles à rendre accessibles. Mais la complexité n'est pas l'ennemi : le manque de structure l'est. Vous pouvez avoir un PDF visuellement complexe et magnifiquement conçu qui est entièrement accessible si vous balisez correctement la structure. La présentation visuelle et la structure sémantique sont des couches distinctes. Pensez à cela comme à un bâtiment. La conception visuelle est l'extérieur - la façade, les fenêtres, les détails architecturaux. La structure d'accessibilité est la disposition intérieure - les couloirs, les étiquettes des pièces, la signalisation. Vous pouvez avoir un extérieur orné et complexe avec un intérieur clair et navigable. Ils ne sont pas en conflit. Le véritable défi n'est pas de rendre les PDF accessibles esthétiquement agréables - c'est de convaincre les organisations d'investir le temps dans une structure appropriée lors de la création au lieu de traiter l'accessibilité comme une solution de post-production. Lorsque vous intégrez l'accessibilité dès le départ, c'est invisible. Lorsque vous essayez de l'adapter plus tard, c'est à ce moment-là que vous vous heurtez à des compromis et des limitations.
Les critères WCAG qui importent réellement pour les PDF
La WCAG 2.1 comporte 78 critères de succès répartis sur trois niveaux de conformité. La plupart des créateurs de PDF paniquent lorsqu'ils voient cette liste. La bonne nouvelle : seuls environ 25 de ces critères s'appliquent généralement aux PDF, et seulement 12 représentent 90 % des échecs que je constate lors des audits. Voici ce qui compte vraiment, classé par fréquence d'échec dans mes 2 147 audits : 1. Structure des titres (taux d'échec de 78%) - WCAG 1.3.1, 2.4.6 : Les documents utilisent un style visuel au lieu de balises de titre sémantiques, ou sautent des niveaux de titres (H1 à H3 sans H2). 2. Texte alternatif pour les images (taux d'échec de 71%) - WCAG 1.1.1 : Les images manquent de texte alternatif ou ont des descriptions génériques comme "image" ou le nom de fichier. 3. Langue du document (taux d'échec de 68%) - WCAG 3.1.1 : Le PDF ne spécifie pas sa langue, ce qui perturbe la prononciation des lecteurs d'écran. 4. Ordre de lecture (taux d'échec de 64%) - WCAG 1.3.2 : Le contenu est balisé dans un ordre visuel plutôt que dans un ordre de lecture logique, surtout dans des mises en page à colonnes multiples. 5. Contraste des couleurs (taux d'échec de 52%) - WCAG 1.4.3 : Le texte ne respecte pas un ratio de contraste de 4,5:1, en particulier dans les en-têtes et les fenêtres d'appel. 6. Structure des tableaux (taux d'échec de 49%) - WCAG 1.3.1 : Les tableaux manquent de cellules d'en-tête appropriées, ou les tableaux complexes n'ont pas d'attributs de portée. 7. Texte des liens (taux d'échec de 43%) - WCAG 2.4.4 : Les liens disent "cliquez ici" ou "lire la suite" au lieu de décrire la destination. 8. Champs de formulaire (taux d'échec de 41%) - WCAG 1.3.1, 4.1.2 : Les champs de formulaire manquent d'étiquettes, ou les étiquettes ne sont pas correctement associées aux champs. 9. Structure des listes (taux d'échec de 38%) - WCAG 1.3.1 : Les listes utilisent des puces/numéros manuels au lieu de balises de liste sémantiques. 10. Titre du document (taux d'échec de 35%) - WCAG 2.4.2 : Le titre du PDF est manquant ou affiche le nom de fichier au lieu d'un titre descriptif. 11. Ordre de tabulation (taux d'échec de 31%) - WCAG 2.4.3 : L'ordre de tabulation ne suit pas l'ordre de lecture logique, ou n'est pas défini sur "Utiliser la structure du document". 12. Signets (taux d'échec de 28%) - WCAG 2.4.5 : Les longs documents manquent de signets pour la navigation, ou les signets ne correspondent pas à la structure des titres. Remarquez ce qui n'est pas sur cette liste : la plupart des critères WCAG concernant la fonctionnalité interactive, les médias basés sur le temps, ou les interactions web complexes. Les PDF sont principalement des documents statiques, donc les critères concernant les légendes vidéo, les pièges à clavier, ou les délais de session s'appliquent rarement."Nous avons passé trois mois à essayer de rendre nos PDF conformes aux WCAG et avons continué à échouer aux contrôles automatisés. Puis nous avons réalisé que nous essayions de corriger des critères qui ne s'appliquent même pas aux PDF. Nous perdions du temps sur les exigences de légendes vidéo lorsque nos documents n'ont pas de vidéo."Cette citation d'un coordinateur d'accessibilité d'une agence d'État illustre un problème courant : les organisations traitent la WCAG comme une liste de contrôle monolithique au lieu de comprendre quels critères s'appliquent à leur type de contenu spécifique. Cela gaspille d'énormes quantités de temps et crée une anxiété inutile.