Testen von barrierefreien PDF-​Dokumenten = Vorlesen-Lassen?

Barrierefreie PDF-​Dokumente gehören immer häufiger zur Standardanforderung bei Veröffentlichungen. Es gibt viele verschiedene Wege, solche Dokumente zu erstellen. Das Ziel ist aber immer das selbe: Es soll für alle Personen ein gleichberechtigter Zugang hergestellt werden, egal wie sie das Dokument verwenden (später dazu mehr).

Das Erstellen von barrierefreien PDF-​Dokumenten ist aus meiner Sicht inzwischen weitestgehend keine Hexerei mehr, aber man benötigt ein gewisses Maß and Grundwissen, um dieser Aufgabe gewachsen zu sein. Egal, wie viel Wissen man hat, am Ende sollte das Ergebnis immer überprüft werden. Maßgebliches übergeordnetes Ziel dabei: Die Grundanforderung „gleichberechtigter Zugang für alle“ muss erfüllt sein, gemäß den gesetzlich verpflichtenden oder selbst gewählten Vorgaben. Eine Frage, die mir daher sehr häufig gestellt wird: Wie prüfe ich denn, ob ein PDF wirklich barrierefrei ist? In diesem Artikel möchte ich daher ein paar Dinge dazu ausführen, vor allem möchte ich auf ein paar klassische Mythen eingehen.

Ein paar Grundlagen zu barrierefreien PDFs

Es gibt verschiedene Richtlinien und Gesetze, die definieren, wie barrierefreie Inhalte auszusehen haben – beispielsweise: WCAG, PDF/​UA, BITV 2.0, BFSG, EN 301549, uvm. Im Kern haben diese Vorgaben einen sehr ähnlichen Inhalt. Sie adressieren Einschränkungen von bestimmten Zielgruppen, beispielsweise Blinden, Seheingeschränkten [in unterschiedlichsten Ausprägungen], aber auch Personen mit kognitiven oder motorischen Einschränkungen, denen mit bestimmten Maßnahmen begegnet werden soll. Nachfolgend die aus meiner Sicht und Erfahrung wichtigsten Kernpunkte (ich meine damit nicht die 4 WCAG Prinzipien, die ich mit Absicht außen vor lasse):

1. Semantik

Inhalte haben eine Bedeutung, und diese muss zusätzlich zum Inhalt transportiert werden – eine Überschrift muss beispielsweise als Überschrift wahrnehmbar sein, anders als ein normaler Fließtext. Andere Beispiele sind Listen, Bilder, Tabellen. Ohne Semantik kann man die Inhalte nicht sinnvoll unterscheiden.

Übertragen auf ein Layout würde eine fehlende Semantik bedeuten, dass alle Texte gleich aussehen (Schriftart, ‑größe, ‑schnitt, ‑farbe), egal ob sie eine Überschrift oder ein Fließtext sind. Sich in einem solchen Dokument zurechtzufinden, dürfte schwierig sein. Deswegen hebt man beispielsweise Überschriften durch eine dem restlichen Text gegenüber abgehobene Gestaltung hervor. Das ermöglich eine einfache Orientierung.

2. Reihenfolge

Die redaktionell gewünschte Ausgabe-​Reihenfolge muss definiert sein, um eine logische Abfolge des Inhaltes zu gewährleisten (was die „richtige“ Reihenfolge ist, kann diskutabel sein – ein anderes Thema). Viele Dokumente im hiesigen Sprachraum werden von oben links nach unten rechts wahrgenommen, warum muss man sich also mit dem Thema dennoch beschäftigen? Ganz einfach, weil es eben oft genug Abweichungen von diesem Schema gibt. Ein simples Beispiel wäre ein Bild, das von einem Text umflossen wird, und dabei die gewünschte Stelle, an der das Bild wahrgenommen werden soll, ist dabei nicht immer klar. Noch wichtiger wird dies bei stark gestalteten Publikationen wie Zeitschriften.

3. Alternativtexte

Alle relevanten bildhaften Elemente müssen über einen Ersatztext beschrieben werden. Ich sage mit Absicht Ersatztext und nicht Alternativtext, da in PDF der klassische Alternativtext nur eine von mehren technischen Möglichkeiten ist, auch wenn der Alternativtext die sicher am meisten eingesetzt Methode darstellt. Ein solcher, den Bildinhalt beschreibender Text ist beispielsweise wichtig, damit auch blinde Personen den Inhalt von visuellen Elementen wahrnehmen können.

