Ihre Barrierefreiheitsprüfung in Word besteht. Das PDF fällt trotzdem durch. Hier erfahren Sie, warum.

Sie haben Überprüfen → Barrierefreiheit überprüfen ausgeführt. Word meldete keine Probleme. Sie haben das Dokument als PDF exportiert, jemand hat es validiert, und es kam mit acht Fehlern zurück.

9 Min. Lesezeit

Auf dieser Seite
  1. Was die Barrierefreiheitsprüfung von Word tatsächlich prüft
  2. Die Messung
  3. Das Ergebnis
  4. Wo die Lücke tatsächlich liegt und was dagegen zu tun ist
  5. Was ein grünes Häkchen in Word wert ist

In diesem Ablauf ist nichts schiefgelaufen. Die Prüfung von Word hat ihre Arbeit korrekt erledigt, und der Validator ebenso – sie prüfen schlicht nicht dasselbe. Word betrachtet das Dokument, das Sie geschrieben haben. PDF/UA betrachtet die Datei, die Word ausgegeben hat. Die Lücke zwischen diesen beiden ist der Grund, warum Dokumente im öffentlichen Sektor scheitern, und sie tritt an vorhersehbaren Stellen auf.

Wir haben genau gemessen, wo.

Was die Barrierefreiheitsprüfung von Word tatsächlich prüft

Microsoft veröffentlicht die vollständige Regelliste. Für Word sind es sieben Regeln:

Schweregrad Regel
Fehler Alle nicht-textuellen Inhalte haben Alternativtext
Fehler Tabellen geben Spaltenüberschriften an
Fehler Dokumentzugriff ist nicht eingeschränkt
Fehler Alle Inhaltssteuerelemente haben Titel
Warnung Tabelle hat eine einfache Struktur
Warnung Ausreichender Kontrast zwischen Text und Hintergrund
Tipp Dokumente verwenden Überschriftenformate

Das ist der vollständige Satz (Regeln für die Barrierefreiheitsprüfung).

Beachten Sie, was nicht darauf steht: der Dokumenttitel, die Schriftarteneinbettung, Metadaten oder irgendetwas anderes bezüglich des PDF-Exports. Was völlig vernünftig ist – die Barrierefreiheitsprüfung ist eine Word-Funktion, keine PDF-Funktion, und sie hat keine Meinung zu einer Datei, die noch nicht existiert.

Das Problem ist, dass jeder ein grünes Ergebnis als „dieses Dokument ist barrierefrei“ interpretiert, während es eigentlich bedeutet: „die sieben Dinge, die Word sehen kann, sind in Ordnung“.

Die Messung

Wir haben den Crawl aus unserem früheren Artikel über reale PDFs herangezogen — 1.682 ungarische Gemeindewebsites, 8.469 PDFs — und daraus 111 „born-digital“ Dokumente heruntergeladen, höchstens eines pro Website, damit keine Gewohnheiten eines einzelnen Büros dominieren.

Zuerst lohnt sich ein Blick darauf, womit sie erstellt wurden:

Produktionskette Dateien Anteil
Microsoft Word 60 54 %
nicht identifiziert 28 25 %
Web-Generatoren (TCPDF, wkhtmltopdf u. ä.) 6 5 %
PDF-Komprimierungs-/Nachbearbeitungstools 6 5 %
Adobe (Acrobat / Distiller) 4 4 %
Kopierer / Scanner 3 3 %
LibreOffice / OpenOffice 2 2 %
PDF-Druckertreiber 2 2 %

Mehr als die Hälfte von allem, was eine Gemeinde veröffentlicht, stammt aus Word. Jeder Versuch, die Barrierefreiheit von Dokumenten im öffentlichen Sektor in großem Maßstab zu verbessern, muss dort ansetzen und nicht bei einem Spezialwerkzeug oder einem Dienstleister für barrierefreie Dokumente – obwohl, wie der Rest dieses Artikels zeigt, damit anzufangen noch nicht heißt, damit auch aufzuhören.

Wir haben die in Word erstellten Dateien mit veraPDF 1.30.2 (Build 2026-06-03) gegen PDF/UA-1 validiert. Eine Datei war zu beschädigt für einen Bericht; die anderen 59 sind das Thema des restlichen Artikels.

Ein Vorbehalt vor den Zahlen: Diese Dateien stammten aus der Liste des Crawls mit Dokumenten, die bereits fehlerhaft aussahen, und ein fehlender Dokumenttitel war eines der Dinge, nach denen gesucht wurde. Daher fehlt ihnen allen ein Titel – deshalb sind sie hier. Jeder andere Fehler weiter unten ist etwas, das wir zusätzlich gefunden haben.

