Pdf.js: Unterstützung für mit Tags versehene PDFs einschließen

Label [triage-needed] hinzugefügt. Benötigen wir ein neues Label (4-tagged-pdf) für die Entwicklung von PDFs mit Tags?

Haben wir Beispiel-PDFs? Ich persönlich habe solche PDFs noch nie gesehen. Wie oft werden sie in der Praxis verwendet?

Ja, wir haben ein paar davon:

$ 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

Wenn Sie mehr benötigen, https://encrypted.google.com/search?q=filetype%3Apdf+ "%2FMarkInfo"+"%2FMarked+true"

Dankeschön! In diesem Fall ist es auf jeden Fall interessant, dies zu untersuchen.

Ich denke, es könnte relativ einfach sein, dies mit einer Mischung aus HTML- und ARIA-Attributen zu implementieren - keine Änderungen am Rendering erforderlich - fügen Sie einfach einige neue Attribute hinzu.

Die PDF-Tagging-Informationen werden im StructTreeRoot-Baum gespeichert, der Strukturelemente mit Informationen zur Barrierefreiheit wie Alt-Text, Sprache und Semantiktyp (H1, TH, LI usw.) enthält. Die Strukturelemente enthalten Verweise auf Objekte im Seiteninhaltsstrom. Hier gibt es eine Grafik, die das zeigt:
https://stackoverflow.com/a/34047585

Ich denke, Sie können die PDF-Tagging-Informationen wie folgt in _layoutText(textDiv) einfügen:

1) Suchen Sie das entsprechende Strukturelement im StructTreeRoot-Baum für das gerenderte PDF-Objekt
2) Fügen Sie dem div ein role Attribut hinzu, wenn das Strukturelement einen Strukturtyp wie H1, H2, LI usw. hat.
3) Fügen Sie dem div ein aria-label Attribut hinzu, wenn das Strukturelement einen /Alt-Eintrag hat
4) Fügen Sie ein aria-level Attribut zum div hinzu, das der Überschriftsebene für die Strukturtypen H1-H6 entspricht

Damit sollen Überschriften, Listen und Bilder einem Screenreader zugänglich gemacht werden. Tabellen können komplizierter zu implementieren sein.

Die PDF-Strukturtypen sind in Abschnitt 14.8.4.3 aufgeführt. von
https://www.adobe.com/content/dam/acom/en/devnet/pdf/pdfs/PDF32000_2008.pdf

Für eine Überschrift würde sich das Rendering folgendermaßen ändern:

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

dazu:

<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>

Das würde dann von einem Screenreader als "7. Auswertung, Überschriftenebene 1" gelesen und lässt den Benutzer vor allem mit der Taste "nächste Überschrift" zwischen den Überschriften wechseln (was die Navigation in großen Dokumenten erheblich erleichtert)

Mir ist aufgefallen, dass das 4-Tagged-pdf-Etikett entfernt wurde. Wird das noch verfolgt?

Das offene Thema zeigt an, dass wir es in Betracht ziehen. Dies ist ein Feature, und die Etiketten wurden ein wenig neu geordnet.

Wow! Das ist toll! Beinhaltet diese Funktion, die in Betracht gezogen wird, Unterstützung für die Generierung von PDFs mit Tags? Es könnte die Implementierung von so etwas wie einem Parser/Analyzer für vorhandene PDFs erleichtern, würde aber auch die Generierung von 508c-PDFs unterstützen.

Erforderliche Kernfunktionalität zum Generieren von 508c-PDFs:

• das Dokument markieren (mit einer Sprache und einem Titel, ggf. anderen Tags)
• Markieren Sie die strukturellen Objekte im PDF (Kopfzeile, Tabelle, th, td, Listen usw.)
• Hinzufügen von alternativem Text zu visuellen Medien (Bilder, Videos, Abbildungen usw.)
• Erstellen/Beibehalten einer Tabulatorreihenfolge von Elementen

Wenn es für diese 4 Dinge eine Kernfunktionalität gäbe, wäre es möglich, eine Logik in den PDF-Generierungsprozess zu implementieren, die 508c-PDFs erzeugen würde. Was, um ehrlich zu sein, riesig wäre, da ich noch kein OpenSource-Javascript-Tool gefunden habe, das diese Funktionalität unterstützt.

