Die einzige Entscheidung, die jeden späteren Schritt prägt, ist die Wahl der Erstellungsumgebung. Ein PDF, das aus einem korrekt strukturierten InDesign-Dokument mit angewendeter Aktion „Barrierefrei machen“ generiert wird, trägt 80 Prozent seiner Barrierefreiheits-Metadaten, bevor jemand Acrobat öffnet. Ein PDF, das aus einem Word-Dokument exportiert wird, in dem Überschriften durch Fettschrift und größere Schrift imitiert wurden, enthält fast keine — und keine noch so gründliche Nachbearbeitung kann dies vollständig beheben. Die Wahl des Autorenwerkzeugs ist also keine ästhetische, sondern eine strukturelle Entscheidung.

Im institutionellen Publishing dominieren 2026 drei Produktionswege. Adobe InDesign mit der Aktion „Barrierefrei machen“ ist der Standard für gesetzt gedruckte Dokumente — Geschäftsberichte, Lehrbücher, Behördenunterlagen —, wo das Layout feststeht und die Datei das Design-Team nur einmal verlässt. Microsoft Word mit „Als barrierefreies PDF speichern“ ist das Arbeitspferd für Bürodokumente — Richtlinien, Verträge, Briefe —, wo die Quelle fortlaufend bearbeitet wird und das PDF eine Darstellungsform und kein Endziel ist. LibreOffice mit der Übergabe an den PDF Accessibility Checker ist der Open-Source-Weg, den Behörden und Universitäten nutzen, die aus Richtliniengründen Microsoft- und Adobe-Stacks vermeiden.

Unter jedem barrierefreien PDF liegt eine parallele logische Struktur — die Tag-Struktur —, die nichts mit dem visuellen Layout zu tun hat. Das sichtbare PDF ist ein koordinatenbasierter Satz von Darstellungsanweisungen. Die Tag-Struktur ist ein separates hierarchisches Dokumentobjektmodell, das besagt: Diese Darstellungsoperation ist die erste Überschrift, jene ist das dritte Aufzählungszeichen der zweiten Liste, dieses Bild ist dekorativ, jenes andere Bild hat den Alternativtext „Vierteljährlicher Umsatz nach Segment, GJ 2024“. Ein Screenreader liest die Tag-Struktur, nicht die Darstellung.

Sechs Tag-Kategorien tragen den Großteil der Bedeutung in realen Dokumenten: Überschriften (H1 bis H6) bilden die navigierbare Gliederung; Absätze (P) sind die Fließtextabschnitte; Listen (L, LI, Lbl, LBody) sind geordnete oder ungeordnete Aufzählungen; Tabellen (Table, TR, TH, TD) sind Datengitter, bei denen Spalten- und Zeilenüberschriften über das Scope-Attribut zugänglich gemacht werden; Abbildungen (Figure) tragen den Alternativtext in ihrem Alt- oder ActualText-Attribut; und die Lesereihenfolge, die der Tiefendurchlauf der Struktur selbst ist, bestimmt die Abfolge, in der ein Screenreader das Dokument vorliest. Eine Seite, die optisch korrekt in zwei Spalten erscheint, kann in der falschen Reihenfolge gelesen werden, wenn die Tag-Struktur die rechte Spalte vor der linken platziert.

Zwei weitere Attribute sind bei jedem Tag in einer korrekt erstellten Datei wichtig. Das Sprachattribut (Lang) teilt dem Screenreader mit, welches Aussprache-Wörterbuch zu verwenden ist — ein französisches Zitat innerhalb eines deutschen Absatzes benötigt ein eigenes Lang-Attribut an einem Span-Tag, sonst wird es mit deutschen Lauten gelesen. Und der Artefakt-Marker unterscheidet dekorativ von strukturell; Kopfzeilen, Fußzeilen, Seitenzahlen und dekorative Linien sollten alle als Artefakte markiert werden, damit der Screenreader sie überspringt.

