Barrierefreie PDF-Dokumente lassen sich nicht auf Knopfdruck erzeugen. Um die Zugänglichkeit für die Benutzer sicherzustellen, gilt es die erstellten PDFs genau zu prüfen und noch verbleibende Hindernisse manuell zu beseitigen.

Menschen mit Behinderungen können viele PDF-Dokumente nicht oder nur teilweise lesen. Dabei lassen sich mit nur wenig Aufwand für jedermann zugängliche PDFs erstellen. Der erste Teil dieses Beitrags in der letzten Ausgabe zeigte, mit welchen Hürden unbedacht erstellte PDFs Menschen mit Behinderungen das Leben schwer machen und mit welchen Werkzeugen sich barrierefreie PDFs erstellen lassen.

Das korrekte Erzeugen eines weitgehend barrierefreien PDFs stellt aber erst die halbe Miete dar: Nun gilt es die Qualität des Dokuments zu prüfen und gegebenenfalls nachzubessern. In diesem Teil des Workshops stellen wir die dazu nötigen Werkzeuge und Verfahrensweisen vor. Außerdem untersuchen wir, wie gut die verschiedenen Lesewerkzeuge mit unserem Erzeugnis zurecht kommen und wo sie Schwachstellen aufweisen.

Barrierefreiheit prüfen

Um sicherzustellen, dass ein PDF-Dokument wirklich barrierefrei ist, gilt es zwei Merkmal sicherzustellen: zum einen die Standardkonformität nach PDF/A-1a und zum zweiten die allgemeine Zugänglichkeit. Letzteres mag paradox erscheinen, sollte doch eigentlich ein Dokument nach PDF/A-1a schon barrierefrei sein – doch wie Sie noch sehen werden, ist das leider nicht zwingend der Fall.

Die formale Prüfung allein reicht jedoch noch nicht aus, um die Barrierefreiheit eines Dokuments zu gewährleisten. Der Prüfschritt 11.1.1 des BITV-Tests [1] verlangt eine genaue Untersuchung, wobei die Fragen über technisch prüfbare Methoden hinausgehen. Der Test hinterfragt bereits die Intention, ein PDF-Dokument überhaupt online zu stellen: PDF sollen nur zum Einsatz kommen, wenn “das Format für die Erfüllung der angestrebten Aufgabe gebraucht wird, die gewünschte Eigenschaft also nicht per HTML zur Verfügung gestellt werden kann. PDFs müssen barrierefrei sein oder es muss eine HTML-Alternative zur Verfügung gestellt werden”.

Da der aktuelle BITV-Test noch auf WCAG 1.0 basiert und erst die Neufassung WCAG 2.0 [2] gehörlose Menschen berücksichtigt, müsste man den Satz eigentlich um die Formulierung “… oder es muss ein Gebärdensprachvideo zur Verfügung gestellt werden” ergänzen. Schritt 11.1.1 des BITV-Test schreibt für PDF-Dokumente die folgenden Prüfungen vor:

• Information über die Barrierefreiheit von angebotenen PDFs,
• PDF-Dokumente für die Prüfung auswählen,
• PDF-Dokument oder HTML-Alternative prüfen,
• Prüfung der (generierten) HTML-Alternative,
• Prüfung der direkten Zugänglichkeit des PDFs.

Der letzte Punkt, das Prüfen der direkten Zugänglichkeit des PDFs, umfasst wiederum eine ganze Reihe von Unterschritten. Hier gilt es unter anderem zu prüfen:

• formale Mängel,
• Tagging,
• Reihenfolge der Tag-Struktur,
• Schriftvergrösserung (Umfließen-Modus),
• Alternativtexte,
• Tabellen,
• Lesezeichen,
• Strukturierung, sowie
• die Hauptsprache.

Die Barrierefreiheit beginnt bereits bei der Planung und setzt sich über die logische sowie sprachliche Struktur bis hin zur technischen Umsetzung fort. Zur Prüfen und Korrigieren von PDF/A-1a-Dokumenten existiert bislang noch kaum freie Software. Daher kommt man hier nicht umhin, neben freier auch proprietäre Software einzusetzen: Bis auf eines handelt es sich bei allen im Folgenden genannten Programmen umd kostenpflichtige Software.

Zum Vergleich exportierten wir unser Testdokument zum einen in ein einfach getaggtes PDF-Dokument und zum anderen in eine Datei im Format PDF/A-1a. Beide untersuchten wir dann mithilfe der verfügbaren Prüfwerkzeuge.

