BFSR BarrierefreiheitsGes. / EU Accessibility Act (EAA) - PDF/UA aus HTML generieren

[Rollo62]

Hallo zusammen,

ich möchte mal fragen, wer sich schonmal mit A11y beschäftigt hat
https://www.bmas.de/DE/Service/Geset...ngsgesetz.html
https://commission.europa.eu/strateg...ibility-act_en

Das betrifft auch PDF-Dateien, z.B. Datenblätter, Kataloge, EU Konformitätserklärungen und so weiter.
PDF an sich ist erstmal nicht barrierefrei, es gibt dafür PDF/UA und mit dem PAC ein gutest Testtool.
https://pac.pdf-accessibility.org/de

Ich habe insbesonder das Problem, dass ich Seiten in HTML generiere und dann zu PDF wandle.
Dabei gehen aber insbesondere die PDF/UA relevanten Einträge verloren.

Hat jemand ein ähnliches Problem mit der Konvertierung HTML-zu-PDF, vielleicht gibt es ja gute Tipps und/oder Tools zur Konvertierung dazu?

Ja, ich könnte PDF auch mit Delphi generieren, aber das würde an so vielen Stellen komplette Umstellung bedeuten,
dass ich hoffe, dass es mit HTML auch funktioniert.

Ich habe dazu auch eine CrossPost in der EN-DelphiPraxis.
https://en.delphipraxis.net/topic/13...fua-from-html/

[TurboMagic]

Hallo,

wie funktioniet das PAC?
Ich habe die URL aufgerufen und es heruntergeladen.
Ist ein 76 MB großes ZIP-Archiv. Habe es in einen leeren Ordner
entpackt und wollte PAC.exe darin starten.

Aber: bei mir kommt dann immer der Microsoft Store und behauptet
"Die App, die Sie installieren möchten, ist keine von Microsoft
überprüfte App." und will dann immer, dass ich in den Store gehe.
Aber mittels "PAC" was zu finden ist hoffnungslos, es sei den man
möchte Pac Man spielen...

[Olli73]

Ich habe mal die KI bemüht und es kam heraus, dass du das HTML am besten mit PrinceXML konvertierst.

[Rollo62]

Zitat von TurboMagic:

Hallo,

wie funktioniet das PAC?

Genau so, download, entpacken in eigenen Folder, virencheck, PAC.exe starten.
Ging bei mir und anderen ohne Probleme, vielleicht hast Du erweiterte Sicherheitssettings.
Läuft bei mir lokal unter C, als auch von Netzlaufwerk.

Leider zeigt PAC bei gewissen PDF Ladefehler, was dann den gesamten Prozess abbricht, also nicht alle PDF kann man da reinwerfen.

Hier gibt es noch ein OnlineTool, bin nicht sicher ob es auch auf PAC basiert.
https://check.axes4.com/de/

Das PDFix Lite funktioniert auch nach Installation, ist ein QT Projekt, und scheint sogar alle Probleme automatisch zu fixen.
https://pdfix.net/pricing/
Ist zwar in der Desktop-Version nicht mehr kostenlos, aber wenn das Fixen richtig funktioniert sein Geld wohl Wert.
Aktuell bin ich noch am checken, wie der Output daraus ist.
Das Lite kann auch bei manchen PDF abbrechen, kommt aber deutlich besser zu Ergebnissen und kann auch sehr komplexe PDF fixen.
Leider fehlt mir aktuell das Ultimative-Test-Tool, auch weil ich selbst keine Adobe-Produkte nutze,
dafür gibt es entweder was von Adobe oder Plugins.

Zitat von Olli73:

Ich habe mal die KI bemüht und es kam heraus, dass du das HTML am besten mit PrinceXML konvertierst.

Interessant, schaue ich mir mal an. Der Preis ist aber schon etwas hoch, für eine ungewisse Performance.
Mal schauen ob man das Testen kann.

[gubbe]

Ich beschäftige mich ebenfalls mit dem Thema PDF/UA. Wie generierst Du denn die PDF-Dateien aus den HTML-Seiten?

Nach meiner Erfahrung wäre es eigentlich besser, die Dateien gleich in HTML zu belassen, wenn man sie barrierefrei zugänglich machen möchte. Ist das keine Option?

Falls es PDF sein muss:
Hast Du versucht, aus der Druckvorschau in Chrome ein PDF zu erstellen? Das sollte zumindest eine Tag-Struktur anlegen (Structure Tree), wie es für barrierefreie PDF-Dateien benötigt wird. Voraussetzung ist natürlich, dass die HTML-Seiten schon entsprechend aufgebaut sind. Also mit Überschriften, Alt-Texten bei Bildern etc.

PDFix ist eher für vorhandene PDF-Dateien geeignet, um sie nachträglich barrierefrei zu machen. Wenn die PDF-Dateien erneut erzeugt werden können, ist es besser, beim Ausgangsformat anzusetzen. Eine Nachbearbeitung, z.B. mit Acrobat kann aber trotzdem notwendig sein.

Was bemängelt denn das PAC-Tool bei Deinen Dateien?

