Pdf.js: Inclut la prise en charge des PDF balisés

Ajout de l'étiquette [triage-needed]. Avons-nous besoin d'une nouvelle étiquette (4-tagged-pdf) pour le développement lié aux PDF balisés ?

Avons-nous des exemples de PDF? Personnellement, je n'ai jamais vu de tels PDF. À quelle fréquence sont-ils utilisés dans la pratique ?

Oui, nous en avons quelques-uns :

$ cd test/pdfs/
$ grep -rla '/Marked true'
i9.pdf
fips197.pdf
issue1169.pdf
smaskdim.pdf
issue3879.pdf
bug816075.pdf
pdf.pdf
issue1709.pdf
f1040.pdf
wdsg_fitc.pdf
annotation-border-styles.pdf
ecma262.pdf
bug887152.pdf
issue1133.pdf
issue2442.pdf
issue1796.pdf
type4psfunc.pdf

Si vous avez besoin de plus, https://encrypted.google.com/search?q=filetype%3Apdf+ "%2FMarkInfo"+"%2FMarked+true"

Merci! Dans ce cas, il est certainement intéressant de se pencher là-dessus.

Je pense qu'il pourrait être relativement facile d'implémenter cela en utilisant un mélange d'attributs HTML et ARIA - aucune modification du rendu requise - ajoutez simplement de nouveaux attributs.

Les informations de balisage PDF sont stockées dans l'arborescence StructTreeRoot, qui contient des éléments de structure avec des informations d'accessibilité comme le texte alternatif, la langue et le type sémantique (H1, TH, LI, etc.). Les éléments de structure contiennent des références à des objets dans le flux de contenu de page. Il y a un graphique montrant ceci ici :
https://stackoverflow.com/a/34047585

Je pense que vous pouvez injecter les informations de marquage PDF dans _layoutText(textDiv) utilisant quelque chose comme ceci :

1) Recherchez l'élément de structure correspondant dans l'arborescence StructTreeRoot pour l'objet PDF en cours de rendu
2) Ajoutez un attribut role au div si l'élément de structure a un type de structure comme H1, H2, LI etc.
3) Ajoutez un attribut aria-label au div si l'élément de structure a une entrée /Alt
4) Ajoutez un attribut aria-level au div correspondant au niveau de titre pour les types de structure H1-H6

Cela devrait rendre les en-têtes, les listes et les images accessibles à un lecteur d'écran. Les tableaux peuvent être plus compliqués à mettre en œuvre.

Les types de structure PDF sont répertoriés dans la section 14.8.4.3. de
https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf

Pour un titre, le rendu changerait de ceci :

<span style="left: 173.529px; top: 237.049px; 
font-size: 5.99874px; font-family: sans-serif; 
transform: scaleX(1.05905);">
7.  Evaluation
</span>

pour ça:

<span style="left: 173.529px; top: 237.049px; 
font-size: 5.99874px; font-family: sans-serif; 
transform: scaleX(1.05905);" 
role="heading" aria-level="1">
7.  Evaluation
</span>

Cela serait alors lu par un lecteur d'écran comme "7. Évaluation, titre de niveau 1" et, plus important encore, permet à l'utilisateur de passer d'un titre à l'autre à l'aide de la touche "en-tête suivant" (ce qui facilite la navigation dans les documents volumineux).

J'ai remarqué que l'étiquette 4-tagged-pdf a été supprimée. Est-ce toujours quelque chose qui est poursuivi?

La question étant ouverte indique que nous l'envisageons. C'est une fonctionnalité, et les étiquettes ont été un peu réorganisées.

Wow c'est génial! Cette fonctionnalité envisagée inclut-elle la prise en charge de la génération de PDF balisés ? Cela pourrait faciliter la mise en œuvre de quelque chose comme un analyseur/analyseur pour les PDF existants, mais cela fournirait également un support pour générer des PDF 508c.

Fonctionnalités de base requises pour générer des PDF 508c :