Werkzeugkasten

Neben dem oben bereits erwähnten Angebot seitens des BITV [1] bietet der Hersteller Intarsys eine kostenfreie Prüfung für PDF/A-Dokumente an [3]. Diese meldete uns in der einfach getaggten Version fünf Fehler und zehn Warnungen (Abbildung 1). In der PDF/A-1a-Datei entdeckte das Werkzeug zwei Fehler und neun mögliche Schwachstellen (Abbildung 2).

Abbildung 1: Das Prüfergebniss des Intarsys-Werkzeugs für unser lediglich getaggtes PDF …

Abbildung 2: … und die entsprechende Ausgabe für das PDF/A-1a-Dokument.

In der Voreinstellung erkennt Adobe Acrobat PDF/A-Dokumente und stellt sie automatisch im PDF/A-Modus dar. Die Konformität prüfen Sie unter dem Karteireiter Standards. Ein Klick auf Konformität prüfen führt zu einem positiven Ergebnis (Status Überprüfung erfolgreich), der Acrobat erkennt unsere Datei als PDF/A-1a-Dokument.

PDFTron Systems bietet als Produkt den PDFA-Manager an, den Sie auch als Testversion für Linux kostenlos von deren Webseite beziehen können [4]. Die entsprechende Binärdatei läuft problemlos unter einem aktuellen Debian oder Ubuntu. Sie prüfen ein damit ein PDF mit dem Kommando:

$ pdfa -l A Datei.pdf

Die Option -l A legt fest, dass der PDFA-Manager die Datei auf ihre Konformität zum PDF/A-1a-Standard prüft. Geben Sie stattdessen -l B an, untersucht er das PDF auf die Übereinstimmung zu PDF/A-1b. Die beiliegende Dokumentation beschreibt alle Optionen ausführlich.

Bei unseren Testdokumenten beandstandet der PDFA-Manager die PDF/A-1a-Version nicht, findet bei der einfach getaggten Datei jedoch drei Fehler. Das Ergebnis der Analyse stellt das Tool in Form einer XML-Datei mit passendem XSL-Stylesheet bereit, sodass sich der Report in einem Webbrowser begutachten lässt (Abbildung 3).

Abbildung 3: Ergebnis der Prüfung eines getaggten PDF-Dokuments mithilfe des PDFA-Managers.

Prüfung der Barrierefreiheit

Nun wollten wir es ganz genau wissen – können unsere Dokumente jetzt wirklich als barrierefrei gelten oder nicht? Dazu setzten wir als nächstes den PDF Accessibility Checker (PAC, [5]) auf die PDFs an.

Das erst vor kurzem veröffentlichte Werkzeug stammt von der schweizer Stiftung Zugang für Alle [6]. Es validiert ein PDF-Dokument auf Grundlage der PDF-Spezifikation [7] auf Barrierefreiheit und stellt das Ergebnis graphisch dar. Dabei markiert es die Problemzonen farblich, um sie optisch möglichst deutlich aufzuzeigen. Leider läuft PAC zurzeit ausschließlich unter Windows, ein ähnliches Programm für Linux existiert nicht. PAC testet die im Kasten “PAC: Testkriterien” aufgeführten Merkmale.

Bei der Prüfung trat zunächst ein Problem zutage: Im ersten Versuch erstellten wir PDF-Dokumente mit Kommentaren. Damit scheiterte die Überprüfung jedoch, PAC stürzte ab. Wir erstellten also das endgültige Testset (PDF/A-1a und nur getaggt) ohne Kommentare. Bei beiden Dokumenten stellte PAC in einem Kurzreport folgende drei fehlgeschlagene Erfolgskriterien (Abbildung 4) fest:

• Fehler: Tab folgt Dokumentstruktur
• Warnung: Logische Lesereihenfolge
• Fehler: korrekte Syntax von Tags/Rollen

Abbildung 4: Das Prüfergebnis von PAC für unser Testdokument.

Sowohl die beiden Fehler als auch die Warnung beschrieb PAC in einem Bericht ausführlicher. So monierte er als Fehler, dass die Tab-Reihenfolge von Seite 1 sich nicht nach der Dokumentstruktur richte und die Tag-Struktur ein ungültiges untergeordnetes Element aufweise. Die Warnung hinsichtlich der logischen Lesereihenfolge bezog sich auf einen Tippfehler in einer Überschrift (Mögliches Problem mit der Reihenfolge auf Seite 1 gefunden: 1.1Überschrift).

