5.4 Anwendbarkeit bei Generieren von Druckversion in PDF-Format?

[cstrobbe]

Manche Websites bieten eine Druckversion der Informationen auf einer Seite an. Zum Beispiel

• Die Druckversion von Buchinformation bei Suhrkamp (das PDF wird in Echtzeit mit der Java-Library PD4ML generiert, im Gegensatz zu der Leseprobe);
• elektronische Fahrplanauskünfte bei der VVS in Stuttgart (mit einer angepassten Version von GPL Ghostscript generiert);
• Bestellbestätigungen in manchen Webshops.

Es geht in diesem Szenario nicht um Dateien, die per E-Mail gesendet werden, sondern um HTML-Informationen, die in Echtzeit als PDF bereitgestellt werden. Ist 5.4 in diesem Szenario anwendbar?

[detlevhfischer]

Da es sich explizit um eine Konvertierung in ein Druckformat handelt, das wirkliche Zielformat also Print ist, würde ich nicht davon ausgehen, dass der Prüfschritt darauf anwendbar ist.

[stefanFarnetani]

Schließe mich @detlevhfischer an.

[sweckenmann]

Könntet ihr vielleicht ein Praxisbeispiel geben, wann der Prüfschritt dann anwendbar ist? Wo kommt eine solche Konvertierung vor (ohne dass es sich um eine Druckversion handelt? Den Einwand verstehe ich) Die Frage kam neulich auch von einem Prüfer. Er bat darum, mal ein Beispiel in die Beschreibung aufzunehmen. Das würde die Beschreibung verständlicher machen.

[detlevhfischer]

Der Prüfschritt wäre z.B. beim BITV-Test Prüftool, das aus dem HTML Bericht einen PDF-Bericht erzeugt, anwendbar.

[cstrobbe]

Ich nehme an, dass es auch um online Konvertiertools wie z.B. smallpdf.com, word2pdfconverter.org, exceltopdf.com und Adobes PPT-to-PDF handelt.

[stefanFarnetani]

Zu Thema Beispiele: In meinen Augen sind auch klare Beispiele in Web-Apps oder webbasierten Verwaltungsprozessen zu finden; z.B. eine Bestätigung beim Einwohneramt oder eine Überweisungsbestätigung bei der Bank. Aber auch die alternative Version der Dokumente, die z.B. in google Docs herunterladen werden können. All Dokumente stehen für sich und können auch digital archiviert werden. Also muss es auch barrierefrei sein. Das sind in meinen Augen "echte" Konvertierungen. Druck-PDF sind nur notwendige (leider aktuell unvermeidliche) Zwischenschritte auf dem Weg zum Drucker.

Um so mehr ich auch über die Beispiele speziell von shurkamp-Verlag nachdenke, umso schwieriger empfinde ich die Abgrenzung. Als Webentwickler ist mir klar, dass viele dieser PDFs nur erzeugt werden, weil es einerseits keine stabile browserübergreifend Möglichkeit gibt direkt PDF-Druckaufträge anzustoßen und andererseits das Drucken aus HTML oft ... nun ja nennen wir es "imaginationsfördernd" ist.

Andererseits können wir nicht verhindern, dass Nutzer sich die Druck-PDF dann auch einfach speichern. Weil es halt praktisch ist. Sobald Nutzer sich das Dokument speichern, greift auch nicht mehr die von uns definierte Sonderregel ("nur für Druck gedacht").

Das ist wirklich schwer. Das Problem daran sind die seit Jahren vernachlässigten Druckfunktionen der Browser. Wären die CSS-Angaben für den Druck besser unterstützt und die Befehle zum Drucken von PDFs per Javascript besser unterstützt, dann wären wir nicht in diesem Dilemma für ein aktuell herrschendes technisches Defizit eine "Sonderregel" zu formulieren.

Aber zu Bedenken ist auch, dass eine härte Auslegung dieses Prüfschritt den Druck auf die Hersteller erhöhen würde, so dass dann endlich die lang erhofften technischen Lösungen entstehen. Im ersten Schritt wird diese Forderung jedoch bei vielen Kopfschütteln erzeugen.

[MarcHaunschild]

Ehrlich gesagt? - Ich finde die Ausnahme gut. Wir wissen alle, dass es Seiten gibt, die formal Vorgaben erfüllen und mi denen man trotzdem kaum zurecht kommt. Es gibt aber auch nicht perfekte Lösungen, die dennoch für Betroffen besser sind als die Alternativen. Ich habe mir oft schon so pragmatische Ausnahmen gewünscht. Wenn die Webseite selber zugänglich ist und sich jemand ein eigentlich für den Druck gemachtes, offiziell nicht barrierefreies PDF aufhebt, weil das für eine bestimmte Nutzerin angenehmer ist, dann spricht doch nichts dagegen. Dank so einem PDF, was ich mir vielleicht offline anschauen möchte und von dem ich weiß, dass ich wegen der fehlenden Auszeichnung Überschriften nicht zur Navigation nutzen kann, mit Strg-F aber schnell an die für mich relevanten Stellen komme, habe ich zusätzliche Wahlmöglichkeiten des Zugangs. Und das ist gerade wieder eins der zentralen Vorteile von Barrierefreiheit. Von allen Möglichkeiten mit ihren individuellen Vor- und Nachteilen die für mich beste aussuchen zu können. Die Alternative wäre einfach diese Möglichkeit zu streichen und dann hat keiner was davon, aber der Test wäre bestanden. Nur hat da keiner was davon... Vorausgesetzt es gibt einen empfohlenen zugänglichen Weg um an die Informationen zu kommen (hier die Webseite), ist jedes weitere Angebot ein Gewinn, das nicht mehr zu einer Abwertung führen sollte. Das ließe sich bestimmt elegant formuliert in den Test integrieren.

