Was ein PDF barrierefrei macht

Was Tags sind

Optisch ist eine PDF-Seite ein Satz von Zeichenanweisungen: Setze diese Glyphen an diese Koordinaten. Nichts darin sagt, welche Glyphen eine Überschrift bilden, welche zum selben Absatz gehören oder dass diese zwölf Textstücke Zellen einer Tabelle sind. Ein sehender Mensch schließt das alles aus Größe, Strichstärke und Position. Software kann das nicht.

Ein getaggtes PDF fügt einen parallelen Strukturbaum hinzu — Überschriften, Absätze, Listen, Tabellen, Abbildungen — ganz ähnlich der Struktur eines HTML-Dokuments. Damit kann assistive Technik „Überschrift Ebene 2“ ansagen, jemanden zwischen Abschnitten springen lassen, eine Tabelle nach Zeile und Spalte vorlesen und den Alternativtext einer Abbildung wiedergeben. Ohne ihn fällt dieselbe Software darauf zurück, aus dem Layout zu raten, und rät bei allem außer der einfachsten einspaltigen Seite falsch.

Drei weitere Dinge trägt die Tag-Ebene, die alle wichtig und von denen keines sichtbar ist:

• Die Lesereihenfolge, die nicht die Reihenfolge ist, in der gezeichnet wurde. Ein zweispaltiges Layout, das spaltenweise gezeichnet wurde, liest sich richtig; zeilenweise über beide Spalten gezeichnet, liest es sich als Unsinn — und sieht identisch aus.
• Der Alternativtext für Bilder, ohne den eine Abbildung als „Grafik“ angesagt wird und sonst nichts.
• Die Dokumentsprache, die einem Screenreader sagt, welche Ausspracheregeln er verwenden soll. Ein französisches Dokument, mit englischen Regeln gelesen, ist kaum zu verstehen.

Warum OCR keine Barrierefreiheit ist

Das ist das häufigste und teuerste Missverständnis, deshalb lohnt sich hier Deutlichkeit.

OCR über ein gescanntes Dokument laufen zu lassen, legt eine Ebene aus erkanntem Text hinter das Bild. Das Dokument wird durchsuchbar, der Text wird markierbar, und ein Screenreader liest jetzt etwas statt nichts. Das ist eine echte und große Verbesserung, und es ist keine Barrierefreiheit.

Was OCR erzeugt, ist ein undifferenzierter Wortstrom. Es weiß nicht, dass eine Zeile eine Überschrift war; es erzeugt eine Zeile Text. Es weiß nicht, dass eine Tabelle eine Tabelle ist; es erzeugt die Zellinhalte in der Reihenfolge, in der es sie abgetastet hat, was bei einer Tabelle häufig die falsche ist, und sagt sie ohne jeden Hinweis darauf an, zu welcher Spalte eine Zahl gehört. Es kann keinen Alternativtext für eine Fotografie schreiben, weil es nicht weiß, was auf der Fotografie zu sehen ist.

Also: OCR ist der notwendige erste Schritt bei einem Scan, und danach hat das Dokument immer noch nichts von der Struktur, die es benutzbar macht. „Wir haben OCR drüberlaufen lassen“ als „wir haben es barrierefrei gemacht“ zu behandeln, ist der Weg, auf dem Organisationen ein Dokumentenarchiv für konform halten, obwohl es das nicht ist.

Ein Dokument ehrlich prüfen

Einiges davon lässt sich schnell prüfen, und es lohnt sich, das zu tun, bevor du annimmst, eine Datei sei in Ordnung.

• Gibt es überhaupt Text? Versuche, einen Satz zu markieren. Lässt sich nichts markieren, ist die Seite ein Bild und braucht vor allem anderen OCR. Text aus einem PDF extrahieren beantwortet dieselbe Frage — ein leeres Ergebnis heißt, es gibt keine Textebene.
• Stimmt die Lesereihenfolge? Markiere den gesamten Text einer komplexen Seite und füge ihn in einen reinen Texteditor ein. Was du bekommst, kommt der Reihenfolge nahe, die ein Screenreader verwenden wird. Kommt eine zweispaltige Seite ineinander verschachtelt heraus, ist die Lesereihenfolge falsch, ganz gleich, wie sie aussieht.
• Ist es getaggt? Desktop-Betrachter zeigen das in den Dokumenteigenschaften, meist als „Tagged PDF: Ja/Nein“. Ein Nein ist eindeutig; ein Ja heißt nur, dass Tags vorhanden sind, nicht, dass sie richtig sind.
• Ist die Sprache gesetzt? Der Metadaten-Editor zeigt die auf Dokumentebene in der Datei gespeicherten Eigenschaften.

Automatische Prüfprogramme sind nützlich und auf eine bestimmte Weise begrenzt: Sie verifizieren, dass Strukturen vorhanden und wohlgeformt sind, nicht, dass sie richtig sind. Ein Prüfprogramm kann dir nicht sagen, dass eine Überschrift als Absatz getaggt wurde oder dass der Alternativtext einer Fotografie „image1.jpg“ lautet. Dafür braucht es einen Menschen.

Was Browser-Tools daran ändern können und was nicht

Ganz offen zu den Grenzen: iBuildPDF macht PDFs nicht barrierefrei, und kein Tool, das nur eine bestehende Datei bearbeitet, kann das wirklich. Barrierefreiheit entscheidet sich weitgehend dort, wo das Dokument verfasst wird — eine in einer Textverarbeitung zugewiesene Überschriftenformatvorlage wird beim Export zu einem Überschriften-Tag; Text, der in ein Textfeld getippt wurde, wird zu einem ungetaggten Fragment. Richtig aus der Quelle zu exportieren ist mehr wert als alles, was danach gemacht wird.

Was die Tools hier leisten können, ist die Vorarbeit und die Diagnose:

• OCR gibt einem Scan eine Textebene, und die ist die Voraussetzung für alles Weitere.
• Textextraktion zeigt dir, was eine Maschine tatsächlich sieht, einschließlich der Lesereihenfolge.
• PDF in Word bringt ein Dokument in einen Editor, in dem Überschriften, Alternativtexte und Tabellenstruktur richtig gesetzt und wieder exportiert werden können.
• Der Metadaten-Editor legt die Eigenschaften auf Dokumentebene offen, darunter den Titel, den assistive Technik zuerst ansagt.

Zwei Operationen verschlechtern die Barrierefreiheit aktiv, und beide werden manchmal aus guten Gründen gemacht: Seiten in Bilder umwandeln zerstört die Textebene vollständig, und Abflachen entfernt die interaktive Struktur der Formularfelder. Keines von beiden ist falsch, aber keines sollte auf ein Dokument angewendet werden, das jemand mit assistiver Technik lesen muss.

Gilt für ein Dokument eine gesetzliche oder vertragliche Anforderung an die Barrierefreiheit, sind die maßgeblichen Standards PDF/UA (ISO 14289) und die PDF-Techniken, die begleitend zu den WCAG veröffentlicht werden; beide sind unten verlinkt.