Bei PAC handelt es sich lediglich um ein Analysewerkzeug. Um nun die gefundenen Fehler zu korrigieren, steht derzeitig lediglich Adobe Acrobat zur Verfügung. Der freie PDF-Editor PDFedit [8] verfügt nicht über die notwendigen Funktionen zur Accessibility-Bearbeitung.

Prüfen in Adobe Acrobat

Aufgrund der Voreinstellung zeigt Adobe Acrobat unser Dokument zunächst im PDF/A-Modus an, in dem er aber eine weitere Bearbeitung nicht zulässt. Daher schalten wir den Modus zunächst über Bearbeiten | Voreinstellungen | Dokumente: PDF/A-Anzeigemodus | nie ab.

Ausserdem gilt es mithilfe der Komponente Preflight die PDF/A-Informationen zunächst aus dem Dokument zu entfernen. Der entsprechende Dialog versichert dabei, die PDF-Datei ließe sich später ganz einfach wieder nach PDF/A wandeln (Abbildung 5). Das Prüfen der Barrierefreiheit erfolgt nun über Erweitert | Ein-/Ausgabehilfe | vollständige Prüfung. Als Ergebnis erhielten wir die Mitteilung Fehler: Tab-Reihenfolge stimmt möglicherweise nicht mit der Ordnungsstruktur überein.

Preflight-Dialog für unser Testdokument in Adobe Acrobat.” width=”300″ height=”81″ /> Abbildung 5: Der Preflight-Dialog für unser Testdokument in Adobe Acrobat.

Korrekturlauf

Zur Korrektur der Tab-Reihenfolge öffnen wir die einzelnen Seiten über den Karteireiter Seiten und danach über einen Rechtsklick auf das gewünschte Dokument den zusätzlichen Dialog Tab-Reihenfolge. Wir wählen dort den Punkt Dokumentstruktur verwenden aus (Abbildung 6).

Abbildung 6: So funktioniert das Festlegen der Tab-Reihenfolge in Adobe Acrobat.

Eine weitere vollständige Prüfung im Acrobat ergibt nun zu unserer großen Freude ein fehlerfreies Dokument. In PAC bleiben jedoch nach wie vor die Warnung und die zweite Fehlermeldung bezüglich von Syntax und Tags bestehen.

Eine Überprüfung der Lesereihenfolge zeigt, dass im Testdokument die Grafik an das Ende geschoben wurde (Abbildung 7). Das betrifft nicht den Tag-Baum, sondern nur die Reihenfolge, in der ein Screenreader den Dokumentinhalt vorliest.

Abbildung 7: In der Lesereihenfolge steht die Grafik nun an der letzten Stelle.

Hier muss der Autor nun entscheiden, ob die Grafik notwendigerweise zum Textverständnis an anderer Stelle stehen muss. Ansonsten lässt sich die Warnung ignorieren, da der Rest des Textes ja in korrekter Reihenfolge gelesen wird.

Die letzte Fehlermeldung hinsichtlich der Rollen und Tags ist etwas komplizierter zu lösen (siehe dazu auch Kasten “Rollen und Tags”). Zunächst korrigieren wir die Tag-Reihenfolge der Grafik und entfernen das DIV-Element. Eine weitere Prüfung führt nun aber zu einer neuer Fehlermeldung, Acrobat beschwert sich nun über ein unvollständiges P-Element (Abbildung 8).

Abbildung 8: Die Prüfung in Adobe Acrobat bemängelt ein fehlendes Tag.

Nachdem dem Entfernen des leeren P-Elements zeigt sich nun auch PAC mit dem Dokument zufrieden. Ein abschliessender Test für Menschen mit Sehbehinderungen – die fehlerfreie Darstellung des Dokumentes im Umfliessenmodus – läuft erfolgreich ab. Alle Elemente, auch die Tabelle, erscheinen in korrekter Reihenfolge (Abbildung 9).

Abbildung 9: Der abschließende Test des PDFs im Umfliessenmodus verläuft erfolgreich.

Rollen und Tags

Ein spezielles Konstrukt barrierefreier PDFs stellt das System sogenannter Rollen und Tags dar. Rollen sind fest definiert, entsprechen in ihrer Benennung den Standard-Tags von Adobe und stellen die Hauptschnittstelle für den Screenreader dar.

