mastodon - Link to source
Ein Email-Austausch mit einer Freundin bestärkt mich darin, meinen Ausspruch „Barrierefreiheit und PDF, ein Widerspruch in sich" auch weiterhin aktiv zu nutzen. Barrierefreie PDFs zu erstellen ist immer noch ein Hexenwerk, es gibt außer Adobe Acrobat anscheinend kein Tool, dass selbst in einfachen Dokumenten mit ordentlicher Struktur ordentliche Exporte hinbekommt, und beim Auswerten und Lesen der Tags über verschiedene Betriebssysteme ist der Zustand mit "katastrophal“ noch mild umschrieben.
This entry was edited (2 days ago)
in reply to Marco Zehe

mastodon - Link to source

DNKrupinski 🏴‍☠️

* Für Word gibt es das Plugin axesWord, welches dich beim Erstellen der Tags aus Word unterstützt.
* Für InDesign gibt es madeToTag.
* Außerdem gibt es noch PDFlib für die programmierte Ausgabe von getaggten PDFs.
* Die Umsetzung aus LaTeX wird noch etwas brauchen, aber man ist eifrig bei der Sache.

Wie immer bei der Barrierefreiheit sind mehrere Beteiligte am Kochen, was das Ergebnis zu Experiment macht.

Der Autor/die Autorin, das verarbeitende System mit Exportfunktion, der PDF Reader, der Screenreader und das zugrunde liegende Betriebssystem.

Nur wenn alle ihren Job machen, ist das Gesamtergebnis zufriedenstellend bis gut.

Viele Schreibende verwenden die Formatvorlagen nicht, da kann der beste Export nichts machen – außer raten. Oder beim Export werden Inhalte, die über einen Seitenrand hinaus gehen, nicht zusammengefasst. Oder der PDF Reader gibt nicht alles an die Schnittstelle des Betriebssystems weiter. Oder der Screenreader ignoriert technische Normen.

Viel Potential für Fehler – wie bei der Erstellung von Internetseiten.

in reply to DNKrupinski 🏴‍☠️

mastodon - Link to source

Marco Zehe

@dnkrupinski Das ist mir durchaus alles klar. Im Gegensatz zu HTML-Seiten, wo meist irgendwie noch irgend etwas geht, ist aber bei PDFs oft genug wirklich gar nichts lesbar. Oder der Textfluss von nicht getaggten PDFs ist so grundlegend kaputt, dass es keinerlei Logik gibt. Mach z.B. mal eine Rechnung von der Telekom auf, egal ob Mobil oder Festnetz. Haarsträubendes Chaos.
@DNKrupinski 🏴‍☠️
in reply to Marco Zehe

mastodon - Link to source

DNKrupinski 🏴‍☠️

Mir ist das durchaus bewusst. Aber wenn du Schei…benkleister reinsteckst, kommt auch Scheibenkleister raus.

Auch wenn HTML "irgendwie" geht, kommst du oft ohne JavaScript gar nicht weiter – und was da an <DIV>-Dünnpfiff herauskommt will ich nicht weiter kommentieren.

Auch hier das Zusammenspiel: Redakteur:in / CMS / Betriebsystem / Screenreader.

Das Format PDF ist nicht schlechter oder besser als HTML (mit der Ausnahme, dass es nur wenige gibt, die PDF im Quellcode lesen können). Und es sind verschiedene Ausgangspunkte.
Doch wenn beide entsprechenden den Normen und Standards erstellt werden, ist das Ergebnis zumindest vergleichbar, wenn auch nicht gleichwertig.

Ja, ich wünschte mir auch ein Produkt, welches kostengünstiger und absturzfreier als der Adobe Acrobat Pro funktionieren würde. Aber **noch** gibt es das nicht – auch wenn der Foxit PDF Editor sich in die richtige Richtung entwickelt.

in reply to flo

mastodon - Link to source

Marco Zehe

@fasnix Ja, das stimmt im Prinzip, aber a) musst du es explizit einschalten, wenn du PDFs exportierst, was die meisten vermutlich übersehen werden, und b) übernimmt LibreOffice z.B. keine Alternativtexte für Grafiken aus aus Word importierten Dokumenten, und somit auch nicht in die getaggten PDFs. Ohne aufmerksame Handarbeit ist auch dies also eine echte Hürde. Dass dieses PDF sauber getaggt war, zeigt, dass sich da zum Glück jemand auskannte.
@flo
in reply to Marco Zehe

mastodon - Link to source

Sandra Pilz

@fasnix Wir haben das jetzt noch weiter getestet und Libre Office übernimmt die Alttexte doch. Die Datei, die wir getestet haben, hatte nur die von mir übersehenen Grafiken in der Kopfzeile, die im Acrobat mit Screenreader nicht angezeigt werden. Pages hat die Kopfzeile anscheinend so getaggt, dass sie nicht als solche erkennbar war vom SR, sondern als normaler Seitentext. (1/2)
@flo
in reply to Ortwin Pinke

