Wir haben PDFs aus der Praxis gegen PDF/UA-1 geprüft. Ein Tool hat die Konformität in einem einzigen Durchgang zerstört.

Die Kurzfassung: Die Fehler häufen sich je nach Produktionstool, nicht je nach Nachlässigkeit der Autoren. Und eines dieser Tools nimmt eine vollständig konforme Datei und zerstört sie in einem einzigen Durchgang – während es die Datei um 20 % verkleinert, was genau der Grund ist, warum jemand es ausführt.

Was wir gemessen haben und was nicht

Hinter diesem Artikel liegen zwei Datenebenen.

Die breite Ebene ist ein Crawl von 1.682 ungarischen kommunalen Websites, die 8.469 PDFs abdecken. Dieser Crawl führte keine vollständige Validierung durch – er prüfte vier einfache Signale pro Datei: ob der Seiteninhalt ein gescanntes Bild ist, ob ein Strukturbaum vorhanden ist, ob das Dokument einen Titel hat und ob eine Sprache deklariert ist. Allein aufgrund dieser vier Signale hatten 5.433 Dateien (64 %) mindestens ein Problem.

Von den 1.682 Websites veröffentlichten 1.215 mindestens ein PDF. Von diesen 1.215 hatten genau 39 keine fehlerhafte Datei.

Diese vier Signale sind keine PDF/UA-Konformität. Sie sind der denkbar einfachste Proxy, und das möchte ich explizit betonen, denn die Lücke zwischen „erfüllt die vier Signale“ und „ist tatsächlich konform“ erweist sich als eine der Erkenntnisse.

Die enge Ebene ist diese: fünf echte Dokumente aus diesem Crawl, plus eines von uns, wurden durch veraPDF 1.30.2 (Build 2026-06-03) gegen das PDF/UA-1-Profil geprüft. veraPDF ist der Open-Source-PDF/UA-Validator, der vom veraPDF-Konsortium entwickelt und vom PREFORMA-Projekt der EU finanziert wurde – sein eigener --version-Output besagt genau das. Wenn er einen Fehler gemäß Klausel 7.1-3 meldet, spricht der Standard, kein Anbieter.

~/.local/share/verapdf/verapdf -f ua1 --format json document.pdf

Warum ungarische Kommunen für deutsche Leser relevant sind

Weil die Werkzeugkette dieselbe ist. Word, Kopierer, Ghostscript – nichts davon ist landesspezifisch, und keiner der unten beschriebenen Fehler hat etwas mit Ungarn zu tun. Die Anforderung ist ebenfalls dieselbe. Für öffentliche Stellen des Bundes schreibt die BITV 2.0 barrierefreie Dokumente vor. Für bestimmte Produkte und Dienstleistungen – darunter der elektronische Geschäftsverkehr, Bankdienstleistungen für Verbraucher und E-Books – gilt seit dem 28. Juni 2025 eine vergleichbare Pflicht aus dem Barrierefreiheitsstärkungsgesetz (BFSG). Wenn Sie wissen wollen, wie Ihr eigener Dokumentenbestand abschneidet, ist die Messung unten die Vorlage dafür.

Die fünf kommunalen Dateien sind unten als Doc A bis Doc E gekennzeichnet. Es handelt sich um öffentliche Dokumente auf öffentlichen Websites, aber die Nennung der Gemeinden würde den Schwerpunkt falsch setzen: Bei 39 sauberen Websites von 1.215 ist dies keine Geschichte darüber, welche Gemeinde es falsch gemacht hat.

Die Ergebnisse

Lesen Sie die Spalte Producer, nicht die Fehleranzahl. Jedes dieser Dokumente wurde von einer Person verfasst, die ihre Arbeit erledigte, und jeder Fehler unten ist eine Eigenschaft der Software, die die Datei ausgegeben hat.

Doc A: fast hätte es gereicht

Doc A ist ein Word 2013-Export, und Word hat seinen Teil ordnungsgemäß erledigt. Die Datei hat einen Strukturbaum, MarkInfo/Marked steht auf true, und /Lang ist auf hu-HU gesetzt. Die Person, die es exportiert hat, hatte allen Grund zu der Annahme, dass die Arbeit erledigt war.

Sie scheitert an vier Prüfungen:

• 7.21.4.1-1 (×2) — zwei Schriftarten sind nicht eingebettet: TimesNewRomanPSMT und TimesNewRomanPS-BoldMT
• 7.1-8 — kein XMP-Metadatenstrom im Katalog
• 7.1-10 — ViewerPreferences hat kein DisplayDocTitle

Nichts davon ist sichtbar, wenn Sie die Datei öffnen. Zwei davon sind einmalige Einstellungen im Export-Dialog. Das dritte – DisplayDocTitle – ist der Grund, warum ein Screenreader 2021.-evi-munkaterv.pdf ankündigt anstelle des tatsächlichen Titels des Dokuments, und Word hat dafür überhaupt kein Kontrollkästchen.

