PDF-Barrierefreiheit

Ein barrierefreies PDF ist ein getaggtes PDF: Überschriften, Absätze, Listen, Tabellen und Bilder sind als maschinenlesbare Tags hinterlegt, die Lesereihenfolge ist logisch, Bilder haben Alternativtexte, und Dokumenttitel wie Dokumentsprache sind gesetzt. Der maßgebliche Standard dafür ist PDF/UA (ISO 14289) – prüfen lässt sich das kostenlos mit dem PDF Accessibility Checker (PAC), ergänzt um einen manuellen Screenreader-Test.

PDFs werden bei der Barrierefreiheit gern vergessen – dabei fallen sie unter dieselben Anforderungen wie Webseiten: Die EN 301 549 widmet Dokumenten ein eigenes Kapitel, und das BFSG erfasst PDFs, sobald sie Teil einer betroffenen Dienstleistung sind. In Behörden wie Unternehmen liegen oft hunderte PDFs, die niemand je geprüft hat. Das macht das Thema zu einem der größten – und am meisten unterschätzten – Compliance-Posten.

Was ein barrierefreies PDF ausmacht

Ein zugängliches PDF ist mehr als ein lesbar aussehendes. Jedes PDF hat zwei Ebenen: das sichtbare Layout, das alle Sehenden bekommen – und den Tag-Baum darunter, aus dem Screenreader, Braillezeilen und Umbruch-Ansichten den Inhalt beziehen. Fehlt die zweite Ebene, ist das Dokument für assistive Technologien ein unstrukturierter Textbrei oder schlicht leer. Es braucht eine maschinenlesbare Struktur – ganz analog zum semantischen HTML:

• Getaggt: Überschriften, Absätze, Listen und Tabellen sind als solche markiert (Tags), nicht nur optisch formatiert.
• Logische Lesereihenfolge: Der Tag-Baum gibt die Reihenfolge vor, in der ein Screenreader vorliest – unabhängig von der visuellen Anordnung.
• Alternativtexte für Bilder und Grafiken (siehe Alt-Texte schreiben), dekorative Elemente sind als Artefakt markiert.
• Dokumentsprache gesetzt (z. B. Deutsch), dazu ein aussagekräftiger Titel, der auch im Fenstertitel angezeigt wird – sonst liest der Screenreader den Dateinamen vor.
• Echter Text statt gescannter Pixel – ein eingescanntes Dokument muss per OCR in Text umgewandelt werden.
• Formularfelder mit Beschriftung, Tabellen mit Kopfzellen, Kontraste wie im Web.
• Navigierbar: Lange Dokumente brauchen Lesezeichen, damit niemand hundert Seiten linear durchhören muss.
• Keine Blockade durch Sicherheitseinstellungen: Ein Kopierschutz, der die Inhaltsentnahme sperrt, sperrt auch Screenreader aus.

Der Tag-Baum: diese Tags musst du kennen

Wenn du HTML kennst, kennst du das Prinzip schon. PDF-Tags sind das Gegenstück zu HTML-Elementen – nur dass sie unsichtbar unter dem Layout liegen:

Der Tag-Baum eines gut strukturierten PDFs entspricht damit grob diesem HTML:

<h1>Jahresbericht 2026</h1>
<p>Der Bericht fasst die wichtigsten Ergebnisse des Jahres zusammen …</p>
<figure>
  <img src="diagramm.png" alt="Balkendiagramm: Umsatz steigt 2026 um 8 Prozent auf 1,2 Millionen Euro.">
</figure>
<ul>
  <li>Umsatz gestiegen</li>
  <li>Kosten stabil</li>
</ul>

Alles, was im Baum steht, wird vorgelesen; alles, was als Artefakt markiert ist, nicht. Beides muss stimmen: Ein vergessener Absatz ist unsichtbar für Screenreader, eine als Inhalt getaggte Zierlinie ist störender Lärm.

Lesereihenfolge: die unsichtbare zweite Ordnung

Sehende Menschen erfassen ein Layout auf einen Blick und springen frei zwischen Spalten, Kästen und Marginalien. Ein Screenreader liest streng nacheinander – und zwar in der Reihenfolge des Tag-Baums, nicht in der Reihenfolge, die das Auge wählt. Gerade bei mehrspaltigen Layouts, Infokästen und Kolumnentiteln geht das schief:

Falsch – der Tag-Baum folgt der technischen Entstehung, nicht dem Sinn:
<Document>
 ├─ <P>  „Jahresbericht 2026 – Seite 3“   (Kolumnentitel)
 ├─ <P>  rechte Spalte, erster Absatz
 ├─ <H1> „Ergebnisse“
 └─ <P>  linke Spalte, erster Absatz