PDF/UA ist die internationale Norm für barrierefreie PDFs, veröffentlicht als ISO 14289-1 im Jahr 2014 und aktualisiert 2024. Während WCAG technologieneutral und plattformneutral ist, ist PDF/UA PDF-spezifisch — es ist der Vertrag zwischen dokumenterstellender Software, dokumentverarbeitender Software und assistiver Technologie, der besagt: Die Tag-Struktur, die Metadaten und die Struktur dieser Datei entsprechen einem überprüfbaren Satz von Bedingungen, sodass ein konformes Leseprogramm sich darauf verlassen kann.

Die Norm wird durch das Matterhorn-Protokoll operationalisiert, das von der PDF Association gepflegt wird und PDF/UA in 31 nummerierte Fehlerbedingungen mit maschinell prüfbaren und manuell prüfbaren Varianten unterteilt. Maschinell prüfbare Fehler umfassen: fehlender Dokumenttitel in den Metadaten, Abbildungen ohne Alt- oder ActualText-Attribut, Listen außerhalb von L/LI-Tags, fehlende Sprachattribute am Dokument oder an Sprachumschaltstellen. Manuell prüfbare Fehler betreffen das, was Software allein nicht überprüfen kann — ob der Alternativtext einer Abbildung diese tatsächlich beschreibt, ob die Lesereihenfolge der logischen Abfolge entspricht, ob Überschriften logisch verschachtelt und nicht übersprugen sind.

Die Aktualisierung 2024 hat PDF/UA an die WCAG 2.2 Erfolgskriterien angeglichen und die Behandlung digitaler Signaturen und Formulare präzisiert — barrierefreie PDF-Formulare müssen Feldbeschriftungen, Feldtooltips und Tab-Reihenfolge zugänglich machen, und signierte PDFs dürfen den Zugriff des Screenreaders auf die zugrunde liegende Tag-Struktur nach dem Signieren nicht blockieren.

Wenn ein PDF ohne verwendbare Tag-Struktur eintrifft — und die meisten Legacy-PDFs haben keine —, verengt sich die Wahl auf vier Nachbearbeitungsumgebungen. Jede hat eine andere Kombination aus Stärken bei Tag-Strukturbearbeitung, OCR für gescannte Originale, Stapelverarbeitung und PDF/UA-Berichterstattung. Die nachfolgende Matrix ordnet Fähigkeiten den Werkzeugen zu.

Ein korrekt getaggtes PDF ist nur die Hälfte der Kette auf Produzentenebene. Die andere Hälfte ist der Screenreader, und die vier Leseprogramme, die Nutzende tatsächlich einsetzen, behandeln dieselbe Datei auf subtil unterschiedliche Weise. Die Unterschiede sind relevant, weil ein Dokument, das in JAWS sauber gelesen wird, in NVDA Probleme bereiten kann, und eine Datei, die in VoiceOver auf macOS funktioniert, möglicherweise anders reagiert, wenn dieselbe Datei von ChromeVox im eingebauten PDF-Viewer von Chrome geöffnet wird.

JAWS bietet die tiefste und älteste PDF-Unterstützung aller kommerziellen Screenreader. Sein PDF-Modus verarbeitet getaggte PDFs über Acrobat oder Acrobat Reader und legt die Tag-Struktur direkt offen — Überschriftenliste (Einfg+F6), Formularliste (Einfg+F5), Tabellenzellen-Navigation mit den Standard-JAWS-Tabellentasten. Wenn ein PDF keine Tags hat, bietet JAWS an, die Struktur abzuleiten, aber das abgeleitete Ergebnis ist unzuverlässig; Entwicklerinnen und Entwickler sollten nicht gegen JAWS-abgeleitete Lesungen validieren.