4. Kontrast

Personen mit bestimmten Seheinschränkungen können bestimmte farblich gestaltete Elemente nicht gut wahrnehmen oder unterscheiden – beispielsweise haben Sie eine Rot-​Grün-​Sehschwäche und sehen beide Farben als Brauntöne. Hinweis: Dies ist beispielsweise eine Anforderung, die nicht in allen Richtlinien als Pflicht hinterlegt ist.

5. Weitere Anforderungen

Es gibt noch sehr viele weitere Anforderungen, die ich wegen der Fokussierung auf das Kernthema nicht weiter ausführen werde.

Die genannten Anforderungen 1–4 sind die Basis für die im Folgenden angesprochenen Inhalte zum Testen von barrierefreien PDF-Dokumenten.

Testmythen

Auf die oben genannten Anforderungen hin müssen PDFs erfolgreich getestet werden, um als »technisch barrierefrei« klassifiziert werden zu können. Leider wissen nur wenige, wie sinnvoll getestet werden kann. Im Netz kursieren viele Tipps und Anleitungen, von denen ich die häufigsten ich nachfolgend beschreibe, kritisch einschätze und Empfehlungen ausspreche.

Mythos 1: Vorlesen-​Lassen ist das beste Testverfahren!?

Das barrierefreie PDF-​Dokumente auf ihrer Korrektheit geprüft werden müssen, ist den meisten Leuten, die damit zu tun haben (egal ob erstellende Personen oder Auftraggebende) klar. Nur wissen sie meist nicht, wie man das macht. Die vermeintlich schnelle Lösung bietet eine Suche im Internet, oder man versucht, sich in die Nutzenden herein zu versetzen. Das Ergebnis ist häufig: Für viele bedeutet das, dass nur blinde Personen ein barrierefreies PDF benutzen, also muss man sich das Ganze vorlesen lassen, um die Korrektheit zu überprüfen. Aber stimmt das denn?

Es gibt einige Kollegen von mir, die das als sinnvolles, teilweise einziges Testverfahren ansehen. Ich bin hier anderer Meinung. Vorlesen lassen kann ein Mittel zum Testen sein. Man sollte sich dabei aber bewusst sein, dass das Ganze aus verschiedenen Perspektiven aber problematisch sein kann und mit Einschränkungen verbunden ist. Auf die wichtigsten Gründe, warum Vorlesen zum Testen schlecht oder nur bedingt geeignet ist, möchte ich im folgenden eingehen.

1. Sofern man sich ein PDF vorlesen lässt, muss man dies auf die richtige Art und Weise machen. Dafür ist es wichtig, nicht nur ein barrierefreies PDF zu benutzen, sondern es muss auch eine Software benutzt werden, die das barrierefreie PDF korrekt verarbeiten kann. Das betrifft sowohl das PDF-​Anzeigeprogramm, als auch die Software, die die Ausgabe steuert (Solche Software wird auch Assitive Technologie [AT] genannt).
   Das ist meistens schon ein großes Problem, weil sich viele Personen das PDF mit der Vorlesefunktion von Adobe Acrobat oder im Browser vorlesen lassen. Diese Programme sind leider fast nie nicht in der Lage, das PDF korrekt auf der barrierefreien Ebene auszugeben (und es ist auch keine echte AT). Beispielsweise wird die Semantik hier nicht transportiert.
   Nutzt man diese Methode, kann man also dem Ergebnis nur sehr bedingt vertrauen und es hat wenig Aussagekraft, da wichtige Grundanforderungen nicht geprüft werden können.