[Rollo62]

Zitat von gubbe:

Wie generierst Du denn die PDF-Dateien aus den HTML-Seiten?

Ich habe verschiedene Wege versucht, aktuell am einfachsten wäre einfach die Nutzung eines PDF-Druckers, wie Pdf24.
Leider scheinen diese Lösungen alle die Aria-Einträge und Zusatzeinträge im HTML zu ignorieren und noch nicht einmal Titel, usw. in das PDF zu übernehmen.
Weil HTML einigermaßen handhabbar ist, wäre das eine einfache Lösung dies um Zusatzinfo anzureichern, wenn diese dann am Ende korrekt im PDF landen.

Alternativ versuche ich die PDF nachzubearbeiten, z.B. mit Python-Tools, aber das ist natürlich auch nicht der optimale Weg, aber zumindest sehr vielversprechend.

Es geht nicht nur um HTML zu PDF, sondern auch um sehr viele alte Dokumente, die wir gerne möglichst einfach updaten möchten, deshalb der Versuch mit PDFix.

Eine Möglichkeit für PDF via InDesign könnten auch zum Beispiel automatisierte PlugIns sein, die bestehende Files vollautomatisch updaten, falls es so etwas geben sollte ( bin kein Adobe Experte ).

Im Moment mache ich aber verschiedendste Versuche und habe mich noch nicht festgelegt.
Weil das ganze Thema sehr komplex werden kann versuche ich erstmal eine Lösung für den Teilbereich der HTML-zu-PDF Konvertierung zu klären, warum dort die Aria Elemente verloren gehen.

[gubbe]

Dass mit einen PDF-Drucker die barrierefreien Einträge verloren gehen, ist nicht so überraschend. Der bekommt ja nur die Zeichenbefehle und nicht die HTML-Struktur, die aber notwendig wäre, um die Bedeutung der Elemente zu erfassen.
Aber wie gesagt, mit der Druck-Funktion von Chrome sollte es funktionieren. Hast Du das schon probiert?

Bei den alten Dokumente ist natürlich die Frage, ob es noch die Quelldateien gibt. Ansonsten kommst Du dabei um Tools wie PDFix nicht herum. Außer, Du würdest die PDF-Dateien zunächst wieder zurück wandeln in ein anderes Format wie Word.

Indesign kann PDF-Dateien mit Tags erzeugen. Man muss die Seitenelemente im Artikel-Panel gemäß der Lesereihenfolge anordnen, ggf. Grafiken verankern und mit alternativen Texten versehen. Es gibt Plugins wie MadeToTag, die dabei helfen können, aber automatisch geht es nicht.
Der Workflow mit Indesign sieht so aus, dass man die PDF-Datei anschließend nochmal in Acrobat überprüft und das PDF/UA-Flag manuell setzt. Mit dem genannten Plugin passiert das automatisch, aber natürlich nicht die Überprüfung. Das Plugin fand ich persönlich allerdings nicht sehr überzeugend.

Falls Du Adobe Acrobat hast, kannst Du Dir pdfGoHTML als Plugin installieren (kostenlos). Es erstellt aus PDF-Datei wieder eine HTML-Ansicht, in der man die Lesereihenfolge und die Auszeichnungen überprüfen kann. So ähnlich geht das aber auch mit dem PAC-Tool.

PDFs nachzuarbeiten mit Python-Tools dürfte schwierig werden, insbesondere, wenn die Seitenelemente in der PDF-Datei nicht in der Lesereihenfolge auftauchen. Du müsstest auch Tabellen erkennen und entsprechend auszeichnen. Das dürfte aufwendig werden und rechtfertigt wahrscheinlich eher den Kauf eines Tools wie PDFix, das auch als SDK verfügbar ist.

[Rollo62]

Zitat von gubbe:

Dass mit einen PDF-Drucker die barrierefreien Einträge verloren gehen, ist nicht so überraschend. Der bekommt ja nur die Zeichenbefehle und nicht die HTML-Struktur, die aber notwendig wäre, um die Bedeutung der Elemente zu erfassen.

Da bin ich nicht so sicher, es ist ja ein spezieller PdfPrinter dazwischengeschaltet und es sollten doch zumindest Titel und andere Metadaten in dem Prozess erhalten bleiben.
Ok, wahrscheinlich haben PDF-PlugIns, z.B. in Word, Excel, bessere Chancen da etwas abzugreifen.

Zitat von gubbe:

Aber wie gesagt, mit der Druck-Funktion von Chrome sollte es funktionieren. Hast Du das schon probiert?

Danke sehr, Werde ich noch machen, im Moment bin ich nicht auf Chrome.

Zitat von gubbe:

Bei den alten Dokumente ist natürlich die Frage, ob es noch die Quelldateien gibt. Ansonsten kommst Du dabei um Tools wie PDFix nicht herum. Außer, Du würdest die PDF-Dateien zunächst wieder zurück wandeln in ein anderes Format wie Word.

