Vom Kampf Gut gegen Böse

PDF-Dokumente zu lesen gehört zum Alltag eines Internetnutzers. Menschen mit Behinderungen wird dieser Alltag jedoch oft erschwert. Ein Großteil der Beschwerden über Barrieren im Web betrifft Informationen, die als PDF vorliegen. René Jaun, blinder Accessibility-Spezialist brachte es bei der Swiss Publishing Week 2008 einmal folgermaßen auf den Punkt:

„Wenn Satan heute geboren würde, würde er als PDF-Datei auf die Welt kommen.“

Zugegeben, die Webwelt besteht tatsächlich aus einer Vielzahl an unzugänglichen PDF-Dateien, an denen sich nicht nur Screenreader wie beispielsweise JAWS vergeblich die Zähne ausbeißen (JAWS ist nicht nur das Akronym zu „Job Access With Speech“, sondern Steven Spielbergs Film „Der weiße Hai“ hieß im Original auch so). Aber die Welt in PDF = „böse“ und HTML = „gut“ einzuteilen, trifft das Problem nicht ganz. Auch wenn es immer wieder heiß diskutiert wird – zuletzt aus Anlass einer Studie der australischen Regierung – so kann es aus Sicht der Barrierefreiheit genauso „gute“ PDF-Dateien geben wie es andererseits „böse“, sprich: nicht barrierefreie HTML-Seiten geben kann. Letztlich ist es eine Frage, inwieweit der Autor bereits beim Verfassen seines Dokumentes, aus dem später ein PDF werden soll, die Anforderungen der Barrierefreiheit beachtet. Das klingt einleuchtend, ist aber nur die halbe Wahrheit.

Sauberes Arbeiten in Word ist eine wichtige Voraussetzung für das effiziente Erstellen barrierefreier PDF-Dokumente - wie hier im Beispiel das korrekte Gliedern des Dokumentes mit Hilfe von Überschriftenebenen - aber letztlich ist dies auch nur die halbe Wahrheit.

Dieses abgeänderte Zitat wäre genauso zutreffend:

„Wenn Satan heute geboren würde, dann würde er als Textverarbeitungs-, Layout- oder PDF-Erstellungsprogramm auf die Welt kommen“

Denn auch wenn PDF sich als Format für barrierefreies Publizieren noch weiterentwickeln kann und wird, so bietet es gemäß PDF-Spezifikation bereits die Grundvoraussetzung für das Bereitstellen zugänglicher Inhalte. Man darf also nicht dem Format allein die Schuld geben. Eine weitaus größere Hürde auf dem Weg zu einer weiteren Verbreitung barrierefreier PDF-Dokumente liegt in den unzureichenden Werkzeugen für ihre Erstellung. Aber warum sind die Werkzeuge unzureichend und warum gibt es keine besseren?

Am fehlenden Markt kann es wohl nicht liegen: PDF-Dokumente sind überall zu finden. Bisher noch. Denn je lauter der Ruf nach barrierefreien Versionen wird, desto vernehmbarer wird auch die Auffassung, dass das Erstellen zu aufwändig ist und man sich daher entschieden hat, überhaupt keine PDF-Dokumenten mehr auf der Internetseite einzustellen.

Aber wie aufwändig ist das Erstellen denn nun wirklich? Genügt es nicht, einfach Überschriftenformate zu verwenden und bei der Konvertierung die ominösen Tags miterstellen zu lassen und fertig? Oder: wie könnte man den Aufwand minimieren? Als ersten Schritt auf dem Weg zu einer Antwort schauen wir uns an, wie ein barrierefreies PDF-Dokument erstellt wird.

Workflow in 8 Phasen

PDF ist ein Sekundärformat. Das bedeutet, dass ich ein Quelldokument in einem anderen Format erstelle und dieses dann in ein PDF-Dokument konvertiere. Ein idealtypischer Workflow in 8 Phasen, wie ich ihn in dem Kapitel „PDF verstehen und umsetzen“ in dem neu erschienenen Standardwerk „Barrierefreiheit verstehen und umsetzen“ (d-Punkt-Verlag 2011) ausführlich vorstelle, ist dementsprechend dreigeteilt und sieht wie folgt aus:

Im Quellformat (A)

Phase 1: Inhalte mit Strukturinformationen versehen
„Strukturiert arbeiten“ über das Verwenden von korrekten Formatvorlagen für Überschriften, Listen, Tabellen

Phase 2: Barrierefrei gestalten
Beispielsweise auf ausreichende Kontraste achten