[sweckenmann]

Vielleicht kann man es so abgrenzen: Sobald das PDF eine Alternative zu HTML darstellt (z.B. eine identisches Druckversion) ist die Konvertierung für diesen PS nicht anwendbar. Wenn die Konvertierung andere Features bietet (z.B. wie die abweichende inhaltliche Darstellung des BITV-Test-Prüfberichts), dann schon? Beim BITV-Test-Prüfbericht liegt a) der HTML-Prüfbericht nicht vor (wenn er nicht veröffentlicht wurde b) der PDF-Prüfbericht enthält derzeit Texte, die in HTML nicht vorhanden sind. D.h. bei der Abgrenzung ist zu prüfen, ob den Nutzenden ein (inhaltlicher) Nachteil entsteht, wenn sie das PDF nicht nutzen können (HTML muss als Alternative dann natürlich zur Verfügung stehen). In die Richtung?

[MarcHaunschild]

In die Richtung?

Dafür! ;-)

[johannesFischer84]

@sweckenmann Sonja, den Vorschlag finde ich gut.

Aber was macht man bei Bestellbestätigungen von manchen Webshops (eines der Beispiele von cstrobbe im Einführungsbeitrag)? Wenn die Bestätigung nur direkt nach der Bestellung angezeigt wird, aber dann nach erneutem Öffnen des Browsers nicht erneut aufgerufen werden kann? Sofern über ein Kundenkonto die erneute Anzeige der Bestätigung möglich wäre, wäre das in Ordnung. Wenn die HTML-Seite aber nicht aufrufbar wäre, gäbe es den Nachteil, wenn man später auch die PDF (oder eine Bestätigungs-E-Mail) nicht nutzen könnte.

[sweckenmann]

@johannesFischer84 Hm, du meinst, wenn die Bestellbestätigung als HTML vorliegt aber nicht gespeichert wird? Ist das ein gängiger Fall? Wenn es eine HTML-Bestätigung gibt, wird sie doch in der Regel auch im Benutzerkonto gespeichrt? Aber klar, kann auch anders sein... Es stellt sich mir auch die Frage, ob man verlangen kann, dass ein User sich dafür registriert.? Manchmal kann man ja auch als "Gast" ohne Konto bestellen, dann hat man nur das PDF (meist aber dann auch keine HTML-Version).

[MarcHaunschild]

Muss man das in diesem Prüfschritt bewerten?

Ich meine das wäre nicht mehr die Website, sondern die Mail. Man müsste dann die Mail bewerten und das angehängte PDF.

Wenn alle die Infos in der Mail sind, würde man analog verfahren (das PDF wäre eine zusätzliche Option).

Auf das Beispiel würde ich nicht weiter eingehen, weil eben Bestellbestätigung (sie haben heute für 99 Cent eine Schokolade gekauft) ziemlich trivial ist.

Man erhält auch Mails mit komplexeren Inhalten. Üblich ist zum Beispiel der Versand von Rechnungen, deren Inhalte ausschließlich im PDF zu finden sind.

[johannesFischer84]

@MarcHaunschild Marc, die E-Mail wollte ich jetzt eigentlich gar nicht weiter diskutieren, vielleicht hätte ich sie gar nicht erwähnen sollen. Das ist ja ein anderer Thread, den cstrobbe in seinem einführenden Beitrag erwähnt hat.

@sweckenmann Sonja, ja wenn die Bestätigung im Nutzerkonto gespeichert wird, würde kein Nachteil entstehen. Da stimme ich zu.

[cstrobbe]

@detlevhfischer

Da es sich explizit um eine Konvertierung in ein Druckformat handelt, das wirkliche Zielformat also Print ist, würde ich nicht davon ausgehen, dass der Prüfschritt darauf anwendbar ist.

Öffnet das kein Schlupfloch? "Oh, die PDF-Version? Die ist nur zum Drucken gedacht, nicht zum Lesen auf einem Gerät." Kann man das auf Basis von EN 301 549 rechtfertigen?

[mayerhh]

Abgesehen von der Anwendbarkeit stellt sich mir die Frage, wie das geprüft werden soll. Für PDF-Dokumente würde das mindestens ein Check auf PDF/UA Konformität bedeuten. Wie passt das in das Prüfverfahren, wo die Prüfung von PDF ausgeschlossen wird?