Das Ergebnis

Keine der 59 Dateien entspricht PDF/UA-1. Im Median scheitern 8 Prüfungen pro Datei. Die beste scheitert an 1, die schlechteste an 1.311.

Hier ist, wo die Fehler liegen, sortiert danach, wie viele Dateien jeweils betroffen sind – und ob die Barrierefreiheitsprüfung von Word dazu etwas zu sagen hat:

PDF/UA-Klausel Was es bedeutet Betroffene Dateien In Words Regelliste?
5-1 kein PDF/UA-Identifikator in den Metadaten 71 % nein
7.1-9 kein dc:title im XMP-Metadaten-Stream 68 % nein
7.21.4.1-1 Schriftarten nicht eingebettet 64 % nein
7.18.1-2 Anmerkung ohne alternative Beschreibung 37 % nein
7.18.5-2 Link ohne Alternativtext 37 % nein
7.1-10 ViewerPreferences fehlt DisplayDocTitle 34 % nein
7.1-8 kein Metadaten-Stream im Katalog 29 % nein
7.3-1 Abbildung ohne Alternativtext 29 % ja
7.5-1 Tabellenstruktur nicht bestimmbar 17 % ja
7.2-43 Tabellenzeilen mit inkonsistenten Spaltenanzahlen 14 % ja

Lesen Sie die letzte Spalte von oben nach unten: Die drei häufigsten Fehler sind für die Prüfung von Word unsichtbar, und die beiden, die Word prüft, befinden sich fast am Ende.

Die Barrierefreiheitsprüfung von Word sucht danach

Waagerechte Balken der zehn häufigsten PDF/UA-1-Fehler in 59 aus Word exportierten PDFs des öffentlichen Sektors, nach Anteil der betroffenen Dateien. Kein PDF/UA-Identifikator 71 Prozent. Kein dc:title 68 Prozent. Schriftarten nicht eingebettet 64 Prozent. Anmerkung ohne Beschreibung 37 Prozent. Link ohne alternative Beschreibung 37 Prozent. Fehlendes DisplayDocTitle 34 Prozent. Kein Metadatenstrom 29 Prozent. Abbildung ohne Alternativtext 29 Prozent. Tabellenstruktur nicht bestimmbar 17 Prozent. Tabellenzeilen mit uneinheitlicher Spaltenzahl 14 Prozent. Nur die letzten drei stehen in der Regelliste von Word; die obersten drei sind für sie unsichtbar.

Anteil der 59 Dateien, den der jeweilige Fehler traf. Die gestrichelten Balken sind die, nach denen die Prüfung von Word sucht — sie stehen ganz unten.

Die naheliegende Geschichte hier wäre, dass Feedback funktioniert – dass Autoren korrigieren, worauf sie hingewiesen werden. Das habe ich etwa eine Stunde lang geglaubt, bis ich die Nenner überprüft habe, und es stellt sich als falsch heraus.

Ein Fehler beim Alternativtext kann nur in einem Dokument auftreten, das ein Bild enthält. Ein Tabellenfehler erfordert eine Tabelle. Von den 59 Dateien enthalten 29 ein Bild und 21 eine Tabelle – der faire Vergleich ist also nicht gegen alle 59:

Alle Dateien Nur wo das Element existiert
Abbildung ohne Alternativtext (7.3-1) 29 % 59 % (17 von 29)
Tabellenstruktur nicht bestimmbar (7.5-1) 17 % 48 % (10 von 21)
Zeilen mit inkonsistenten Spaltenanzahlen (7.2-43) 14 % 38 % (8 von 21)

Alternativtext ist die bekannteste Aufgabe zur Barrierefreiheit überhaupt, Word stuft ihn als Fehler ein, moderne Versionen nerven Sie während des Tippens damit – und drei von fünf Dokumenten, die ein Bild enthalten, werden immer noch ohne Alternativtext veröffentlicht. Fast die Hälfte der Dokumente mit Tabellen scheitert an der Tabellenstruktur, was Word ebenfalls als Fehler markiert.

Die ehrliche Version ist also weniger angenehm als die, mit der ich begonnen habe. Feedback löst das Problem nicht: Wo Word warnt, scheitert immer noch die Hälfte der Dateien. Feedback gibt Ihnen lediglich eine Chance. Wo es gar kein Feedback gibt – der Identifikator, die Metadaten, die Schriftarten – steigt die Fehlerquote auf zwei Drittel, und nichts im Autorentool hätte Sie jemals darauf hinweisen können.

Wo die Lücke tatsächlich liegt und was dagegen zu tun ist

Schriftarten nicht eingebettet – 64 %