Richtig – Kolumnentitel als Artefakt, Inhalt in Sinn-Reihenfolge:
<Document>
 ├─ <H1> „Ergebnisse“
 ├─ <P>  linke Spalte, erster Absatz
 └─ <P>  rechte Spalte, erster Absatz

In Acrobat Pro kontrollierst du das über die Tag-Ansicht (Reihenfolge der Tags von oben nach unten) – und am verlässlichsten, indem du das Dokument mit einem Screenreader einfach einmal von vorn bis hinten vorlesen lässt.

PDF/UA: der Standard

PDF/UA (ISO 14289, „Universal Accessibility“) ist die Norm für barrierefreie PDFs. PDF/UA-1 (ISO 14289-1) erschien erstmals 2012 und baut auf Tagged PDF auf, das es im PDF-Format schon seit Version 1.4 (2001) gibt. Die Norm konkretisiert, wie Tags, Lesereihenfolge, Alternativtexte, Metadaten und Formularfelder technisch auszusehen haben. 2024 folgte PDF/UA-2 (ISO 14289-2) auf Basis von PDF 2.0 – mit neuen Tag-Namensräumen, strengeren Verschachtelungsregeln und gelockerten Vorgaben für Überschriften-Tags. In der Praxis ist PDF/UA-1 weiterhin der Standard, den Werkzeuge und Prüftools flächendeckend unterstützen.

Wichtig für die Einordnung: PDF/UA regelt die Technik, nicht die Inhalte. Kontraste, verständliche Sprache oder die Qualität eines Alt-Textes bewertet die Norm nicht – dafür gelten zusätzlich die WCAG. Das W3C dokumentiert in seinen PDF-Techniken, wie WCAG-Kriterien konkret in PDFs umgesetzt werden. Ein PDF, das PDF/UA erfüllt und die WCAG-Inhalte beachtet, ist auf der sicheren Seite. Umgekehrt heißt „PDF/UA-konform“ allein noch nicht barrierefrei.

Das Matterhorn-Protokoll

Damit „PDF/UA-konform“ überprüfbar wird, hat die PDF Association das Matterhorn-Protokoll entwickelt: Es übersetzt PDF/UA-1 in 31 Prüfpunkte mit 136 konkreten Fehlerbedingungen – etwa „Überschriften-Ebene übersprungen“ oder „Bild ohne Alternativtext“. Jede Fehlerbedingung ist als maschinell prüfbar oder als menschlich zu beurteilen eingestuft. Genau das ist der Grund, warum kein Prüftool allein reicht: Ob ein Alt-Text existiert, sieht die Software; ob er das Bild sinnvoll beschreibt, sieht nur ein Mensch.

Schritt für Schritt: barrierefreies PDF aus Word

Der Grundstein liegt immer im Quelldokument. Wer in Word sauber arbeitet, bekommt den Tag-Baum beim Export fast geschenkt. Die folgende Kurzfassung reicht für den Export; wie man Word, PowerPoint und Excel darüber hinaus sauber aufsetzt – von der Lesereihenfolge in Präsentationen bis zu verbundenen Zellen in Tabellen –, steht unter Barrierefreie Office-Dokumente:

1. Formatvorlagen statt Handarbeit: „Überschrift 1“, „Überschrift 2“ usw. für Überschriften – niemals nur fett und größer formatieren. Die Überschriften-Hierarchie gilt im PDF genauso: eine H1, keine Ebenen überspringen. Listen über die Listen-Schaltflächen erzeugen, nicht mit Spiegelstrichen tippen.
2. Alt-Texte vergeben: Rechtsklick auf ein Bild → „Alternativtext anzeigen“. Dekorative Bilder als „dekorativ“ markieren, dann landen sie als Artefakt im PDF.
3. Tabellen sauber aufbauen: Echte Tabellen (Einfügen → Tabelle) nur für Daten, nie fürs Layout. Kopfzeile im Register „Tabellenentwurf“ aktivieren, verbundene Zellen vermeiden.
4. Titel und Sprache setzen: Datei → Informationen → Titel eintragen; die Dokumentsprache unter Überprüfen → Sprache kontrollieren.
5. Die Word-eigene Prüfung nutzen: Überprüfen → „Barrierefreiheit überprüfen“ findet fehlende Alt-Texte, problematische Tabellen und mehr – direkt beim Schreiben.
6. Richtig exportieren: Datei → „Speichern unter“ (oder „Exportieren“) → PDF → Optionen → Häkchen bei „Dokumentstrukturtags für Barrierefreiheit“. Für lange Dokumente zusätzlich „Textmarken erstellen mithilfe von: Überschriften“ – das erzeugt die Lesezeichen.
7. Nachprüfen mit PAC (siehe unten).

