Bien que cet article ne se veuille pas un tutoriel sur la création de contenu accessible avec Microsoft Word ou OpenOffice, garder à l’esprit les conseils suivants vous aidera à intégrer l’accessibilité dès la phase de création des documents sources – cette liste reprend quelques-uns des points les plus importants à retenir. Et comme nous l’avons vu dans les articles précédents, il est généralement préférable d’intégrer l’accessibilité dès la création du document source plutôt que de l’ajouter a posteriori, une fois que celui-ci a été converti au format PDF.
Images
Un document PDF accessible doit comporter des textes de remplacement pour les images informatives, les graphiques, les formules ou tout autre élément qui ne se traduit pas naturellement en texte pour les utilisateurs de technologies d’assistance. Dans la plupart des cas, cette démarche doit être effectuée avant même la création du document PDF. Le texte de remplacement doit transmettre le même sens que les informations contenues dans l’image, ou décrire sa fonction si l’image sert à représenter une action. Un exemple classique serait l’image d’une loupe utilisée pour lancer une recherche dans un document PDF interactif : le texte alternatif de cette image devrait naturellement être « Recherche ». Fournir un bouton de recherche avec un équivalent textuel indiquant « loupe » n’aurait pas beaucoup de sens dans ce contexte. Étonnamment, nous constatons sans cesse ce genre d’erreurs.
Il est conseillé de fournir des équivalents textuels aux images et autres éléments graphiques directement dans l'outil de création avant la conversion, plutôt que d'attendre de le faire dans Acrobat Pro. Cependant, comme c'est le cas pour les pages Web HTML classiques, les images purement décoratives ou qui ne transmettent pas d'informations pertinentes aux utilisateurs doivent être balisées avec un attribut nul afin que les technologies d'assistance puissent les ignorer. Ces images ne peuvent pas être traitées dans l’outil de création et devront être marquées comme des artefacts, directement dans Acrobat Pro (un peu comme si on les intégrait en tant qu’images d’arrière-plan CSS).
Liens hypertextes
Les liens hypertextes doivent être reconnaissables par les technologies d'assistance et contenir des informations adéquates quant à leur destination et à leur finalité. En d'autres termes, leur finalité doit être claire afin que les utilisateurs sachent à quoi s'attendre lorsqu'ils cliquent dessus. Les liens doivent être créés dans l’outil de création avant la conversion, mais ils peuvent également être ajoutés à une chaîne de texte dans Acrobat Pro après la conversion. Les deux méthodes fonctionnent aussi bien l’une que l’autre du point de vue des technologies d’assistance, mais les liens ajoutés dans le document PDF ne seront pas signalés visuellement ; cela peut poser des problèmes de repérage pour les utilisateurs voyants. Il est donc toujours préférable d’ajouter les liens dans le document source plutôt que d’attendre la fin du processus de conversion.
Des libellés de lien peu pertinents, tels que « cliquez ici » ou « en savoir plus », posent souvent problème aux utilisateurs qui ne peuvent pas voir le contexte de la page. Parfois, afin de s’assurer que l’objectif des liens reste clair même hors contexte, il est nécessaire d’apporter des informations complémentaires au-delà du texte visible du lien. Alors que cela s’effectuerait normalement à l’aide de l’attribut `aria-label` ou d’un positionnement CSS hors écran dans un fichier HTML classique, cette opération dans un document PDF nécessite de masquer les informations supplémentaires derrière les liens. Cela ne peut être réalisé qu’à l’aide de la propriété « texte alternatif » (alt text) dans Acrobat Pro – l’un des rares cas où une partie du balisage doit être traitée après le processus de conversion.
Langue
L'identification de la langue par défaut d'un document PDF constitue un autre aspect essentiel de l'accessibilité des PDF. Souvent négligée, cette question peut créer des obstacles insurmontables pour les utilisateurs de lecteurs d'écran issus d'un contexte culturel différent et/ou pour lesquels l'anglais n'est que la deuxième ou la troisième langue. La définition de la langue par défaut d'un document permet aux technologies d'assistance et aux agents utilisateurs classiques, tels que les navigateurs Web, d'afficher le texte avec plus de précision.
La langue par défaut du document doit toujours être spécifiée dans l'outil de création avant la conversion au format PDF ; cela garantit que la version source et la version PDF seront toutes deux correctement configurées. Si cette étape n'a pas été effectuée et que le document source n'est plus disponible, la langue par défaut peut également être spécifiée dans Acrobat Pro après la conversion, mais cette opération s'avère souvent plus chronophage.
Les mots, expressions, paragraphes, citations ou extraits d’un document rédigés dans une langue différente de la langue par défaut du document doivent également être signalés comme tels pour les lecteurs d’écran et les technologies d’agents utilisateurs. Bien qu’il soit recommandé de définir cette indication dans l’outil de création, ces informations ne sont pas toujours transférées de manière fiable de l’outil de création vers le fichier PDF ; il est donc parfois nécessaire de préciser les changements de langue dans Acrobat Pro après la conversion du document.
Titres
Les titres font office de plan ou de table des matières interactive pour un document, dans la mesure où ils permettent aux utilisateurs de technologies d'assistance de passer d'une partie du contenu à une autre, à condition que ces titres soient correctement balisés. Il est donc essentiel de veiller à ce que les titres soient définis de manière sémantique dans l'outil de création à l'aide de styles, plutôt que de se contenter de modifier leur présentation visuelle en variant la taille, la police et la couleur des caractères pour leur donner l'apparence de titres.
Les documents accessibles utilisent des titres pour refléter la structure logique de leur contenu. L'utilisation hiérarchique des titres et le fait d'éviter les sauts de niveau aident les utilisateurs de technologies d'assistance à comprendre la structure du contenu. Ces utilisateurs peuvent ainsi s'appuyer sur un plan organisé de manière logique pour accéder directement au contenu qu'ils souhaitent lire.
Il est plus efficace de définir les titres dans le logiciel de création plutôt que dans Acrobat Pro, car les styles ainsi appliqués seront ensuite systématiquement appliqués à toutes les autres chaînes de texte identifiées comme des titres, ce qui améliore la cohérence globale de la présentation et de la mise en page. Les titres peuvent toujours être ajoutés ou corrigés dans Acrobat Pro après la conversion, mais, là encore, cette opération s'avérera beaucoup plus chronophage si elle n'est effectuée qu'une fois le processus de conversion terminé.
Listes
Les listes d'éléments doivent être correctement mises en forme dans l'outil de création à l'aide de balises de liste, afin que les technologies d'assistance puissent refléter la relation entre les éléments de la liste et permettre aux utilisateurs de naviguer d'une liste à l'autre, ou d'un élément de liste à l'autre. Le simple fait d'utiliser des sauts de ligne pour séparer les éléments d'une liste n'est pas suffisant, car la structure (ou l'absence de structure) ne se traduit pas de manière programmatique pour les technologies d'assistance.
La manière la plus simple de créer des listes consiste à les mettre correctement en forme à l'aide des balises et des styles de liste dans l'outil de création avant la conversion (listes ordonnées ou non ordonnées). Acrobat Pro permet également de baliser les listes après la conversion, mais seules les listes non ordonnées classiques sont disponibles au format PDF (il est impossible de baliser sémantiquement les listes ordonnées dans un fichier PDF). Une fois converties au format PDF, les listes ordonnées seront simplement considérées comme des listes non ordonnées. Pour transformer une liste non ordonnée en liste ordonnée, les auteurs devront ajouter manuellement un numéro devant chaque élément de la liste, en l'intégrant à l'élément de liste.
En conclusion
Ce ne sont là que quelques-unes des améliorations les plus importantes qui peuvent être apportées à un document source afin d’aider les technologies d’assistance à en tirer le meilleur parti. D’autres aspects pourraient également être abordés, mais le simple fait de respecter ces quelques exigences permettrait déjà aux utilisateurs de bénéficier d’améliorations considérables. Le prochain article conclura cette série en passant en revue les principes fondamentaux d’un processus de conversion efficace au format PDF, afin que les fonctionnalités d’accessibilité incluses dans le document source soient transférées automatiquement et de manière fiable vers le fichier PDF.
Les articles de blog de cette série sont les suivants. Le dernier sera publié dans les prochaines semaines :
- Exigences relatives aux fichiers PDF accessibles : 1re partie
- Exigences relatives à un fichier PDF accessible : 2e partie – Obstacles courants à l'accessibilité
- Exigences relatives aux fichiers PDF accessibles : Partie 3 – Bonnes pratiques de création (cet article)
- Exigences relatives à un fichier PDF accessible : 4e partie – Processus de conversion adéquat
Nous espérons que vous avez apprécié ce troisième volet de notre série consacrée aux exigences en matière d'accessibilité des fichiers PDF. Pensez-vous que ces bonnes pratiques soient les plus importantes ? Estimez-vous que d'autres bonnes pratiques auraient dû être mentionnées ? N'hésitez pas à laisser un commentaire afin que nous puissions poursuivre cette discussion.