Ein PDF, das auf Times New Roman verweist, ohne die Schriftart mitzuführen, wird mit dem angezeigt, was der Computer des Lesers als Ersatz findet – und die assistive Technologie verliert die Zeichenzuordnung, die sie benötigt, um Text zuverlässig zu extrahieren. In Word ist dies ein Kontrollkästchen, das dort versteckt ist, wo niemand sucht: Datei → Optionen → Speichern → Schriftarten in der Datei einbetten. Aktivieren Sie es, und es gilt für das aktuelle Dokument, weshalb es Teil Ihrer Vorlage sein muss, statt etwas, an das Sie sich erinnern müssen.

Kein Dokumenttitel – und zwei verschiedene Felder namens „Titel“

Ein PDF speichert den Titel an zwei verschiedenen Stellen, und diese können voneinander abweichen. Es gibt das klassische /Title-Feld in den Dokumentinformationen, und es gibt dc:title innerhalb des XMP-Metadaten-Streams – Klausel 7.1-9 prüft den zweiten. In dieser Stichprobe tragen 19 Dateien einen dc:title in XMP, während ihr Dokument-Info-/Title leer bleibt, was für sich genommen wissenswert ist: Ein Validator und ein Screenreader lesen möglicherweise nicht das Feld, das Sie ausgefüllt haben.

Die Korrektur deckt beides ab und dauert zehn Sekunden: Datei → Informationen → Eigenschaften → Titel. Der Titel ist nicht der Dateiname und nicht die H1 auf der ersten Seite; es ist das, was ein Screenreader ansagt, wenn das Dokument geöffnet wird. Wenn es leer ist, hört der Benutzer 2021.-evi-munkaterv.pdf. Die Prüfung von Word wird dies niemals erwähnen – es ist keine der sieben Regeln.

Kein PDF/UA-Identifikator – 71 %

Dies ist in keiner Weise die Schuld des Autors: Word schreibt schlicht nicht die PDF/UA-Deklaration, und es gibt keine Einstellung, die das tut. Eine Datei kann strukturell perfekt sein und trotzdem an Klausel 5-1 scheitern. Dafür ist ein Nachbearbeitungsschritt nötig – was eine echte Lücke in der Werkzeugkette ist, nichts, was Sie im Exportdialog beheben können.

Es gibt noch einen weiteren Punkt, und den sollten Sie zuerst prüfen, wenn Ihr Workflow zusätzliche Schritte enthält: Stellen Sie sicher, dass nach Word niemand die Datei umschreibt. In dieser Stichprobe wurden sechs Dateien nachträglich durch ein Komprimierungstool geschickt, und ein einziger Durchlauf eines solchen zerstört den gesamten Strukturbaum – das ist gut zu wissen, bevor jemand ein Dokument durch einen „PDF verkleinern“-Dienst schickt, um ein Anhangslimit einzuhalten.

Was ein grünes Häkchen in Word wert ist

Word prüft die Dinge, die wirklich einen Menschen erfordern: ob der Alternativtext etwas aussagt, ob die Tabellenüberschriften die tatsächlichen Überschriften sind. Keine Maschine kann entscheiden, was ein Diagramm bedeutet, also muss es ein Mensch tun, und Word hat recht, danach zu fragen. Das ist der Teil der Arbeit, den Software Ihnen nicht abnehmen kann – und, gemessen an den 59 %, der Teil, den die Leute ohnehin überspringen.

Was es Ihnen nicht sagen kann, ist irgendetwas über die Datei, die Sie veröffentlichen wollen. Dafür müssen Sie sich das PDF selbst ansehen, nach jedem Schritt, der es betrifft.

Wenn Sie die klauselweise Liste für eines Ihrer eigenen Dokumente wünschen, meldet unser PDF-Barrierefreiheits-Checker dieselben Klauseln wie veraPDF, und die Fehlerreferenz erklärt, was jede bedeutet und welche automatisch behebbar sind. Beginnen Sie mit einem Dokument, das die Leute tatsächlich herunterladen – ein Formular, eine Gebührenordnung, ein Leitfaden – und nicht mit dem aktuellsten.

Zoltán Csordás

Gründer, a11yfy

Zoltán Csordás ist Accessibility-Entwickler und Gründer von a11yfy. Er baut die PDF/UA-Pipeline hinter a11yfy.com und verbringt die meiste Zeit mit Tag-Bäumen, veraPDF-Berichten und dem, was ein Screenreader daraus macht. 2026 hat er 8.469 PDFs von 1.682 ungarischen Kommunal-Websites geprüft, um das Ausmaß des Problems zu messen. Lebt in Budapest.