PDF/UA, BFSG, WCAG: Der Wegweiser zum Prüfen von barrierefreien PDF

PDF-Dokumente sind aus der digitalen Kommunikation nicht wegzudenken, bilden jedoch oft eine Sackgasse für die Barrierefreiheit. Während Websites zunehmend nach modernen Standards optimiert werden, bleiben Begleitdokumente häufig unzugänglich. Mit dem Inkrafttreten des Barrierefreiheitsstärkungsgesetzes (BFSG) im Juni 2025 wird die Bereitstellung barrierefreier Dokumente für viele Unternehmen von einer freiwilligen Serviceleistung zur gesetzlichen Pflicht.

Um rechtliche Risiken zu minimieren und die Nutzbarkeit für Menschen sicherzustellen, reicht ein einfacher Export aus Word oder InDesign nicht aus.

• PDF/UA: Dies ist der internationale Standard für universelle Barrierefreiheit im PDF-Format. Er definiert die technischen Anforderungen an das Dateiformat (zum Beispiel Tagging-Struktur, Einbettung von Schriften), damit assistive Technologien den Inhalt zuverlässig interpretieren können. PDF/UA deckt damit die technische Zugänglichkeit ab, nicht die inhaltliche Qualität.
• ISO 14289: Formale ISO-Normenbezeichnung desselben PDF/UA-Standards.
• WCAG (Web Content Accessibility Guidelines): Diese Richtlinien sind der weltweite Maßstab für barrierefreie Webinhalte, nicht originär für PDFs. Viele WCAG-Erfolgskriterien sind auf PDFs deshalb nur eingeschränkt oder anders anwendbar. Die Beziehung zu PDF/UA ist indirekt: WCAG beschreibt die inhaltlichen und funktionalen Ziele der Barrierefreiheit, während PDF/UA die PDF-spezifische technische Umsetzung regelt.
• EN 301 549: Die europäische Norm für die Barrierefreiheit von Informations- und Kommunikationstechnologie-Produkten. Sie referenziert für Dokumente direkt auf die WCAG und macht diese damit in der EU verbindlich.
• BITV 2.0 & BFSG: Die Barrierefreie-Informationstechnik-Verordnung (BITV) gilt primär für öffentliche Stellen. Das Barrierefreiheitsstärkungsgesetz (BFSG) überträgt diese Anforderungen nun auf viele private Wirtschaftsakteure für bestimmte Produkte und Dienstleistungen. Wer Dokumente im Rahmen dieses Gesetzes anbietet, muss die Konformität nach den oben genannten Normen sicherstellen.

Während die ISO-Norm PDF/UA festlegt, was erfüllt sein muss, sagt das Matterhorn-Protokoll, wie man es prüft. Es wurde von der PDF Association entwickelt, um die Prüfung zu standardisieren.

Das Protokoll besteht aus 31 Checkpunkten mit insgesamt 136 Fehlerbedingungen. Das Entscheidende daran: Es unterscheidet strikt zwischen dem, was eine Software erkennen kann, und dem, was ein Mensch beurteilen muss.

• 89 Fehlerbedingungen sind durch Software prüfbar (zum Beispiel: »Inhalt, der als Artefakt gekennzeichnet ist, befindet sich innerhalb von getaggtem Inhalt.«).
• 47 Fehlerbedingungen sind nur durch menschliche Prüfung feststellbar (zum Beispiel: »Die Anordnung der Tags entspricht nicht der logischen Lesereihenfolge.«).
• 2 Fehlerbedingungen können keiner dieser Kategorien zugeordnet werden, weil sie keine eigenständigen Bedingungen sind.

PDF/UA ist der Maßstab für Konformität. Das Matterhorn-Protokoll ist der de-facto-Referenzrahmen, wie diese Konformität praktisch geprüft wird.

Um die Einhaltung der durch Software prüfbaren Bedingungen zu messen, kommen bestimmte Tools zum Einsatz. Jedes hat einen eigenen Fokus:

• PDF Accessibility Checker (PAC): Das wohl bekannteste kostenlose Tool in Deutschland. Die Prüfberichte des PAC sind direkt nach den Checkpunkten des Matterhorn-Protokolls strukturiert. Besonders wertvoll ist die »Screenreader-Vorschau«, die es der Prüfperson erleichtert, nicht eindeutig automatisierbare Fehlerbedingungen (wie die korrekte Semantik oder Lesereihenfolge) visuell zu kontrollieren.
• Adobe Preflight: In der Vollversion von Adobe Acrobat Pro ist ein mächtiges Preflight-Modul integriert, das spezifische Prüfprofile für PDF/UA besitzt. Viele der maschinell erkannten, strukturellen Fehler können über integrierte »Fixups« (Korrekturprofile) direkt im Dokument behoben werden, ohne das Quelldokument erneut exportieren zu müssen.
• veraPDF: veraPDF ist ein quelloffenes Prüfwerkzeug für PDF/UA. Es eignet sich vor allem für automatisierte Prüfungen, Qualitätssicherung und formale Abnahmen, etwa bei großen Dokumentenmengen.

