PDF und Barrierefreiheit verstehen: Ein ehrlicher Überblick

Was PDF eigentlich ist – und was nicht

PDF steht für Portable Document Format und wurde ab 1991 von Adobe entwickelt. Seit 2008 ist PDF in der Version 1.7 als ISO 32000-1 ein offener Standard, die aktuelle Fassung ist ISO 32000-2 (PDF 2.0) von 2020. Die ursprüngliche Idee: ein Dateiformat, das ein Dokument auf jedem Gerät, in jedem Betriebssystem und in jeder Software visuell identisch darstellt.

Genau das ist die zentrale Eigenschaft von PDF – und gleichzeitig die größte Herausforderung für Barrierefreiheit. PDF wurde als Druck-Ersatz konzipiert. Es hält Position, Schriftart, Größe und Layout einer Seite fest, damit sie überall gleich aussehen. Diese Festlegung ist visuell ein Vorteil, semantisch aber zunächst ein Verlust: Im PDF stehen Pixel an Koordinaten, nicht „Überschrift", „Absatz" oder „Tabelle".

Die semantische Struktur muss in einem PDF nachträglich hinzugefügt werden – über sogenannte Tags. Ohne diese Tags ist ein PDF aus Sicht eines Screenreaders nur eine zusammengewürfelte Ansammlung visueller Elemente.

PDF und HTML: Zwei grundverschiedene Welten

Aus Sicht der Barrierefreiheit sind PDF und HTML zwei fundamental unterschiedliche Formate. Sie folgen verschiedenen Designphilosophien, und das wirkt sich auf jede Stufe der Zugänglichkeit aus.

Der zentrale Unterschied

HTML ist von Geburt an semantisch. Wer eine Überschrift <h1> schreibt, sagt damit zugleich: „das hier ist eine Überschrift erster Ordnung". Browser, Screenreader, Suchmaschinen – alle nutzen dieselbe Semantik unmittelbar.

PDF dagegen ist von Geburt an visuell. Wer in InDesign, Word oder LaTeX eine Überschrift formatiert, sagt damit nur: „das hier ist 24-Punkt-fett-Calibri an Position X". Erst durch das nachträgliche Tagging wird daraus „das hier ist eine Überschrift erster Ordnung". Bei jeder Konvertierung von der Quelldatei ins PDF kann diese semantische Information verloren gehen oder verfälscht werden.

Die Kette der Barrierefreiheit

Die tatsächliche Barrierefreiheit eines PDFs entsteht nicht durch die Datei allein. Sie ist das Ergebnis einer Kette von Komponenten – und jede Stelle in dieser Kette kann Zugänglichkeit verbessern oder zerstören.

Erstellungsseite: Wo Barrieren entstehen

Wie ein PDF entsteht, prägt seine Barrierefreiheit massiv. Die Qualität der Ausgangs-Software, die Sorgfalt bei der Strukturierung im Quelldokument und die Fähigkeiten der Konvertierungs-Engine entscheiden, wie viel Nachbearbeitung später nötig ist.

• Microsoft Word Bei korrekt verwendeten Formatvorlagen kann Word getaggte PDFs erzeugen. Die Qualität der Tags variiert allerdings je nach Word-Version und Komplexität des Dokuments.
  Knackpunkt: Wer Überschriften nur visuell formatiert (fett, größer), statt Formatvorlagen zu nutzen, erzeugt unstrukturierte PDFs – egal wie sorgfältig sonst gearbeitet wurde.
• Adobe InDesign Für anspruchsvolles Layout das verbreitetste Werkzeug. Tagging ist möglich, erfordert aber bewusste Auszeichnung von Absatzformaten, Artikel-Verkettungen und Lesereihenfolge im Dokument selbst.
  Knackpunkt: Visuelles Design und semantische Struktur müssen parallel aufgebaut werden – ein nachträgliches Tagging fertig gestalteter Dokumente ist aufwendig.
• LibreOffice / OpenOffice Kann seit Version 2 getaggte PDFs exportieren. Der Funktionsumfang für komplexe Strukturen ist gegenüber kommerziellen Werkzeugen eingeschränkter.
  Knackpunkt: Die Nachbearbeitungs-Möglichkeiten im PDF sind in Open-Source-Tools deutlich begrenzter als in spezialisierten PDF-Editoren.
• LaTeX Klassisch für wissenschaftliche und technische Dokumente. Tagging ist möglich, aber technisch anspruchsvoll und über Pakete wie accessibility oder tagpdf abzubilden.
  Knackpunkt: Die Bayerische Hochschule für öffentliche Verwaltung bewertet LaTeX für Barrierefreiheit als „nur bedingt geeignet". Mathematische Formeln und komplexe Strukturen erfordern Sondermaßnahmen.

Hinzu kommt das, was der Praktiker Jan Eric Hellbusch seit Jahren betont: Für die wirklich gute Nachbearbeitung von PDFs gibt es bisher kaum Alternativen zur Software des Format-Entwicklers selbst. Diese Abhängigkeit ist ein strukturelles Problem von PDF, das sich nicht durch einzelne Tools lösen lässt.

Reader-Seite: Was die Anzeige-Anwendung leistet