Nachdem ich dies geschrieben habe, bin ich mir nicht sicher, ob dies als separater Feature-Request gelten würde oder nicht... Ich würde gerne ein neues Issue erstellen, wenn dies der Fall ist.

Ich habe mit @cuhaller zusammengearbeitet , um eine bessere Einhaltung von SC 2.4.10 und 1.1.1 der WCAG 2.0 für Anwendungsfälle zu

Ich glaube, dass die Änderungen für eine Teilmenge dessen, was dieses Problem erfordert, ausreichend sein sollten. Ich werde in der nächsten Woche oder so eine PR veröffentlichen, die den Richtlinien zum

Ich habe Änderungen in einem Fork von 2.3.200 von PDF.js vorgenommen, um Überschriftenebenen und alternativen Bildtext (ohne Positionierung) bereitzustellen, der sich im Überschriften-und-img-alt-Text-Zweig dieses Repositorys befindet .

Ich zögere, eine PR zu eröffnen, da es Zusammenführungskonflikte mit dem Master gibt und ich derzeit nicht die Zeit habe, sie zu lösen.

Wenn jemand die Möglichkeit hat, diesen Zweig mit Master auf den neuesten Stand zu bringen, setzen wir uns mit Ihnen in Verbindung!

Edge hat die native Unterstützung für markierte PDFs angekündigt. Chrome unterstützt es jetzt auch und hat auch seine kommende Fähigkeit angepriesen, mit Tags versehene PDFs von Webseiten zu exportieren.

Heutzutage stellt Firefox das Tagging in PDFs nicht mehr dem Barrierefreiheitsbaum / den Barrierefreiheits-APIs zur Verfügung. Dieser Text steht jedoch auf der Funktionsliste für Firefox 80 :

Firefox kann jetzt als Standard-System-PDF-Viewer festgelegt werden.

Wenn ein Benutzer, der sich auf AT verlässt, dies tut oder ein Systemadministrator, der die Zusammensetzung der Benutzer nicht kennt, kann es für Benutzer, die sich sonst auf Edge, Chrome oder Adobes Reader verlassen, problematisch sein, getaggte PDFs für sie zu analysieren .

Ich empfehle dringend, die Hinweise aus den Versionshinweisen für 80 zu streichen und diese Fehlerpriorität zu erhöhen. Ich verstehe, dass Mozilla jetzt ressourcenbeschränkt ist, aber die Optik zur Förderung einer unzugänglichen Funktion, die in konkurrierenden Browsern besser bedient wird, sieht nicht gut aus.

Unsere Organisation möchte eine barrierefreie PDF-Lösung für Benutzer von Hilfstechnologien implementieren. Wir sind zu dem Schluss gekommen, dass die Vorschau eines PDFs mit PDF JS nicht zugänglich ist, da semantisches Markup fehlt. Der Mangel an semantischen Informationen schafft Barrieren für Benutzer, die mit Screenreader-Software interagieren. Während das PDF im Klartext angezeigt wird und Anmerkungen ankündigt, wird kein Markup für Überschriften, Tabellen, Bilder oder Links bereitgestellt.

Der Anwendungsfall, der Tabellen umgibt, ist für Benutzer von Bildschirmleseprogrammen besonders schwierig. Tabellen ohne semantisches Markup bieten den Benutzern keinen Kontext und es ist für Benutzer von Bildschirmleseprogrammen unmöglich, die in der PDF-Datei enthaltenen Informationen vollständig zu verstehen.

Links werden als URLs anstelle des spezifischen Linktextes angekündigt, was das Verständnis des Zwecks des Links erschwert. Wir empfehlen, dass Links anstelle der Link-URL den sichtbaren Linktext verwenden, damit die Benutzer den Link im Kontext verstehen.

Ohne diese Unterstützung haben wir Bedenken, PDF JS allgemein zu implementieren. Gibt es ein Update oder einen Zeitplan für die Unterstützung einer Funktion zur Bereitstellung von semantischem Markup? Wir bitten darum, diesem Problem eine höhere Priorität einzuräumen, da es die Fähigkeit der Benutzer zur Wahrnehmung und Interaktion mit Inhalten beeinträchtigt.

Beiträge sind meines Wissens mehr als willkommen

Danke @trjohnst für deine Arbeit dazu.