Phase 3: Merkmale der Barrierefreiheit anlegen
Beispielsweise Alternativtexte zu Fotos und Grafiken

Konvertierung (B)

Phase 4: PDF mit Tags erstellen
Im Normalfall geschieht dies „per Knopfdruck“

In Acrobat (C)

Phase 5: Zwischenprüfung durchführen
Daraus folgt eventuell eine Korrektur im Quellformat

Phase 6: Eigenschaften vervollständigen
Dies betrifft alle Merkmale der Barrierefreiheit, die man im Quellformat nicht anlegen konnte

Phase 7: Prüfen
die Qualitätssicherung der finalen Version

Phase 8: Sicherheit festlegen
Kennwortschutz setzen falls notwendig gegen Änderungen an dem Dokument

Der real existierende Kompromiss

Ausgehend von unserem 8-Phasen Workflow lassen sich die Grenzen der vorhandenen Werkzeuge aufzeigen und damit auch erkennen, wo Zusatzaufwand entsteht und wie sich dieser verringern lässt. Für eine erste Betrachtung genügt ein Blick auf einen Textverarbeitungsworkflow beispielsweise mit Word 2007 und Acrobat 9 Professional. Eine ideale Programmkombination gibt es hier nicht. Jeder Workflow weist seine eigenen Vor- und Nachteile auf. Ein Zusatzaufwand besonders aus den Phasen 5 bis 8 ist immer damit verbunden.

Grundsätzlich lassen sich die Probleme folgendermaßen gliedern:

• im Quellformat (A):
  Nicht alle Merkmale der Barrierefreiheit lassen sich hier bereits anlegen. Beispielsweise ist es nicht möglich, in einer Tabelle eine Spalte mit Überschriftenzellen korrekt auszuzeichnen.

• bei der Konvertierung (B):
  Selbst wenn im Quelldokument korrekt gearbeitet wurde, die Konvertierung das entsprechende Merkmal jedoch nicht unterstützt, muss nachgearbeitet werden. Beispielsweise werden bedingte Trennstriche nicht korrekt ins PDF übersetzt, so dass diese durch eine Sprachausgabe ausgegeben oder in der Umfließenansicht angezeigt werden.

• in Acrobat (C):
  Bleiben wir beim Problem der Silbentrennung. Zwar gibt es in Acrobat eine Möglichkeit, einen Trennstrich durch einen bedingten Trennstrich manuell zu ersetzen. Dies ist jedoch mit unberechenbaren Layoutveränderungen verbunden – also praktisch unbrauchbar. Ganz davon abgesehen, dass diese manuellen Änderungen einen sehr hohen Zusatzaufwand bedeuten und an Arbeiten denken lassen, die eher an ein Strafgefangenlager erinnern als an freiwillig gewählte Erwerbsarbeit.

Kurz und gut: Selbst wenn der Autor also sauber und korrekt in Word gearbeitet hat, entsteht Zusatzaufwand:

• durch eine unvollständige oder unzuverlässige Konvertierung

• durch die Zwischenprüfung und die finale Prüfung: auch für das Prüfen gilt, dass hier ein Knopfdruck nicht genügt. Automatische Prüftools sind unterstützende Werkzeuge bei der Prüfung, können aber ein manuelles Prüfen und eine Beurteilung durch einen Menschen nicht ersetzen.

• durch Nacharbeiten in Acrobat Professional: Acrobat Professional ist einer der wenigen Editoren zum Bearbeiten barrierefreier PDF-Dateien. Als Zusatzaufwand muss man hier immer auch das Knowhow einkalkulieren, mit diesem komplexen Programm arbeiten zu können.

Der Zusatzaufwand aus den Phasen 5 bis 8 kann manchmal sogar die Zeit übersteigen, die der Autor für das Verfassen des Dokumentes (in den Phasen 1 bis 4) investiert hat. Dass dies einer nachhaltigen Lösung nicht gerade zuträglich ist und den Kosten-Nutzen-Aspekt in den Mittelpunkt rückt, kann man sich denken.

Qualitativ hochwertige PDF-Dokumente zu erstellen erfordert ein vertieftes Fachwissen vor allem für Nacharbeit und Prüfung. Dazu zählt das Arbeiten am Tag-Baum beziehungsweise in der Strukturansicht in Acrobat. Ein Problem dabei ist, wenn man es nur ab und zu macht, wird man nie richtig gut und schnell dabei.

Zum Unvermögen der vorhandenen Werkzeuge kommt noch Pech dazu