Dies ist die Datei, auf die ich zeigen würde, wenn jemand sagt, Barrierefreiheit sei eine Frage der Anstrengung. Jemand hat sich hier angestrengt. Die Werkzeugkette hat trotzdem verloren.

Doc E: den falschen Test bestehen

Doc E ist der Punkt, an dem unsere eigenen einfachen Crawl-Signale peinlich werden.

Der Crawl erfasste es als gescannt, getaggt und mit einem Titel versehen – auf dem Papier besser als Doc A. Öffnet man es, ändert sich das Bild:

Producer : Lexmark CX622ade
Creator  : HardCopy
/Title   : "Scanned Document"
StructTree: True

Ein Kopierer scannte ein Papierdokument, erzeugte einen Strukturbaum über dem Bild und schrieb die wörtliche Zeichenfolge Scanned Document in das Titelfeld. Unsere Signalprüfung sah has_title = true. Einem Screenreader-Benutzer wird mitgeteilt, dass er ein Ding namens „Scanned Document“ geöffnet hat.

Wenn Sie irgendeine Art von automatisierter Bewertung der Barrierefreiheit aufbauen, ist dies der Fehlermodus, gegen den Sie konzipieren müssen: Vorhandensein ist nicht gleichbedeutend mit Nützlichkeit. Zwei unserer vier Signale – hat-Titel und ist-getaggt – wurden hier von einem Kopierer erfüllt, der nichts über das Dokument verstand, das er scannte.

Doc C: der interessante Fall

Doc C hat 5.997 fehlgeschlagene Prüfungen auf 53 Seiten – 3.223 Teile nicht getaggten Inhalts und 2.290 Textabschnitte ohne bestimmbare Sprache. Es hat überhaupt keinen Strukturbaum.

Die Metadaten sind das, was es einen Abschnitt wert macht:

Creator  : Microsoft® Word for Microsoft 365
Producer : GPL Ghostscript 10.06.0

Creator wird von der Anwendung geschrieben, in der das Dokument verfasst wurde. Producer wird von dem geschrieben, was die Datei zuletzt ausgegeben hat. Also: Word hat dieses Dokument verfasst, und etwas hat es dann durch Ghostscript gejagt, was die Datei erzeugte, die tatsächlich auf der Website liegt.

Wir wissen, dass der Word-Export Struktur enthält, denn Doc A in der obigen Tabelle ist ein Word-Export und es hat einen Strukturbaum, ein Marked-Content-Flag und eine Sprache. Dasselbe Autorentool, gegenteiliges Ergebnis – der Unterschied ist das, was nach dem Export passierte.

Das ist eine Hypothese, kein Ergebnis. Also haben wir es getestet.

Das Experiment

Nehmen Sie eine Datei, von der wir wissen, dass sie konform ist: unsere eigene Beispielausgabe, die veraPDF als compliant: true mit null Verstößen meldet. Führen Sie einen Ghostscript-Befehl aus:

gs -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dPDFSETTINGS=/prepress \
   -o after.pdf before.pdf

Dann validieren Sie erneut.

Ein Durchgang. Der Strukturbaum, das Marked-Content-Flag, die Dokumentsprache und die Einstellung zur Titelanzeige sind alle weg.

Wir haben /prepress verwendet, das ist die qualitätserhaltende Voreinstellung – daher ist es fair zu fragen, ob eine echte Komprimierungseinstellung sich anders verhält. Tut sie nicht. Alle vier Standard-Voreinstellungen erzeugen das identische Validierungsergebnis:

Die Voreinstellung steuert die Bildqualität. Sie hat keinen Einfluss darauf, ob die Struktur überlebt, denn die Struktur ist keine Bilddaten – sie ist der Teil der Datei, den pdfwrite überhaupt nicht neu aufbaut.

Und die Seiten selbst? Gerendert mit 144 DPI und in Graustufen verglichen, erzeugen /prepress und /ebook null unterschiedliche Pixel von 2.005.644 pro Seite über alle fünf Seiten hinweg – die größte Abweichung in einem Einzelkanal beträgt 4 von 255, was kein Auge finden wird. Nur /screen ändert etwas Sichtbares, und nur auf einer von fünf Seiten, wo ein Foto herunterskaliert wird: 1,4 % der Pixel unterscheiden sich dort.

Der visuelle Preis dieser Operation hängt also von der gewählten Voreinstellung ab. Der Preis für die Barrierefreiheit nicht.

Ghostscript 10.07.1 wurde für die Reproduktion verwendet; die Datei in freier Wildbahn stammte von 10.06.0.