2. Nutzt man eine „korrekte“ Assistive Technologie (beispielsweise NVDA oder JAWS), muss man diese erst zu bedienen lernen. Macht man das nicht, kann auch hier das Ergebnis verfälscht werden. Das Erlernen einer solchen Software und das Üben der Nutzung kostet einiges an Zeit.
3. Hat man auch dies gemeistert, so verbleiben dennoch einige, in meinen Augen große, Einschränkungen. Das größte Defizit in meinen Augen ist die reine Beschränkung auf die Nutzendengruppe der Blinden und deren Bedürfnisse – meist mit dem Ziel: „Klingt es schön?“.
   Andere Einschränkungen (siehe oben, und davon sind weit mehr Personen betroffen) werden bei diesem Testverfahren außen vorgelassen. Weiterhin ist es auch sehr schwer möglich, auf adäquate Art und Weise die Korrektheit von Reihenfolge und Alternativtexten zu prüfen. Es gibt noch einige weitere Hürden und Einschränkungen, mit teils gravierenden Auswirkungen.
4. Mein Hauptargument, warum ich vom Testen mit einer Vorlesefunktion abrate, ist der Zeitaufwand. Haben Sie ein mehrere 100 Seiten, großes Dokument und wollen dies per Vorlesefunktion testen, müssen Sie sehr viel Zeit aufwenden. Barrierefreiheit sollte aber möglichst von allen gelebt werden können und nicht zu einer großen Bürde werden.
5. Vorlesen führt häufig auch zu einer vermeintlichen Optimierung des barrierefreien PDF-​Dokumentes in Richtung einer optimierten Vorlesefunktion. Im Ergebnis steht dann meist nur ein PDF, das mit einer Assistiven Software vermeintlich „schön„vorgelesen wird. Verwendet man eine andere Software zur Ausgabe, kann das Ergebnis sogar schon anders aussehen.
6. Teilweise werden auf Basis des Vorleseergebnisses Dokumente sogar so verändert, dass etwas anderes ausgegeben wird, als im Dokument sichtbar ist – in der vermeintlichen Absicht, den Blinden etwas Gutes zu tun. Dies ist teilweise sogar kontraproduktiv und widerspricht auch dem Grundsatz eines gleichberechtigten Zugangs. Alle Personen sollten Zugriff auf die selben Informationen haben können – ob Sie sich das Dokument nun vorlesen lassen oder mit Ihren Augen wahrnehmen.

Damit ich nicht falsch verstanden werde: Vorlesen kann weiterhin ein Mittel zum Überprüfen sein. Man sollte sich jedoch bewusst sein, wie ein solcher Test im Detail technisch funktioniert und welche Einschränkungen es gibt. In meinen Augen sollte es nie das erste und auch nicht das zentrale Prüfmittel sein.

Mythos 2: Alternativ Texte prüft man mit dem Tooltipp von Acrobat!?

Bei der Überprüfung von Alternativtexten verlassen sich viele auf den so genannten Tooltipp/​Quickinfo von Acrobat. Hierbei fährt man mit der Maus über ein Bild und Acrobat präsentiert in einem kleinen Fenster den Inhalt des Alternativtextes.

Prinzipiell ist dies für Leute ohne große Vorkenntnisse ein sehr angenehmer Weg, Alternativtexte zu prüfen. Dennoch muss ich von diesem Weg leider abraten, denn die Funktion ist nur sehr unzuverlässig in Acrobat implementiert. Sie hat beispielsweise Probleme bei sich überlagernden Bildern, bestimmten Effekten (beispielsweise Schatten) und Vektorgrafiken. Hier wird häufig von Acrobat ein falscher oder gar kein Alternativtext angezeigt. Man sollte nie unzuverlässige Testmethoden einsetzen.

Mythos 3: Man prüft dir Reihenfolge mit den Reihenfolge-​Fenster in Acrobat!?

Obwohl Adobe das PDF Format erfunden hat, und Acrobat wahrscheinlich das am meist genutzte Programm zur Anzeige von PDFs ist, sollte man hier kein blindes Vertrauen in Software und Hersteller haben. Auf den Hilfeseiten zu Acrobat, aber beispielsweise auch InDesign, gibt es einige Erläuterungen, denen ich leider vehement aus fachlicher Sicht widersprechen muss (gestützt wird meine Meinung auch durch die gängigen Richtlinien und Normen).

Ein Beispiel dafür ist eine sehr unglückliche Übersetzung in der deutschen Acrobat-​Version. Hier gibt es das Navigationsfenster Reihenfolge. Wie ich bereits ausgeführt habe, muss in einem barrierefreien PDF die Reihenfolge korrekt hinterlegt sein. Was liegt also näher, als mit diesem Fenster in Acrobat Acrobat die Reihenfolge zu prüfen?