Eine Rolle weist besondere Eigenschaften auf (ähnlich wie in HTML zum Beispiel Block-Level- und Inline-Elemente) und unterliegen bestimmten Restriktionen. Tags sind entweder in Form der Adobe-Standardtags fest definiert oder werden durch Autoren oder Autorenwerkzeuge frei benannt. Wichtig ist, alle Tags einer Standardrolle zuzuordnen. Für Abbildung 10 haben wir mit OpenOffice Writer eine verschachtelte Liste erstellt (rechts oben) und diese in Acrobat geprüft.

Abbildung 10: So sieht die Festlegung der Rollen in Adobe Acrobat aus.

Im Fenster Rollenzuordnung rechts unten in Abbildung 10 sehen Sie die in unserem Dokument verwendeten Rollen jeweils als Kombination des Tagnamens und der zugewiesenen Rolle. OpenOffice setzt fast alle Tag-Namen identisch mit ihrem Rollennamen – bis auf das Tag Standard, das die Rolle P hat.

In unserem Haupt-Testdokument wurden die Listen mit Der Screenreader Jaws 10 [9] las aus unserem Haupt-Testdokument die Listen korrekt aus. Bei anderen Screenreadern kann es aber vorkommen, dass sie entweder die Rolle oder sogar die Tagnamen auslesen. Bei einem vom Rollennamen abweichenden Tagnamen kann das zu fehlerhaften Zugriffen führen. Im Zweifelsfall schafft hier das Nachbearbeiten der Tagnamen Abhilfe.

Zurück zu PDF/A-1a

Bleibt noch zu korrigieren, dass ja nun kein standardkonformes PDF/A-1a-Dokument mehr vorliegt. Um das zu ändern, öffnen wir in Adobe Acrobat erneut Preflight und starten das Umwandeln mit einem Doppelklick auf PDF/A-1A konvertieren. Nach einer positiven Rückmeldung verläuft die erneute Konformitätsprüfung in Acrobat erfolgreich (Abbildung 11).

Abbildung 11: Nach dem Korrigieren der Fehler wandelt Adobe Acrobat das Dokument problemlos wieder zurück nach PDF/A-1a.

Ein erneutes Prüfen unseres Testdokuments durch den Online-Validierer von Intarsys ergibt nun allerdings neben sieben Warnungen (Abbildung 12) auch einen neuen Fehler. Die ursprünglich bemäkelten Punkte erweisen sich immerhin als korrigiert.

Abbildung 12: Der Prüfbericht des Intarsys-Werkzeugs weist nun weniger Fehlern aus als zuvor, wartet aber mit neuen Warnungen auf.

Da wir mit Werkzeugen der Freien Software schon vor den letzten Arbeitsschritten nicht weitergekommen sind, brechen wir die weiteren technischen Analysen an dieser Stelle ab.

Barrierefrei?

Weder das Vorhandensein von Tags garantiert noch das Einhalten von ISO-Standards garantieren letztlich die Barrierefreiheit eines PDF-Dokuments. Auch die einzelnen Prüfprogramme kommen zu unterschiedlichsten Ergebnissen. Wie zugänglich ein Dokument tatsächlich ist, stellt letztlich erst der Benutzer fest.

Deshalb sollten Sie beim Erstellen von barrierefreien Dokumenten im professionellen Rahmen unbedingt Menschen mit entsprechenden Einschränkungen als Tester in den Entwicklungsprozess einbinden. Sollte das aus Kostengründen nicht möglich sein, hilft ein Hinweis auf der Webseite des Dokuments. Er gibt den Nutzern die Möglichkeit, sich bei Problemen direkt an den Autor zu wenden.

PDF-Betrachter

Legt man als Ersteller PDFs auf Barrierefreiheit aus, gerät man unweigerlich in einen Zielkonflikt: Die ursprüngliche Konzeption des Formats bestand darin, eine identische Darstellung von Dokumenten auf möglichst allen Plattformen und Ausgabegeräten zu gewährleisten. Ein PDF-Dokument soll sich daher nachträglich nicht so leicht verändern lassen.

Im Gegensatz dazu macht Barrierefreiheit es notwendig, eine Anpassung der Darstellung an die individuellen Bedürfnisse des Anwenders zuzulassen. Das betrifft eine vergrösserte Darstellung, die Möglichkeit zum Verändern der Farben von Text und Hintergrund (Kontrast), die Extraktion des Texts, eine tastaturbasierte Navigation und die Erhaltung der Lesereihenfolge (Linearität) der einzelnen Abschnitte.