Es lohnt sich, präzise zu sein, was hier dokumentiert ist und was nicht, denn das ist der Teil, den die Leute prüfen wollen. Ghostscripts offizielle High Level Devices-Dokumentation erwähnt niemals logische Struktur, Tagging, Barrierefreiheit oder PDF/UA. Was sie jedoch sagt, ist (aus dem Englischen übersetzt), dass pdfwrite eine neue Datei erzeugt, bei der „das tatsächliche Innere des PDF-Datei nicht dasselbe ist wie das Original“ und dass „jeder Teil der ursprünglichen Eingabe, der nicht tatsächlich Markierungen auf der Seite vornimmt (wie Hyperlinks, Lesezeichen, Kommentare usw.), normalerweise nicht in der Ausgabe vorhanden sein wird“.

Ein Strukturbaum hinterlässt keine Markierungen auf der Seite. Er ist, im Sinne dieses Satzes, genau die Art von Ding, das „normalerweise nicht in der Ausgabe vorhanden sein wird“ – und die obige Messung zeigt, wie das in einem echten Dokument aussieht.

Dies ist also eher ein erwartetes Verhalten als ein Fehler. Aber es ist ein erwartetes Verhalten, das in einem Satz über Hyperlinks und Kommentare beschrieben wird, auf einer Seite, die niemals das Wort Barrierefreiheit verwendet – und der Befehl selbst gibt keine Warnung aus.

Was dies in der Praxis ändert

Validieren Sie nach dem letzten Schritt, nicht nach dem Verfassen

Wenn Ihr Workflow Word → PDF → optimieren → veröffentlichen ist, dann sagt Ihnen die Validierung des Exports nichts über die Datei, die Ihre Benutzer herunterladen. Der Autor von Doc C hat mit ziemlicher Sicherheit ein getaggtes PDF erstellt und nie gesehen, was veröffentlicht wurde.

Überprüfen Sie das Feld Producer auf Ihren veröffentlichten Dateien

Zwei Felder sagen fast alles aus: Creator nennt das Programm, in dem das Dokument geschrieben wurde, Producer nennt das, was die Datei zuletzt ausgegeben hat. Wenn im Feld Creator Word steht und im Feld Producer Ghostscript, ein Druckermodell oder ein Komprimierungsprogramm, dann ist Ihr Strukturbaum wahrscheinlich weg – und Sie können beides sehen, ohne etwas zu installieren.

python -c "import pikepdf,sys; print(pikepdf.open(sys.argv[1]).docinfo)" file.pdf

Dateigrößenoptimierung ist bei getaggten PDFs destruktiv

Komprimieren Sie die Bilder, bevor Sie das barrierefreie PDF erstellen, nicht danach.

Wo der Validator aufhört

Unsere eigene Beispieldatei besteht mit null Verstößen, und ich möchte ehrlich darüber sein, was dieses grüne Ergebnis bedeutet und was nicht.

veraPDF prüft die Struktur, nicht den Sinn. Es bestätigt, dass jedes Bild einen Alternativtext enthält, und tut das ebenso bereitwillig, wenn diese Beschreibung image1.png lautet – was in den Dateien, die uns zur Nachbesserung erreichen, häufig der Fall ist.

Die Lesereihenfolge ist der schwierigere Fall. Eine Überschrift, die als H2 getaggt ist, erfüllt den Standard, egal ob sie dorthin gehört, wo sie sitzt, sodass eine Datei die Prüfung sauber besteht, während ein Screenreader die Seite in einer Reihenfolge durchläuft, die kein sehender Leser erkennen würde. Tabellen-Scope-Attribute haben dasselbe Problem, mit der zusätzlichen Schwierigkeit, dass sie wie Semantik aussehen und meistens Vermutungen sind.

Jedes davon ist eine Ermessensentscheidung, und bei jedem davon erhält automatisierte Nachbesserung – unsere eingeschlossen – entweder Hilfe von einem Menschen oder sie macht es falsch. Eine konforme Datei ist die Untergrenze, nicht die Obergrenze. Wer Ihnen den grünen Haken als Ziellinie verkauft, verkauft Ihnen die Untergrenze.

Wenn Sie Ihre eigenen Dokumente prüfen möchten

Führen Sie veraPDF gegen PDF/UA-1 auf den Dateien aus, die Sie tatsächlich veröffentlichen, sortiert danach, wie oft sie heruntergeladen werden, statt danach, wie aktuell sie sind. Beginnen Sie mit dem Feld Producer – es wird Ihnen in Sekunden sagen, ob das Problem Ihre Exporteinstellungen sind oder etwas Nachgelagertes, von dem Sie nicht wussten, dass es dort ist.

Wenn Sie die Fehlerliste für eine Ihrer Dateien sehen möchten, ohne etwas zu installieren, meldet unser PDF-Barrierefreiheits-Checker dieselben Klauseln. Was die Fehler einzeln bedeuten, ist in der PDF/UA-Fehlerreferenz nachzulesen, und der Standard selbst – was PDF/UA-1 erfordert und warum – wird im PDF/UA-Leitfaden behandelt.