PDF ist ein komplexes Format, und wer sich damit schon mal intensiver beschäftigt hat, der weiß, dass es in einem PDF nicht nur eine Reihenfolge geben kann (neben der Reihenfolge für barrierefreie PDFs gibt es auch die Reihenfolge der Inhalte: meist so, wie die Erstellungssoftware den Inhalt der Seite nacheinander „malt“). Und vielleicht ahnen Sie es schon: das Navigationsfenster Reihenfolge zeigt leider nicht die für die Barrierefreiheit relevante Reihenfolge an. Dies geschieht ausschließlich im Navigationsfenster Tags.

Neben diesem kleinen Übersetzungsfehler kommt zusätzlich erschwerend dazu, dass Adobe auf ihren Hilfeseiten behauptet, dass das Navigationsfenster Reihenfolge durchaus relevant wäre für ein barrierefreies PDF. Dies ist aber falsch bzw. wider allen gängigen Normen und Standards. (Zur Entlastung von Adobe muss man sagen, dass das Navigationsfenster Reihenfolge durchaus einen gewissen Vorteil für eine gewisse Art der Ausgabe in Acrobat haben könnte, jedoch aufgrund von massiven Programmeinschränkungen nur sehr bedingt benutzt werden kann. Ich hoffe auf Besserung).

Nutzen Sie also bitte ausschließlich die im PDF definierte Tag-​Reihenfolge zur Überprüfung der Reihenfolge eines barrierefreien PDF-Dokumentes.

Mythos 4: Die Vollständige Prüfung der Barrierefreiheit in Acrobat sagt mir, ob alles stimmt!?

Acrobat hat schon seit sehr langer Zeit eine eingebaute Prüfung auf Barrierefreiheit (die Namen dieser Funktion haben über die Jahre stark variiert, das Prinzip und die Funktionsweise ist seit langer Zeit aber identisch geblieben). Startet man diese Prüfung, kann man ein paar nicht genau definierte Kriterien auswählen, gemäß welcher man das Dokument überprüfen möchte. Als Ergebnis der Prüfung erscheint ein Ergebnisbericht.

Diese Prüfung kann ich leider nur bedingt empfehlen. Zum einen deckt sie nur in Teilen die gängigen Richtlinien ab. Bestimmte relevante Anforderungen werden nicht überprüft (das PDF könnte also durchaus relevante Fehler enthalten). Weiterhin kann die Prüfung auch Fehler rückmelden, obwohl ein perfektes barrierefreies PDF vorliegt. Was genau wie geprüft wird, ist auch nicht vollständig offen gelegt.

Ebenso erfolgt nur eine automatische Prüfung. In allen gängigen Testverfahren in Bezug auf Barrierefreiheit ist dies jedoch nicht ausreichend. Beispiel: Im Dokument ist ein Bild, welches eine Banane abbildet; als Ersatztext ist aber „Apfel“ hinterlegt. Die Software würde dies nicht als Problem erkennen, denn sie prüft nur, ob ein Ersatztext vorhanden ist, und nicht, ob dieser auch passend ist. Um solche und andere Probleme erkennen zu können, muss das Dokument manuell überprüft werden – was von Acrobat leider nicht gut unterstützt wird.

Mythos 5: So muss ein barrierefreies PDF aussehen!?

In der langen Zeit, in der ich mich mit barrierefreie PDFs beschäftige, habe ich schon einige Vorgaben von Kunden, Auftraggebern und Kollegen gesehen, die mich haben staunen lassen. Warum? Weil sie in den Bereich der Mythen gehören und meist einfach immer weitergetragen werden, ohne hinterfragt zu werden. Ein paar Beispiele immer noch gängiger Mythen:

1. Weißer Text ist verboten!
   Stimmt es? Nein!
   Der Ursprung liegt in Acrobat, aber in keiner Richtlinie ist davon etwas zu finden.
2. Wenn es ein Bild plus eine Bildbeschriftung gibt, kann ich eines davon in der Ausgabe einfach weglassen!
   Stimmt es? Nein!
   Jeder Nutzende darf selbst entscheiden, was es sich ansehen oder lesen will.