Randnotiz – der Drucken-Dialog zerstört alles. „Drucken → Microsoft Print to PDF“ erzeugt ein PDF ohne Tags – die gesamte Struktur aus dem Quelldokument geht verloren, egal wie sauber es aufgebaut war. Immer den Export- bzw. Speichern-Weg nehmen. Das ist der häufigste einzelne Fehler, den ich in der Praxis sehe.

Schritt für Schritt: Export aus InDesign

InDesign kann getaggte PDFs erzeugen, verlangt aber mehr Vorarbeit als Word – und fast immer Nacharbeit in Acrobat:

1. Absatzformate mit Tagexport: In den Absatzformatoptionen unter „Tagexport“ jedem Format sein PDF-Tag zuweisen (H1–H6 für Überschriften, P für Fließtext).
2. Lesereihenfolge über das Artikel-Bedienfeld: Fenster → „Artikel“, Inhalte in der gewünschten Lesereihenfolge hineinziehen und im Bedienfeldmenü „Für Leserichtung in PDF mit Tags verwenden“ aktivieren. Ohne diesen Schritt bestimmt die Ebenen- und Erstellreihenfolge den Tag-Baum – selten die richtige.
3. Alt-Texte: Objekt → „Objektexportoptionen“ → Alt-Text. Rein dekorative Grafiken dort als Artefakt auszeichnen.
4. Objekte verankern: Frei schwebende Bilder und Kästen in den Textfluss verankern, damit sie an der sinnvollen Stelle vorgelesen werden.
5. Metadaten: Datei → Dateiinformationen → Dokumenttitel eintragen.
6. Export: Datei → Exportieren → Adobe PDF → Häkchen bei „PDF mit Tags erstellen“; keine Sicherheitseinstellungen, die die Inhaltsentnahme sperren.

Danach in Acrobat Pro nacharbeiten: Dokumentsprache setzen (Datei-Eigenschaften → Erweitert → Sprache), den Fenstertitel auf „Dokumenttitel“ statt Dateiname stellen, die Tab-Reihenfolge auf „Dokumentstruktur verwenden“ und den Tag-Baum kontrollieren. Ich habe noch kein komplexes InDesign-Layout gesehen, das ohne diese Nacharbeit fehlerfrei durch PAC kommt – plane sie fest ein.

Prüf-Workflow: PAC, Acrobat, Screenreader

Mein Standard-Workflow hat drei Stufen – jede findet Fehler, die die anderen übersehen:

1. PAC (PDF Accessibility Checker): Der kostenlose PAC – ursprünglich von der Schweizer Stiftung „Zugang für alle“ entwickelt – prüft gegen PDF/UA und WCAG, zeigt den Tag-Baum in einer Screenreader-Vorschau und gibt zusätzlich Qualitätswarnungen aus. Seit PAC 2026 helfen KI-gestützte Prüfungen, etwa als Bild eingefügte Tabellen zu erkennen. PAC läuft nur unter Windows; als Open-Source-Alternative für die maschinelle Validierung gibt es veraPDF.
2. Acrobat Pro: Die eingebaute Barrierefreiheitsprüfung plus Tag-Ansicht, um gefundene Fehler direkt zu beheben – vom fehlenden Alt-Text bis zur falschen Tag-Reihenfolge.
3. Manuell mit Screenreader: Das Dokument mit NVDA oder VoiceOver komplett vorlesen lassen: Stimmt die Reihenfolge? Sind die Alt-Texte verständlich? Werden Tabellen als Tabellen navigierbar? Zusätzlich per Tab durch alle Links und Formularfelder gehen.

Dass alle drei Stufen nötig sind, folgt direkt aus dem Matterhorn-Protokoll: Ein bestandener PAC-Test heißt nur, dass die maschinell prüfbaren Bedingungen erfüllt sind. Ob die Lesereihenfolge inhaltlich stimmt, Alt-Texte taugen oder sich der Text nicht auf rein visuelle Merkmale bezieht („siehe roten Kasten rechts“), kann nur ein Mensch beurteilen.

Gescannte PDFs: erst OCR, dann Tags