Ja Quelldaten sind da, aber wie gesagt, 200 Seiten PDF mit 27 Sprachen und 6500 Issues bei hunderten von solchen Dokumenten möchten wir nicht unbedingt fixen.

Das PDFix könnte aus den 6500 Issues 0 Fehler erzeugen, was die Dokumente dann zumindest technisch BFSR Konform machen, falls unsere Kunden das bemängeln.
Das ist zumindest der erste Schritt, bevor Dokumente dann wirklich angepasst werden.

Zitat von gubbe:

... MadeToTag, ... pdfGoHTML ...

Danke, ich selbst mache nichts mit InDesign, kann aber interessant sein für unsere Artworker.

Zitat von gubbe:

PDFs nachzuarbeiten mit Python-Tools dürfte schwierig werden, insbesondere, wenn die Seitenelemente in der PDF-Datei nicht in der Lesereihenfolge auftauchen.

Es gibt verschiedene Ideen die Struktur und Analyse aller Elemente zu machen und womöglich das Ergebnis dann wieder als Input zu nutzen, das schaue ich mir gerade an.
Wahrscheinlich bleibt aber immer noch eine Menge manueller Aufwand übrig, vollautomatisch wird es da schwierig werden.

Alternativ ist es vielleicht einfacher in HTML direkt zu arbeiten, was auch eher als barrierefrei angesehen wird, und das als alternativen, barrierefreien Kanal anzubieten.
Egal was wir machen, es müssen wohl viele unserer bisherigen Prozesse komplett umgebaut werden.

[gubbe]

Solange der PDF-Printer nicht speziell für das Ausgangsprogramm entwickelt wurde, um dort Daten abzugreifen, bekommt er die wichtigen Informationen gar nicht mit. Zum Beispiel Word sagt dem Drucker ja nicht "Jetzt komm eine Überschrift H1", sondern setzt nur die Schriftattribute. Daraus wieder umständlich eine Struktur abzuleiten, ergibt keinen Sinn. Besser können es (wie Du schon sagst) nur direkte PDF-Export-Funktionen in den Programmen wie Word, LibreOffice oder Chrome, die Zugriff auf die notwendigen "Rohdaten" haben.

Die Dateien nur rein technisch barrierefrei zu machen, ist meines Erachtens sinnlos. Dann kannst Du auch einfach alles als Artefakt (also unwichtig für den Screenreader) deklarieren und das PDF/UA-Flag setzen. Voilà: Barrierefrei Aber es geht ja darum, dass Leute damit auch wirklich etwas anfangen können.

Wenn Du Acrobat Pro hast, kannst Du Dir auch dessen Funktion zum automatischen Taggen anschauen bzw. die Online-Funktion mit KI ausprobieren. Ob da was sinnvolles rauskommt, hängt aber auch sehr davon ab, wie klar die Dokumente aufgebaut sind. Wenn Eure Dokumente nicht zufällig alle das gleiche Layout haben, wird es auch mit eigener Logik z.B. in Python, schwierig. Es gibt PDF-Dateien, da kannst Du noch nicht mal die Texte vernünftig auslesen.

Wenn die Quelldateien vorhanden sind, kann ich nur dazu raten, dort anzusetzen. Sonst hast Du später doppelte Arbeit.

[Rollo62]

Zitat von gubbe:

Voilà: Barrierefrei Aber es geht ja darum, dass Leute damit auch wirklich etwas anfangen können.

Genau, aber das ist schonmal der erste Schritt, um mögliche Abmahnungen von den Meldestellen zu verhindern, die gerade nach solchen Dingen suchen.

Es geht im Wesentlichen um Bedienungsanleitungen, Datenblätter und andere Dokumente wie Konformitätserklärungen oder Zertifikate, welche als Teil von Produkten angesehen werden können, die aber schon älter sein können.
Wenn diese nun in einem Onlineshop von unseren Kunden angeboten werden, könnte man diese als Teil des Verkaufsgeschäftes ansehen und dann müssten die wohl auch barrierefrei sein.
Weil es aber aktuell keine klare Einschätzung dazu gibt, ob das so muss, gehe ich mal davon aus, dass es nicht schadet die Fehler zu fixen, auch wenn es keinen Sinn macht im ersten Schritt.

Es macht aber überhaupt keinen Sinn alle alten Dokumente pro forma in InDesign zu überarbeiten, sondern das würden wir bei der nächsten Revision machen, sonst machen wir nichts anderes mehr.
Zumal es aus unserer Sicht nicht zwingend nötig ist, weil nicht wir selbst die Produkte in B2C Shops anbieten, unsere B2B Kunden dies aber schon an Endkunden verkaufen in deren B2C Shops.

Ich persönlich vermute mal, dass spätestens mit Einführung von Batteriepass und Produktpass, alle diese sowieso Daten unter die EAA fallen, weil diese dann als digitale elemente Teil der Kaufentscheidung eines Kunden im Onlineshop sind und damit laut EAA barrierefrei sein müssten.
Deshalb meine ich, bis dahin müssen wir das sowieso eingeführt haben, falls nicht ein Kunde das schon eher einfordert.