3. Fußnoten sind nicht erlaubt!
   Stimmt es? Nein!
   Man kann eigentlich alles in ein barrierefreies PDF packen, was man möchte. Im Prinzip sogar Tabellen in Fußnoten.
4. Jeder Link braucht einen Alternativtext!
   Stimmt es? Jein!
   Unterschiedliche Normen und Richtlinien machen hier unterschiedliche Vorgaben – zum einen, ob es das geben muss, zum anderen, wie man es umsetzen soll. Fakt ist: In PDFs sollte man für einem Link nie einen Alternativtext vergeben. Das ist weder konform zu PDF-​Norm selbst, noch erfreut es die Nutzenden, da relevanter Inhalt (meist die eigentliche URL) verloren geht (man kann auch sagen „überschrieben wird“). Genutzt werden sollte hier der sogenannten Contents-​Eintrag (eine der Ersatztextformen in PDF).
5. Den Titel muss man als <H1> taggen!
   Stimmt es? Jein!
   Man kann den Titel semantisch als <H1> kennzeichnen, ich und viele meiner versierten Fachkollegen raten aber zur Nutzung des Tags <P>. Da mag jetzt merkwürdig klingen, aber es hat gute Gründe. Wer dazu mehr erfahren will, der kann einen Fachbeitrag von mir dazu lesen (englisch: https://​pdfa​.org/​h​o​w​-​t​o​-​t​a​g​-​t​i​t​l​e​s​-​i​n​-​p​d​f​-​d​o​c​u​m​e​n​ts/) oder sich das Referenzwerk zum Taggen zu Gemüte führen (englisch: https://​pdfa​.org/​r​e​s​o​u​r​c​e​/​t​a​g​g​e​d​-​p​d​f​-​b​e​s​t​-​p​r​a​c​t​i​c​e​-​g​u​i​d​e​-​s​y​n​t​ax/).

Wie prüft man nun richtig?

Bei der Prüfung von barrierefreien PDF Dokumenten muss als erstes definiert werden, an welcher Norm, Richtlinie oder welchem Gesetz man sich orientieren möchte. Diese definiert im weiteren Testverlauf, welche Software oder Techniken man einsetzen kann und welche weiteren Prüfschritte unternommen werden müssen.

An erster Stelle sollte in jedem Fall eine automatische Prüfung stehen. Ich setze dafür maßgeblich den PDF Accessibilty Checker (PAC) ein (siehe https://​pac​.pdf​-accessibility​.org/de), aber auch den PDF/​UA-​Preflight von Acrobat und veraPDF. Die automatische Prüfung testet, ob alle technischen Anforderungen erfüllt sind (beispielsweise: ein Bild hat einen Alternativtext). Im zweiten Schritt sollte eine manuelle Prüfung erfolgen, die festellt, ob auch alles korrekt umgesetzt wurde (beispielsweise ein Bild hat den richtigen Alternativtext). Diese Methode wird ebenso durch den PAC per sogenannter Screenreader-​Vorschau unterstützt. Sinnvoll ist hier – gerade am Anfang als Unterstützung – der Einsatz von Checklisten.

Das genaue Testverfahren für beide Schritte – also die automatische und die manuelle Prüfung –, kann leider durchaus etwas komplexer sein und je nach Art und Typ des Dokumentes unterschiedlichste Arbeitsschritte erfordern. Darum sind weiterführende Empfehlungen an dieser Stelle nicht möglich bzw. nicht sinnvoll. Schließlich möchte ich vermeiden, durch falsch interpretierte Simplifizierungen selbst Quelle für irgendwelche Mythen rund um barrierefreie PDFs zu werden. Wenn Sie lernen wollen, wie man korrekt barrierefreie PDF-​Dokumente überprüft, verweise ich gern auf die regelmäßig stattfindenden Webinare des Anbieters der PAC-​Software, axes4 (siehe https://​www​.axes4​.com/​d​e​/​e​v​e​nts).

Sollte Ihnen dies als Input nicht ausreichen, und sie eine individuelle Betreuung benötigen – beispielsweise eine individuelle Einschätzung, welche Prüfschritte und ‑methoden für Ihr Dokument und für Ihre Anforderungen sinnvoll und richtig sind –, können wir dazu gerne auch einen Beratungstermin oder einen passenden Workshop vereinbaren. Kontaktieren Sie mich dazu gern.