Ein eingescanntes Dokument ist für Screenreader nichts als ein Bild – null Text, null Struktur. Der Weg zur Zugänglichkeit hat zwei Schritte, und viele vergessen den zweiten: Erst wandelt eine Texterkennung (in Acrobat: „Scan & OCR“ → „Text erkennen“) die Pixel in durchsuchbaren Text um. Dann muss dieser Text noch getaggt werden – OCR allein erzeugt keine Überschriften, Listen oder Tabellen. Bei schlechten Scanvorlagen kommt Korrekturlesen dazu, denn Erkennungsfehler liest der Screenreader originalgetreu falsch vor. Wenn das Quelldokument noch existiert, ist der Neuexport daraus praktisch immer schneller und besser als die Reparatur des Scans.

Formularfelder

PDF-Formulare brauchen dieselbe Sorgfalt wie Webformulare: Jedes Feld braucht eine programmatisch verknüpfte Beschriftung – im PDF ist das der Tooltip (in Acrobat: „Formular vorbereiten“ → Feldeigenschaften → QuickInfo). Der sichtbare Text neben dem Feld reicht nicht, denn der Screenreader liest im Formularmodus nur den Tooltip vor. Dazu kommen eine logische Tab-Reihenfolge, gruppierte Radiobuttons (gleicher Feldname, unterschiedliche Werte) und Pflichtfeld-Kennzeichnungen im Beschriftungstext. Interaktive Formulare sind einer der Punkte, an denen der Aufwand im PDF schnell explodiert – und eines der stärksten Argumente, das Formular stattdessen als HTML anzubieten.

Recht: EN 301 549, BITV und BFSG

Die EN 301 549 behandelt Dokumente in einem eigenen Kapitel 10 („Nicht-Web-Dokumente“) und wendet dort die WCAG-Erfolgskriterien auf Dateien wie PDFs an – auch auf solche, die eine Website nur zum Download anbietet. Daraus folgt:

• Öffentliche Stellen müssen PDFs nach BITV 2.0 barrierefrei bereitstellen. Ausgenommen sind Office-Dateiformate, die vor dem 23. September 2018 veröffentlicht wurden – es sei denn, sie werden für aktive Verwaltungsverfahren weiterhin benötigt.
• Unternehmen unterliegen seit dem 28. Juni 2025 dem BFSG: PDFs, die Teil einer erfassten Dienstleistung sind – Verträge, AGB, Rechnungen, Produktinformationen im Onlineshop, E-Books –, müssen zugänglich sein.
• PDF/UA ist dabei nicht wörtlich vorgeschrieben, gilt aber als Stand der Technik: Wer PDF/UA erfüllt und die WCAG-Inhalte beachtet, deckt die Anforderungen der EN 301 549 an Dokumente ab.

Randnotiz – HTML schlägt PDF fast immer. Bevor du ein PDF mühsam zugänglich machst, frag dich, ob es ein PDF sein muss. Eine HTML-Seite ist von Natur aus responsiv, zoomt ohne horizontales Scrollen, passt sich an Dunkelmodus und eigene Schriftgrößen an, ist durchsuchbar, leichter und mit semantischem Markup fast nebenbei barrierefrei – während dieselbe Qualität im PDF Handarbeit pro Dokument bedeutet. Für Inhalte, die online gelesen werden, ist HTML meist die bessere Wahl; das PDF bleibt für das, was wirklich gedruckt oder archiviert wird.

Aufwand realistisch einschätzen

Die Kostenkurve ist steil, und sie zeigt in eine klare Richtung: Am billigsten ist Barrierefreiheit, die im Quelldokument entsteht – Formatvorlagen, Alt-Texte und der getaggte Export kosten fast nichts extra. Deutlich teurer ist die Nacharbeit in Acrobat, bei der jemand Tag für Tag prüft und repariert. Am teuersten ist die komplette nachträgliche Sanierung fremder PDFs ohne Quelldatei – bei komplexen Layouts reden wir über Stunden pro Dokument.

Für den Altbestand heißt das: priorisieren statt alles auf einmal. Zuerst die Dokumente, die aktuell gebraucht und häufig abgerufen werden; dann die, die sich durch eine HTML-Seite ersetzen lassen (oft der schnellste Weg); selten genutzte Archivbestände zuletzt oder auf Anfrage. Und für alles Neue gilt ab sofort: Der Export aus einem sauberen Quelldokument ist der einzige Weg, der skaliert.

Häufige Fehler