Unter Linux lassen sich alle diese Kriterien erfüllen, wenn auch in unterschiedlicher Qualität. So können Sie sowohl den Adobe Reader als auch Okular, den Dokumentenbetrachter von KDE SC 4, für einen kontrastreiche Darstellung mit individuellen Farbwerten konfigurieren.

In Adobe Reader verbergen sich die entsprechenden Optionen im Dialog Einstellungen unter dem Punkt Accessibility (Abbildung 13). Sie aktivieren die Settings, indem Sie im Dialogfenster die oberste Option Ersetze Dokumentfarben auswählen. Auch bei Okular finden Sie die enstprechenden Optionen unter Einstellungen | Accessibility (Abbildung 14). Die Anpassungen geschehen ohne Verzögerung im laufenden Betrieb (Abbildung 15).

Abbildung 13: Die Einstellungen zur Barrierefreiheit in Adobe Reader …

Abbildung 14: … und im Dokumentenbetrachter Okular von KDE SC 4.

Abbildung 15: So sieht die invertierte Darstellung in Okular aus.

In unseren Tests funktionierten die Optionen bei beiden Werkzeugen weitgehend einwandfrei. Im Adobe Reader traten bei PDF-Dokumenten, die mit LaTeX erzeugt wurden, Aussetzer in der Darstellung auf – einzelne Seiten blieben leer. Diese Aussetzer erscheinen willkürlich und lassen sich bisher weder eindeutig reproduzieren noch einer Ursache zuordnen.

Keine Möglichkeiten zu einer für sehbehinderte Menschen optimierten Anzeige bieten hingegen die Programme Ghostview, Epdfview, Xpdf und Evince. Bei allen diesen Dokumentenbetrachterb bleibt zudem die Qualität des Renderings für starke Vergrösserungen deutlich hinter jener von Adobe Reader und Okular zurück.

Sonstiges und Zukunft

Wie dieser Workshop verdeutlicht, gehört zum Erstellen barriefreier Dokumente wesentlich mehr als nur ein Mausklick. Viele Probleme aus dem Arbeitsalltag blieben in Rahmen dieses Artikels noch ungenannt. Auch das Verwenden von Standards wie etwa PDF/A-1a-konformer Dokumentes gewährleistet per se noch keine Barrierefreiheit. Sobald Sie ein ursprünglich ausschließlich für die grafische Ausgabe gedachtes Dokument barriefrei aufgearbeiten wollen, stoßen Sie schnell an Grenzen.

Gegebenenfalls müssen Sie dann auf den Standard verzichten und mithilfe der verbleibenden Möglichkeiten ein optimales Ergebnis zu erreichen versuchen. Dazu zählen das konsequente Verwenden von Formatvorlagen unter OpenOffice Writer, das Beachten der sprachlichen und inhaltlichen Konsistenz, das Zurückstellen nicht-informativer Inhalte und der Einsatz von Tagged-PDF. Am Ende der Kette steht derzeit das abschliessende Prüfen und Nachbearbeiten mithilfe meist proprietärer Werkzeuge. Ein Muss stellt die Verifikation durch betroffene Nutzer dar.

Das aufwändige Verfahren erweist sich als zusätzliche Stolperfalle auf dem Weg zu einem für alle Nutzer zugänglichen Dokument: Dem Autor unterlaufen schnell Fehler, die auch automatische Validierungswerkzeuge noch nicht erfassen können (etwa sprachliche Inkonsistenzen) und die deshalb unkorrigiert bleiben.

Wunschzettel

An der Züricher Hochschule für Angewandte Wissenschaften [10] wurde ein Plugin für Microsoft Office entwickelt, das den Benutzer daran erinnert, Formatvorlagen zu verwenden, die Auszeichnung fremdsprachiger Textteile vorzunehmen, das Labeling von Formularen zu prüfen und über die Anforderungen von PDF/A-1a informieren. Es wäre hilfreich, wenn OpenOffice über ein ähnliches Werkzeug verfügen könnte. Da der Prozess der Dokumentenerstellung in OpenOffice jedoch von jenem in MS-Office abweicht, müsste man noch klären, welche konkreten Inhalte dieser Assistent bieten soll.

Wir möchten außerdem an dieser Stelle an die Entwickler freier Software appellieren, beim Fortführen bestehender Projekte möglichst die Belange aller Nutzer mit einzubeziehen. Das betrifft nicht nur die Software an und für sich, sondern auch die dazugehörige Dokumentation. Da es sich um freie Software udn frei zugängliche Materialien handelt, haben alle die Chance, mit Änderungen beizutragen und Verbesserungen möglich zu machen.