Selbst ein perfekt erstelltes PDF kann beim Nutzer Barrieren erzeugen, wenn der Reader die Tag-Struktur nicht oder nicht vollständig interpretiert. Reader-Anwendungen unterscheiden sich erheblich darin, wie sie Barrierefreiheits-Funktionen umsetzen.

Anstatt einzelne Produkte zu vergleichen – Reader-Verhalten ändert sich mit jedem Update – lohnt sich der Blick auf Reader-Kategorien und deren typische Eigenschaften:

• Kategorie 1

  Spezialisierte Desktop-PDF-Reader

  Vollständige Desktop-Anwendungen mit dediziertem Barrierefreiheits-Funktionsumfang. Sie unterstützen typischerweise Tag-Auslesung, Tastatur-Navigation, Reflow-Modus, Hochkontrast-Darstellung und Screenreader-Kopplung. Funktionsumfang variiert zwischen Anwendungen erheblich – auch zwischen kostenpflichtigen Versionen und kostenlosen Reader-Varianten desselben Anbieters.

• Kategorie 2

  Browser-eingebaute PDF-Viewer

  PDF-Anzeige direkt im Webbrowser. Diese Viewer haben historisch einen geringeren Funktionsumfang für Barrierefreiheit als spezialisierte Desktop-Anwendungen. Der konkrete Umfang unterscheidet sich je nach Browser und Version. Wer barrierefreie PDFs anbietet, kann nicht voraussetzen, dass alle Nutzer:innen die volle Funktionalität erleben, wenn das PDF im Browser geöffnet wird.

• Kategorie 3

  Mobile PDF-Reader

  PDF-Apps für Smartphones und Tablets unterstützen Tag-Strukturen historisch deutlich eingeschränkter als Desktop-Anwendungen. Reflow-Funktionen sind oft eingeschränkt, Screenreader-Kopplung variiert je nach Plattform. Mobile Lesbarkeit von PDFs ist generell eine Schwachstelle des Formats, unabhängig vom Reader.

• Kategorie 4

  Assistive-Technology-Reader

  Screenreader und ähnliche Anwendungen lesen PDFs entweder direkt oder über einen vorgeschalteten PDF-Reader. Die Qualität der Interpretation hängt von der Kopplung beider Anwendungen ab. Der Praktiker Jan Eric Hellbusch weist darauf hin, dass selbst bekannte PDF-Reader für sehbehinderte Nutzer:innen Probleme aufweisen können – etwa bei der Darstellung in eigenen Farbschemata.

Das Update-Problem: Warum PDFs „kaputtgehen"

Eines der unterschätzten Probleme von PDFs in der Praxis: Sobald ein PDF einmal nachbearbeitet wurde, ist seine Lebensdauer als barrierefreies Dokument an die Aktualisierung gekoppelt. Bei jeder Änderung gibt es drei Optionen, und alle haben ihre Nachteile.

Option 1: Neuer Export aus dem Quelldokument

Das Quelldokument (Word, InDesign) wird angepasst und neu zu PDF exportiert. Klingt einfach, hat aber einen Haken: Alle nachträglich am PDF gemachten Anpassungen gehen verloren. Wer im PDF Tags korrigiert, die Lesereihenfolge angepasst oder Alt-Texte ergänzt hat, muss diese Anpassungen nach jedem Export erneut durchführen.

Option 2: Anpassung direkt im PDF

Mit spezialisierten PDF-Editoren lässt sich das PDF direkt bearbeiten, ohne ein neues PDF zu exportieren. Das spart die Nachbearbeitung der Tags – schafft aber ein anderes Problem: Quelldokument und PDF driften auseinander. Wer später aus dem alten Quelldokument neu exportiert, verliert wieder alle Änderungen.

Option 3: Sauberes Quelldokument

Die einzige nachhaltige Lösung ist, das Quelldokument so sauber aufzubauen, dass beim Export möglichst wenig nachbearbeitet werden muss. Das setzt Disziplin im Quelldokument voraus: Formatvorlagen statt manueller Formatierung, Alternativtexte für Bilder bereits in Word oder InDesign, korrekte Tabellen-Strukturen, Sprach-Auszeichnung. Auch dann bleibt fast immer Nachbearbeitung übrig.

Wann PDF, wann lieber HTML?

Die wichtigste strategische Frage zur PDF-Barrierefreiheit ist oft: Muss das überhaupt ein PDF sein? Es gibt Anwendungsfälle, in denen PDF unverzichtbar oder klar überlegen ist – und andere, in denen HTML deutlich barrierefreier umsetzbar wäre.

Die ehrliche Antwort ist oft: Beide Formate, mit klar verteilten Rollen. Die Information zuerst als HTML auf der Website (gut auffindbar, mobile-tauglich, durchsuchbar), parallel als PDF zum Download für Nutzer:innen, die das Dokument offline benötigen oder ausdrucken wollen. Die HTML-Version ist die primäre, das PDF die sekundäre Form.

Eine methodische Anmerkung zum Schluss

Im PDF-Bereich kursieren viele Statistiken, etwa zu Compliance-Raten bei PDF-Dokumenten. Diese Zahlen sind interessant, aber methodisch oft eingeschränkt: Sie basieren häufig auf automatischen Tests, die nur einen Teil der WCAG-Kriterien prüfen können, oder auf nicht-repräsentativen Stichproben.