• Gescanntes Dokument ohne OCR – für Screenreader nur ein Bild.
• Export über den Drucken-Dialog statt „Speichern als PDF“ – alle Tags gehen verloren.
• Visuell formatiert, aber nicht getaggt – fette Zeilen statt Formatvorlagen, keine Struktur unter der Oberfläche.
• Falsche Lesereihenfolge, weil der Tag-Baum nicht zur Optik passt – typisch bei mehrspaltigen Layouts aus InDesign ohne Artikel-Bedienfeld.
• Alt-Texte fehlen oder sind Dateinamen („grafik_final_v2.png“ hilft niemandem).
• Titel und Sprache nicht gesetzt – der Screenreader meldet den Dateinamen und spricht deutschen Text mit englischer Stimme aus.
• Tabellen ohne Kopfzellen oder Tabellen als Layout-Werkzeug.
• Formularfelder ohne Tooltip – im Formularmodus liest der Screenreader nichts vor.
• Sicherheitseinstellungen, die die Inhaltsentnahme sperren und damit assistive Technologien blockieren.
• PDF nehmen, wo HTML besser wäre.

Häufige Fragen

Macht „Speichern als PDF“ automatisch ein barrierefreies PDF?

Nein, aber der Grundstein liegt im Quelldokument: Wer in Word oder InDesign saubere Formatvorlagen, Alt-Texte und den getaggten Export nutzt, bekommt ein weitgehend zugängliches PDF. Entscheidend ist der richtige Weg – der Export mit Dokumentstrukturtags, nie der Drucken-Dialog – und eine Prüfung mit PAC danach.

Fällt mein PDF unter das BFSG?

Wenn es Teil einer erfassten Dienstleistung ist – etwa eine Rechnung, ein Vertrag oder eine Produktinformation im Onlineservice –, ja. Dokumente sind über Kapitel 10 der EN 301 549 abgedeckt. Für öffentliche Stellen gilt Entsprechendes schon länger über die BITV 2.0.

Reicht die Prüfung in Acrobat?

Sie ist ein guter Anfang, findet aber nicht alles. Ergänze PAC für die PDF/UA-Prüfung und einen manuellen Screenreader-Test – das Matterhorn-Protokoll stuft viele Prüfpunkte ausdrücklich als nur menschlich beurteilbar ein, etwa die Qualität von Alt-Texten oder die inhaltliche Logik der Lesereihenfolge.

Was ist der Unterschied zwischen PDF/UA-1 und PDF/UA-2?

PDF/UA-1 (2012) basiert auf PDF 1.4 mit den klassischen Tags und ist der Standard, den Werkzeuge und Prüftools heute breit unterstützen. PDF/UA-2 (2024) baut auf PDF 2.0 auf – mit neuen Tag-Namensräumen, strengeren Verschachtelungsregeln und flexibleren Überschriften-Tags. Für die Praxis ist PDF/UA-1 auf absehbare Zeit die relevante Zielmarke.

Geht das auch ohne Acrobat Pro?

Beim Erstellen: ja. Word und LibreOffice exportieren getaggte PDFs (LibreOffice bietet im PDF-Export sogar eine eigene Option für universelle Zugänglichkeit), und geprüft wird kostenlos mit PAC. Grenzen gibt es beim Reparieren: Wer den Tag-Baum eines fertigen PDFs bearbeiten muss, kommt um Acrobat Pro oder Spezialwerkzeuge kaum herum. Die beste Strategie ohne Acrobat ist deshalb, Fehler im Quelldokument zu beheben und neu zu exportieren.

Müssen alte PDFs nachträglich barrierefrei gemacht werden?

Öffentliche Stellen profitieren von der Ausnahme für Office-Formate, die vor dem 23. September 2018 veröffentlicht wurden – solange die Dokumente nicht für aktive Verwaltungsverfahren gebraucht werden. Für alles, was aktuell genutzt wird, gilt die Pflicht. Praktisch heißt das: Altbestand priorisieren, häufig genutzte Dokumente zuerst sanieren oder durch HTML ersetzen.

Fazit

Ein barrierefreies PDF ist getaggt, hat eine logische Lesereihenfolge, Alt-Texte, echten Text, Kopfzellen in Tabellen und gesetzten Titel samt Sprache – idealerweise nach PDF/UA und geprüft in drei Stufen: PAC, Acrobat, Screenreader. Der Hebel liegt im Quelldokument: Formatvorlagen und der getaggte Export kosten Minuten, die nachträgliche Sanierung Stunden. Der wichtigste Tipp kommt aber vorher: Prüfe, ob es überhaupt ein PDF sein muss. Für online gelesene Inhalte ist gutes HTML fast immer die zugänglichere Wahl.

Quellen

• PDF/UA kompakt – Einführung in ISO 14289 (PDF Association, PDF)
• Matterhorn-Protokoll – Prüfpunkte für PDF/UA (PDF Association)
• PAC – PDF Accessibility Checker (kostenloses Prüftool)
• EN 301 549 V3.2.1 – Kapitel 10: Nicht-Web-Dokumente (PDF)