mastodon - Link to source

Marco Zehe

@oldperl @fasnix Eben nicht. Die einzigen, die wirklich PDFs testen, sind Funktionen im kostenpflichtigen Adobe Acrobat. Word und LibreOffice haben Testmöglichkeiten, ihre nativen Dokumente auf Barrierefreiheitsprobleme zu testen, haben aber beim PDF-Export selbst das eine oder andere Defizit. pdf.js kann wohl rudimentär inzwischen Tags verarbeiten, Vorschau auf Mac und iOS auch, aber sonst kenne ich keine Bibliotheken, die standardmäßig vernünftig getaggte PDFs erstellen.
@Ortwin Pinke @flo
in reply to Marco Zehe

mastodon - Link to source

Marco Zehe

@oldperl @fasnix Und da sind Tools wie die OCR-Software ABBYY FineReader noch nicht berücksichtigt, die Dokumente scannen und daraus eine Logik abzuleiten versuchen, aufgrund der sie dann Tags in PDFs reinschreiben. Das kann gut gehen, muss es aber nicht. Und als Entwickler kannst du Dir natürlich die PDF/UA-Spezifikation reinziehen, das bleibt Dir unbenommen. Ist aber ein ziemlicher Brocken.
@Ortwin Pinke @flo
in reply to Ortwin Pinke

mastodon - Link to source

Marco Zehe

@oldperl @fasnix Das resultierende Markup für Screen Reader ähnelt stark HTML. Also Absätze, Sprachauszeichnungen, Überschriften, Grafiken mit Alternativtexten, Listen, Tabellen mit entsprechenden Header-Zellen usw. Also viele "übliche Verdächtige“. Was aber die Darstellung für Sehbehinderte wie Kontraste usw. angeht, da bin ich überfragt.
@Ortwin Pinke @flo
in reply to Marco Zehe

mastodon - Link to source

Stefan Daschek

@oldperl @fasnix

Wenn Inhalte als (semantisch getaggtes) HTML vorliegen, kann man Prince verwenden, um daraus accessible PDFs zu machen: princexml.com/doc/prince-outpu…

Bruce Lawson hat das hier super beschrieben: medium.com/@bruce_39084/making…

Prince ist frei für Non-Commercial-Use. Für Commercial Use oder wenn mans als SaaS verwenden möchte zB mal auf europdf.eu schauen (Disclaimer: In dem Projekt steck ich mit drin.)


Making accessible tagged PDFs with Prince

Making accessible tagged PDFs with Prince Disclosure: I’ve been doing some paid consultancy for YesLogic (Prince’s vendors) on the accessibility of Prince’s PDFs. Love them or hate them, PDFs …
Bruce Lawson (Medium)
@Ortwin Pinke @flo
in reply to Stefan Daschek

mastodon - Link to source

Stefan Daschek

@oldperl @fasnix

Nachtrag (wir haben das literally vor 10 Minuten deployed 😎):

Auf europdf.eu gibts einen Playground, wo man bequem mit Prince rumexperimentieren kann – HTML oder URL reinkopieren, bei Bedarf div. Options setzen, „Create PDF“, fertig. 🚀

Braucht zwar einen Account, aber Free Plan reicht. Damit kann man schon unbegrenzt viele „Test-PDFs“ (mit Wasserzeichen) machen.

Screenshot des EuroPDF Playgrounds: Ein umfangreiches Formular mit Eingabefeldern für HTML oder alternative eine URL und weiteren Optionen wie „Javascript“, „Media Type“, „Callback URL“ usw. Daneben eine Auflistung von PDFs, die bisher im Playground erzeugt wurden, mit Detailangaben zu Dateigröße, Erstellungsdauer etc.

EuroPDF - create PDFs from HTML, fast and secure!

/_bridgetown/static/europdf-og-6LMUHV7J.png
www.europdf.eu
@Ortwin Pinke @flo
in reply to Marco Zehe

mastodon - Link to source

Marco Zehe

Einige weitere Beobachtungen: LibreOffice scheint Alternativtexte von Grafiken aus Word-Dokumenten zu importieren, und auch in PDF-Dokumenten landen diese beim Export, aber nicht, wenn die Grafik in der Kopfzeile einer oder mehrerer Seiten ist, sondern nur wenn diese im Hauptbereich der Seite vorkommt. Kopf- und Fußzeilen werden im resultierenden PDF für Screen Reader gar nicht gerendert. Gefühlt macht LibreOffice vieles richtig, wenn man es anweist, PDF/UA auszugeben.
⇧