Ich begann @trjohnst ‚s manuell Rebasing Zweig auf Pdf.js Master. Dieser Ansatz funktioniert gut für Tags, die nur eine einzige Ebene benötigen; zB Überschriften oder Bilder mit Alt-Text. Wenn es beim Durchlaufen des Inhaltsstroms auf eine Sequenz mit markiertem Inhalt stößt, sucht es nach dem zugehörigen Strukturelement und platziert die entsprechende ARIA-Rolle auf der Textspanne in der HTML-Ausgabe der Textschicht pdf.js.

Leider reicht dies nicht für alles, was verschachtelte Tags benötigt; zB Listen oder Tabellen. Ich glaube nicht, dass der Ansatz auf diese ausgeweitet werden kann, zumindest nicht ohne viele knifflige Randfälle. Um Links und Formularfelder ordnungsgemäß zu unterstützen (und beachten Sie, dass Formularfelder zum Zeitpunkt des Beitrags von @trjohnst nicht von pdf.js unterstützt wurden), müssen wir in der Lage sein, die Anmerkungsebene zu berücksichtigen, nicht nur die Textebene. Wenn man noch weiter nach vorne denkt, wäre es gut, Heuristiken implementieren zu können, mit denen versucht wird, Überschriften, Links, Tabellen, Formularfelder usw. in ungetaggten PDFs zu erkennen (und richtig zu positionieren).

Anstatt dies in der Textebene zu versuchen, müssen wir meiner Meinung nach den Strukturbaum durchlaufen und darauf basierend Knoten rendern und ARIA-Eigenschaften für die Elemente festlegen, die wir ausgeben. Der Strukturbaum kann Daten sowohl in der Text- als auch in der Anmerkungsebene referenzieren. Wir können entweder die DOM-Knoten der Text- und Annotationsebene basierend auf dem Strukturbaum neu anordnen (kann schwierig sein, ohne das visuelle Rendering zu unterbrechen?)

Architektonisch ist dies schwierig, da die Text- und Anmerkungsebenen bereits getrennt gerendert werden, und jetzt müssen wir uns eine dritte Ebene (oder zumindest die Quelle der Wahrheit) ansehen, den Strukturbaum, der Knoten in beiden verschieben (oder referenzieren) kann die anderen Schichten. Der einfachste Weg, dies zu tun, besteht wahrscheinlich darin, jeder Sequenz mit markiertem Inhalt (in der Textebene) und jedem Link-/Formularfeld (in der Annotationsebene) eine ID zuzuordnen. Ich sehe, dass Formularfelder bereits ein Datenattribut haben, das eine ID angibt. Wenn wir aria-owns verwenden, müssen wir sowieso das id-Attribut setzen, sodass dies zwei Fliegen mit einer Klappe füttern könnte. Die ID müsste etwas sein, das wir außerhalb der Text- und Anmerkungsebenen berechnen können, innerhalb unserer neuen Strukturebene. Wenn wir den Strukturbaum handhaben, geben wir dann Elemente für die Strukturelemente aus, indem wir Elemente aus den Text-/Anmerkungsebenen basierend auf ihren IDs verschieben/besitzen.

Um über Tagged PDF zu Heuristiken hinauszugehen, müssten wir in der Lage sein, Dinge zu tun wie: Umfasst das Rechteck bei einer Link- oder Formularfeld-Anmerkung etwas in der Textebene? Wenn dies der Fall ist, sollte die Anmerkung mit ihrem Text verknüpft werden (aria-owns oder DOM move). Auch dies ist architektonisch schwierig, da die Text- und Anmerkungsebenen (und ihre Eingaben) getrennt sind und ich glaube nicht, dass wir von diesen Ebenen einen zwischengespeicherten Zustand haben, den wir verwenden können. Wir können jedoch möglicherweise die Grenzen der von den Text- und Annotationsebenen gerenderten Knoten betrachten, obwohl dies die architektonischen Grenzen zwischen Inhalts- und Präsentationsverarbeitung verwischt.

Während eine erste Implementierung von Tagged PDF nicht unbedingt Heuristiken unterstützen muss, empfehle ich dringend, dies als Teil des Architekturentwurfs zu berücksichtigen. Die Realität ist, dass ungetaggte PDFs leider sehr weit verbreitet sind und es wäre traurig, in eine Architektur eingeschlossen zu sein, die es nicht erlaubt, diese zugänglicher zu machen. (Beachten Sie, dass Acrobat Reader und in viel geringerem Maße Chromium Heuristiken verwenden, um zu versuchen, PDFs ohne Tags zugänglicher zu machen.)