Ok, keiner ist perfekt, könnte man hier sagen. Das gilt erst recht für Software-Produkte. Und trotzdem: wenn es um barrierefreies Publizieren geht scheitern viele Textverarbeitungs- und Layoutprogramme an elementaren Funktionen oder an Funktionen, die nur halbherzig implementiert sind. Das sind keine kleinen Fehler mehr, die sich durch minimalen Zusatzaufwand ausbügeln lassen, sondern es geht hier letztlich um die Frage, ob ein effizienter Workflow und damit auch eine breite Akzeptanz für barrierefreies Publizieren möglich ist oder nicht.

Glück oder Pech – andere nennen es Schicksal – das hat im Leben seinen Platz. Doch leider auch beim Arbeiten mit barrierefreien PDF-Dateien. Es fehlt nicht nur an bestimmten Funktionen („Unvermögen“) es fehlt auch an Funktionen mit vorausschaubaren und damit zuverlässigen Ergebnissen („Pech“). Das Glücksspiel besteht darin, ob Elemente, die im Quelldokument an der richtige Stelle stehen, dort womöglich sogar mit Bordmitteln verankert wurden, auch im Tag-Baum des PDF an der beabsichtigten Stelle eingeordnet werden. Denn selbst wenn man in Word richtig arbeitet, kann man nicht sicher sein, was im PDF herauskommt: das gilt beispielsweise für die Position von Bildern, Marginalien, Textrahmen oder Fußnoten.

Die nachhaltige Lösung

Die zentrale Frage lautet also: Wie müsste eine nachhaltige Lösung aussehen? Eine nachhaltige Lösung, die den Zusatzaufwand auf ein Mindestmaß reduziert – und zwar auf das saubere Arbeiten und das Anlegen von Barrierefreiheitsinformationen im Quelldokument (A) – müsste folgenden Anforderungen genügen:

• eine Kontrolle über die Tag-Erstellung und die Tag-Reihenfolge ist im Quelldokument möglich (beispielsweise über ein Mapping von Formatvorlagen zu Tags wie es rudimentär in Adobe Indesign möglich ist)

• eine Prüfung auf Barrierefreiheit müsste bereits im Quelldokument möglich sein

• Artefakte (Elemente, die keine inhaltliche Relevanz besitzen und deswegen weder im Tag-Baum enthalten sind noch von einem Screenreader vorgelesen werden sollen) müssten bereits im Quelldokument gekennzeichnet werden können

• alles,was ich in der Quelldatei bereits richtig mache, sollte auch korrekt ins PDF übernommen werden (beispielsweise Sprachauszeichnungen oder die Positionierung von Elementen)

• die Konvertierung kann mit einem Klick erledigt werden, ohne dass ich das barrierefreie PDF anschließend nacharbeiten muss

In Adobe Indesign lassen sich über die Mapping-Möglichkeit Absatzformate zu XML-Tags (und damit indirekt auch zu PDF-Tags) zuordnen.

Kein Wort zum Umfließen?

Dass ich das Umfließen mit keinem Wort erwähne, hat einen schlichten Grund: so wie Adobe die Umfließenfunktion in Acrobat und Reader implementiert hat, ist sie weder WCAG 2.0 konform noch ist sie in der Praxis brauchbar. Ihre Unbrauchbarkeit rührt gerade daher, dass sie auf der physischen Reihenfolge der Elemente und nicht auf der Tag-Reihenfolge beruht. Jeder, der einmal versucht hat, die Reihenfolge für die Umfließenansicht zu korrigieren, und ihm dabei Elemente verloren gegangen sind, weiß, wovon ich spreche. Soviel dazu an dieser Stelle. Das Thema Umfließen ist wichtig, deswegen wird es im Mai einen eigenen Artikel geben.

Fazit

Eine nachhaltige Lösung für das Erstellen barrierefreier PDF-Dokumente müsste das Ziel haben, die Phasen 5 bis 8 des bisherigen Workflow überflüssig zu machen. Eine aufwändige Nacharbeit am Tag-Baum wäre dann nicht mehr notwendig. Jeder, der Word korrekt verwenden kann, sollte in der Lage sein, auch ein barrierefreies und für alle nutzbares PDF-Dokument zu erstellen – nicht aufgrund seiner herausragenden Fähigkeiten oder durch zusätzlichen Aufwand, sondern einfach durch eine Software, die das tut, wozu Sie entwickelt wurde. Wahrheit macht barrierefrei.