NVDA liest getaggte PDFs ebenfalls über Acrobat oder Acrobat Reader, mit Browse-Modus-Navigation, die dem Webseitenmodell entspricht — H für Überschriften, K für Links, T für Tabellen. NVDAs PDF-Unterstützung hat sich seit 2022 deutlich verbessert, bleibt aber bei komplexen Tabellen und Formularfeldern hinter JAWS zurück. NVDA gibt ehrlicheres Feedback bei Dokumenten mit fehlerhaften Tags: wo JAWS weitermacht, neigt NVDA zum Schweigen — was diagnostisch nützlich ist.

VoiceOver auf macOS liest PDFs über Preview und Safari mit Rotor-Navigation (VO + U) über Überschriften, Links, Tabellen und Formularfelder. VoiceOver ist das nachsichtigste der vier Programme — es rekonstruiert eine Lesereihenfolge auch bei schlecht getaggten Dateien —, aber diese Nachsicht kann tatsächliche Fehler verbergen. Ein Dokument, das in VoiceOver akzeptabel gelesen wird, sollte dennoch gegen JAWS oder NVDA überprüft werden, nicht umgekehrt.

ChromeVox auf ChromeOS und das allgemeine Verhalten jedes Screenreaders in Verbindung mit dem eingebauten PDF-Viewer von Chrome bilden eine eigene Kategorie. Chromes PDF-Viewer rastert den Text und extrahiert ihn neu, anstatt die ursprüngliche Tag-Struktur darzustellen, sodass ein PDF mit sauberer Tag-Struktur beim direkten Öffnen in Chrome einen Großteil seiner Struktur verlieren kann. Die Abhilfemaßnahme für barrierefreiheitskritische Kontexte besteht darin, die Datei zum Herunterladen zu zwingen und in Acrobat Reader zu öffnen oder eine HTML-Alternative bereitzustellen.

Die Kette zusammengefügt: Ein einzelnes barrierefreies PDF durchläuft sechs konkrete Schritte. Sie sind sequenziell — das Überspringen eines einzigen führt zu einer Datei, die in einem der späteren Schritte oder in den Händen der Nutzenden scheitert.

Teams, die PDF-Barrierefreiheit als abschließendes Nachbearbeitungsproblem behandeln, zahlen die Rechnung doppelt — einmal für die Behebung einer Datei, die ohne strukturelle Absicht erstellt wurde, und erneut bei jeder Aktualisierung dieser Datei. Teams, die es als Erstellungsproblem behandeln, bauen die Tag-Struktur an der Quelle auf, generieren sie bei jeder Überarbeitung sauber neu und verwenden PAC und einen Screenreader zur Verifizierung, nicht zur Reparatur. Der Kostenunterschied zwischen den beiden Ansätzen ist erheblich; der Unterschied in der Barrierefreiheit ist noch größer.

Die oben dokumentierte Kette ist bei jedem Glied bewusst werkzeugneutral. Unabhängig davon, ob die Quelle InDesign oder LibreOffice ist, der Editor Acrobat oder Foxit, der Verifizierer PAC und der Screenreader JAWS oder NVDA — die Strukturlogik bleibt dieselbe: Absatzformate werden Tags zugeordnet, Tags entsprechen PDF/UA, PDF/UA wird durch PAC verifiziert, und Screenreader lesen das Ergebnis. Werkzeuge ändern sich; die Kette nicht.

Für Beschaffungs- und Compliance-Teams lautet die operative Schlussfolgerung, dass Barrierefreiheitserklärungen für PDFs die Produktionskette beschreiben sollten — das Autorenwerkzeug, die Exportaktion, den Verifizierer — und nicht nur ein Acrobat-Checker-Ergebnis. Für Entwicklungsteams bedeutet dies, dass die Tag-Struktur die Quelle der Wahrheit ist und die Tag-Struktur vorgelagert zu dem PDF erstellt wird, das der Nutzende jemals sieht. Eine praktische Produktionsanleitung, die diesen Primer ergänzt, findet sich im schrittweisen PDF-Barrierefreiheits-Playbook.