Ein »grüner Haken« in Tools wie dem PAC ist ein notwendiger erster Schritt, aber kein Garant für echte Barrierefreiheit. Automatisierte Tools können nur die Maschinenlesbarkeit prüfen, nicht aber die inhaltliche Sinnhaftigkeit. Ungefähr ein Drittel der Fehlerbedingungen aus dem Matterhorn-Protokoll erfordern eine menschliche Bewertung. Ein Tool erkennt, dass ein Tag vorhanden ist, aber nicht, ob es das richtige ist.

Aber auch die durch Software prüfbaren Fehlerbedingungen haben ihre Tücken. PDFix.net hat dazu 155 PDF-Dokumente mit veraPDF, Adobe Preflight, PAC und dem CommonLook PDF Validator getestet. In mehr als der Hälfte der getesteten PDFs haben die Validatoren unterschiedliche Ergebnisse ausgegeben. Das bedeutet: Sich auf ein einzelnes PDF/UA-Prüftool zu verlassen, kann zu unvollständigen oder irreführenden Ergebnissen hinsichtlich der Konformität führen. Eine Gegenprüfung mit verschiedenen Werkzeugen wird dringend empfohlen – insbesondere bei der Validierung kritischer Barrierefreiheitsanforderungen.

Es bleiben neben durch Software prüfbaren Fehlerbedingungen eine Menge Fragen, um festzustellen, wie es um die Barrierefreiheit eines PDF-Dokuments steht:

• Semantische Korrektheit: Wurden die Tags richtig vergeben? Eine Überschrift darf nicht nur wie eine Überschrift aussehen, sie muss auch als <h1> bis <h6> korrekt im Strukturbaum zugewiesen sein.
• Logische Lesereihenfolge: In welcher Abfolge liest der Screenreader die Inhalte vor? Besonders bei komplexen Mehrspalten-Layouts weicht die visuelle Ordnung oft von der technischen Tag-Reihenfolge ab.
• Qualität der Alternativtexte: Tools prüfen nur, ob ein Alt-Attribut vorhanden ist. Ein Mensch muss beurteilen, ob der Text den Informationsgehalt des Bildes für einen blinden Nutzer präzise wiedergibt.
• Artefakte: Sind rein dekorative Elemente (Linien, Hintergrundgrafiken) korrekt als Artefakt gekennzeichnet, damit sie den Lesefluss nicht stören?
• Tabellenstruktur: Sind Kopfzeilen (<th>) korrekt zugewiesen, sodass Datenzellen in der Sprachausgabe ihrem Kontext zugeordnet werden können?

Diese Aspekte lassen sich in Adobe Acrobat Pro prüfen, unter anderem über den Tags-Baum, das Lesereihenfolge-Werkzeug, den Reflow-Modus sowie den Tabellen-Editor. Acrobat macht die technische Struktur sichtbar, die inhaltliche Bewertung – etwa der Sinnhaftigkeit von Alternativtexten oder der logischen Reihenfolge – bleibt jedoch Aufgabe einer prüfenden Person. Wie zuvor erwähnt hat PDF Accessibility Checker (PAC) ebenfalls praktische Ansichten zur Bewertung dieser Bedingungen.

Ergänzend zur strukturellen Prüfung in Acrobat ist es möglich, das PDF mit einem echten Screenreader wie NVDA zu testen. Dabei zeigt sich, wie sich die getaggte Struktur tatsächlich in Sprache übersetzt: ob Überschriften sinnvoll angekündigt werden, ob die Lesereihenfolge verständlich ist und ob Tabellen, Listen oder Alternativtexte in einem realistischen Nutzungsszenario nachvollziehbar sind. Solche Tests decken Probleme auf, die in Prüftools nicht auffallen, etwa unlogische Reihenfolgen oder inhaltlich zwar richtige, aber praktisch unbrauchbare Beschreibungen.

Die Prüfung auf Barrierefreiheit ist ein zweistufiger Prozess: Das Matterhorn-Protokoll sieht allerhand Fehlerbedingungen vor, die durch Software oder Mensch geprüft werden müssen, um die tatsächliche Barrierefreiheit zu gewährleisten.

Für Unternehmen bedeutet dies: Wer Barrierefreiheit erst am Ende des Prozesses »draufklatschen« will, scheitert meist an den Kosten. Echte Konformität beginnt in der Struktur der Datei – egal ob in Word oder InDesign.