Barrierefreie PDF aus Word – ohne Zusatzsoftware kein zugängliches PDF?
Wer sich mit barrierefreien PDF-Dokumenten beschäftigt, stößt früher oder später auf PAC, veraPDF oder vergleichbare Prüfwerkzeuge. Die Ergebnisse solcher Prüfungen werden häufig als Maßstab für die Barrierefreiheit eines Dokuments herangezogen, zum Beispiel auch von Überwachungsstellen im Rahmen der BITV und des BFSG. Das ist nachvollziehbar. Schließlich braucht es objektive Kriterien und reproduzierbare Verfahren, um Dokumente bewerten zu können. Das hat aber auch Grenzen.
In unserer Artikelserie rund um PAC haben wir bisher vor allem die andere Seite betrachtet. Im Beitrag „PAC-Fehler – grüne Häkchen sind kein Beweis“ haben wir gezeigt, dass ein Dokument trotz erfolgreicher Prüfung Barrieren enthalten kann. Mit dem Beitrag zur neuen KI-Funktion in PAC 2026 haben wir untersucht, ob moderne Verfahren diese Lücke besser schließen können.
Für unser neues Beispieldokument drehen wir die Perspektive nun um.Die Ausgangsfrage lautet diesmal: Bedeutet ein Fehler in PAC automatisch, dass ein Dokument nicht barrierefrei ist?
Um dieser Frage nachzugehen, haben wir ein PDF-Dokument ausschließlich mit den Bordmitteln von Microsoft Word erstellt. Das Dokument enthält typische Elemente wie Bilder, Überschriften, Tabellen, Verlinkungen, ein Inhaltsverzeichnis und Fußnoten. Anschließend wurde es direkt als getaggtes PDF exportiert – ohne Acrobat Pro, Plugins oder andere Zusatzsoftware.
Das Ergebnis überrascht zumindest auf den ersten Blick. Das Dokument erzeugt mehrere Fehler und Warnungen in PAC. Gleichzeitig konnten die Inhalte in unseren Screenreader-Tests weitgehend problemlos genutzt werden. Und auch eine Sichtprüfung von Inhalt, Gestaltung oder technischer Struktur lassen keine Probleme erkennen. Einige der gemeldeten Auffälligkeiten betreffen Metadaten, andere technische Details der Tag-Struktur oder Anforderungen, die sich mit wenigen Mausklicks nachträglich ergänzen lassen. Das führt uns zu unserer Ausgangsfrage zurück: kann man ohne Zusatzsoftware kein zugängliches PDF erstellen?
PDF/UA ist ein wichtiger Standard. Automatische Prüfwerkzeuge leisten einen wertvollen Beitrag zur Qualitätssicherung. Trotzdem stellt sich die Frage, welche Bedeutung einzelne Fehlermeldungen für die tatsächliche Zugänglichkeit eines Dokuments haben. Nicht jede formale Abweichung führt zwangsläufig zu einer Barriere oder Einschränkung bei der Nutzung. Umgekehrt garantiert auch ein fehlerfreier Prüfbericht noch keine Barrierefreiheit, wie wir im Beitrag „PAC-Fehler – grüne Häkchen sind kein Beweis“ gezeigt haben, der im Übrigen auch im Artikel „Auf Knopfdruck barrierefrei? KI-Modelle sollen PDF-Inhalte zugänglich machen“ der c't 12/2026 zitiert wurde.
Die Diskussion, was als barrierefrei gilt und was nicht, gewinnt zusätzlich an Bedeutung, weil PDF-Dokumente seit Jahren zu den größten Problemfeldern in den Monitoring-Berichten zählen, wie auch der große Report „Bericht zur Barrierefreiheit von PDF-Dokumenten auf Webauftritten der öffentlichen Hand in Deutschland 2026“ wieder gezeigt hat. Aber nicht nur durch die BITV, sondern auch durch BFSG und Marktüberwachung steigen die Anforderungen an den Nachweis von Barrierefreiheit, auch von PDF-Dokumenten. Derzeit ist es aber praktisch unmöglich formal barrierefreie PDF zu erzeugen, wenn der zugrundeliegende PDF/UA Standard mit Bordmitteln aus gängigen Autorentools, also ohne Plugins und kostenpflichtige Zusatzsoftware gar nicht möglich ist. Man darf die Frage stellen: warum müssen Dokumente nach dem Export überhaupt mit Spezialwerkzeugen nachbearbeitet werden, wenn sie bereits in Word, PowerPoint, LibreOffice oder InDesign semantisch korrekt erstellt wurden? Sollte es nicht das Ziel sein, dass Autorentools von Haus aus PDF-Dokumente erzeugen, die nicht nur praktisch zugänglich, sondern auch formal konform sind?
Im Beispieldokument haben wir deshalb jede einzelne Fehlermeldung und Warnung untersucht. Wir haben geprüft, was PAC konkret beanstandet, welche technische Ursache dahintersteckt und ob sich daraus tatsächlich eine Einschränkung für die Nutzung ergibt. Dabei geht es unter anderem um Tabellenköpfe ohne explizite Zuordnung, fehlende PDF/UA-Kennzeichnungen, Warnungen zu Link- und Span-Elementen, Metadaten oder Fußnoten. In mehreren Fällen konnten wir trotz formaler Abweichungen keine erkennbaren Auswirkungen auf die Nutzung, zum Beispiel mit Screenreadern, feststellen. Andere Meldungen erwiesen sich dagegen als nachvollziehbar, auch wenn ihre praktische Bedeutung vom jeweiligen Anwendungsfall abhängt.
Unser neues Beispieldokument liefert auf die Ausgangsfrage keine abschließende Antwort. Es zeigt aber, dass zwischen PDF/UA-Konformität, automatischen Prüfergebnissen und tatsächlicher Zugänglichkeit Unterschiede bestehen können. Genau deshalb halten wir die Diskussion für wichtig.
Denn wenn grüne Häkchen in einem Prüfwerkzeug kein Beleg für tatsächliche Barrierefreiheit sind, stellt sich umgekehrt die Frage, ob fehlende PDF/UA-Konformität automatisch als Beleg für fehlende Barrierefreiheit gewertet werden sollte. Vielleicht liegt die Wahrheit – wie so oft – irgendwo dazwischen.
Das Dokument können Sie hier herunterladen und die einzelnen PAC-Meldungen, deren technische Hintergründe und ihre praktischen Auswirkungen selbst nachvollziehen.