• baliser le document (avec une langue et un titre, éventuellement d'autres balises)
• balisez les objets structurels à l'intérieur du PDF (en-tête, tableau, th, td, listes, etc.)
• ajouter du texte alternatif aux supports visuels (images, vidéo, figures, etc.)
• créer/maintenir un ordre de tabulation des éléments

Si la fonctionnalité de base existait pour ces 4 éléments, il serait alors possible d'implémenter une logique dans le processus de génération de PDF qui produirait des PDF 508c. Ce qui, pour être honnête, serait énorme, car je n'ai pas encore trouvé d'outil javascript OpenSource avec cette fonctionnalité prise en charge.

Après avoir écrit ceci, je ne sais pas si cela pourrait être considéré comme une demande de fonctionnalité distincte ou non... Je serais heureux de créer un nouveau problème si tel est le cas.

J'ai travaillé avec @cuhaller pour assurer une meilleure conformité avec SC 2.4.10 et 1.1.1 des WCAG 2.0 pour les cas d'utilisation spécifiques à l'application sur laquelle travaille son équipe.

Je pense que les changements devraient être suffisants pour un sous-ensemble de ce que cette question exige d'être fait. J'aurai un PR dans la semaine prochaine en suivant les directives de contribution . Je mettrai à jour ce fil lorsque je soumettrai.

J'ai des modifications dans un fork de 2.3.200 de PDF.js pour fournir des niveaux de titre et un texte d'image alternatif (sans positionnement) situé dans la branche headers -and-img-alt-text de ce référentiel .

J'hésite à ouvrir un PR car il y a des conflits de fusion contre master et je n'ai actuellement pas le temps de les résoudre.

Si quelqu'un a de la disponibilité pour mettre cette branche à jour avec le maître, contactez-nous !

Edge a vanté la prise en charge native des PDF balisés. Chrome le prend également désormais en charge et a également vanté sa capacité future à exporter des fichiers PDF balisés à partir de pages Web.

Aujourd'hui, Firefox n'expose pas le balisage des PDF à l'arborescence d'accessibilité/API d'accessibilité. Cependant, ce texte est sur la liste des fonctionnalités de Firefox 80 :

Firefox peut maintenant être défini comme la visionneuse PDF par défaut du système.

Si un utilisateur qui s'appuie sur AT le fait, ou un administrateur système qui ne connaît pas la composition des utilisateurs le fait, il peut être problématique pour les utilisateurs qui s'appuyaient sur Edge, Chrome ou Adobe's Reader d'analyser les fichiers PDF balisés pour eux. .

Je suggère fortement que les conseils soient supprimés des notes de version pour 80, et que cette priorité de bogue soit augmentée. Je comprends que Mozilla est maintenant limité en ressources, mais l'optique de promouvoir une fonctionnalité inaccessible qui est mieux servie dans les navigateurs concurrents n'est pas bonne.

Notre organisation cherche à mettre en œuvre une solution PDF accessible pour les utilisateurs de technologies d'assistance. Nous sommes arrivés à la conclusion que la prévisualisation d'un PDF avec PDF JS n'est pas accessible car le balisage sémantique est manquant. Le manque d'informations sémantiques crée des barrières pour les utilisateurs qui interagissent avec les logiciels de lecture d'écran. Bien que le PDF s'affiche en texte brut et annonce des annotations, le balisage n'est pas fourni pour les en-têtes, les tableaux, les images ou les liens.

Le cas d'utilisation entourant les tables est particulièrement difficile pour les utilisateurs de lecteurs d'écran. Les tableaux dépourvus de balisage sémantique ne fournissent aucun contexte aux utilisateurs et il est impossible pour les utilisateurs de lecteurs d'écran de comprendre pleinement les informations présentées dans le PDF.

Les liens sont annoncés sous forme d'URL au lieu du texte du lien spécifique, ce qui rend difficile la compréhension de l'objectif du lien. Nous recommandons que les liens utilisent le texte du lien visible au lieu de l'URL du lien, afin que les utilisateurs comprennent le lien dans son contexte.

Sans ce support, nous avons des inquiétudes quant à l'implémentation de PDF JS à grande échelle. Existe-t-il une mise à jour ou un calendrier concernant la prise en charge d'une fonctionnalité pour fournir un balisage sémantique ? Nous demandons que ce problème soit considéré comme une priorité plus élevée car il a un impact sur la capacité des utilisateurs à percevoir et à interagir avec le contenu.

Autant que je sache, les contributions sont plus que bienvenues

Merci @trjohnst pour votre travail à ce sujet.

J'ai commencé rebasage manuellement @trjohnst de » branche sur le maître de pdf.js. Cette approche fonctionne bien pour les balises qui n'ont besoin que d'un seul niveau ; par exemple des titres ou des images avec du texte alternatif. Lorsqu'il parcourt le flux de contenu, s'il rencontre une séquence de contenu marqué, il recherche l'élément de structure associé et place le rôle ARIA approprié sur l'étendue de texte dans la sortie HTML par la couche de texte pdf.js.

Malheureusement, cela n'est pas suffisant pour tout ce qui nécessite des balises imbriquées ; par exemple des listes ou des tableaux. Je ne pense pas que l'approche puisse être étendue pour couvrir ceux-ci, du moins pas sans beaucoup de cas limites délicats. De plus, afin de prendre en charge correctement les liens et les champs de formulaire (et notez que les champs de formulaire n'étaient pas pris en charge par pdf.js au moment de la contribution de

Plutôt que d'essayer de le faire dans la couche de texte, je pense que nous allons devoir parcourir l'arborescence de la structure et rendre les nœuds en fonction de cela, en définissant les propriétés ARIA sur les éléments que nous sortons. L'arborescence de la structure peut référencer des données à la fois dans les couches de texte et d'annotation. Nous pouvons soit réorganiser les nœuds DOM de la couche de texte et d'annotation en fonction de l'arbre de structure (cela pourrait être délicat sans casser le rendu visuel ?) ou utiliser aria-owns pour réorganiser uniquement l'arbre a11y sans réorganiser le DOM.

Sur le plan architectural, cela est délicat car les calques de texte et d'annotation sont déjà rendus séparément, et nous devons maintenant examiner un troisième calque (ou au moins une source de vérité), l'arbre de structure, qui peut déplacer (ou référencer) des nœuds dans les deux les autres couches. Le moyen le plus simple de le faire est probablement d'attacher un identifiant à chaque séquence de contenu marqué (dans la couche de texte) et à chaque champ lien/formulaire (dans la couche d'annotation). Je vois que les champs de formulaire ont déjà un attribut de données spécifiant un identifiant. Si nous voulons utiliser aria-owns, nous devons quand même définir l'attribut id, afin que cela puisse nourrir deux oiseaux avec un scone. L'identifiant devrait être quelque chose que nous pouvons calculer à partir de l'extérieur des couches de texte et d'annotation, à partir de notre nouvelle couche de structure. Lorsque nous gérons l'arbre de structure, nous produisons ensuite des éléments pour les éléments de structure, en déplaçant/possédant des éléments des calques de texte/annotation en fonction de leurs identifiants.

Au-delà du PDF balisé à l'heuristique, nous aurions besoin de pouvoir faire des choses comme : étant donné un lien ou une annotation de champ de formulaire, son rectangle englobe-t-il quelque chose dans le calque de texte ? si c'est le cas, l'annotation doit être associée à son texte (aria-owns ou DOM move). Encore une fois, c'est architecturalement délicat car les couches de texte et d'annotation (et leurs entrées) sont séparées et je ne pense pas que nous ayons un état mis en cache à partir de ces couches que nous puissions utiliser. Cependant, nous pouvons potentiellement examiner les limites des nœuds rendus par les couches de texte et d'annotation, bien que cela commence à brouiller les frontières architecturales entre le traitement du contenu et de la présentation.

Bien qu'une implémentation initiale de PDF balisé n'ait pas nécessairement besoin de prendre en charge l'heuristique, j'encourage fortement à considérer cela comme faisant partie de la conception architecturale. La réalité est que les PDF non balisés sont malheureusement très répandus et il serait triste d'être enfermé dans une architecture qui ne permet pas de les rendre plus accessibles. (Notez qu'Acrobat Reader et, dans une bien moindre mesure, Chromium, utilisent des heuristiques pour essayer de rendre les PDF non balisés plus accessibles.)