Barrierefreie Dokumentenaufbereitung (PDF/UA-Tagging, Alternativtexte, EAA/BITV)

Die meisten im Umlauf befindlichen PDFs sind nicht getaggt: Ein Screenreader sieht nur einen flachen Textstrom, ohne Überschriften, ohne Tabellenstruktur, ohne Lesereihenfolge und ohne Bildbeschreibungen. Seit der European Accessibility Act (EAA) am 28. Juni 2025 zu gelten begann, und da die Web-Zugänglichkeitsrichtlinie und die BITV 2.0 öffentliche Stellen bereits binden, ist dies ein Compliance-Rückstand. Layoutmodelle und Bild-Sprach-Modelle (VLM) können Dokumente automatisch taggen, Alternativtexte vorschlagen und validierte Ausgaben erzeugen, während Fachleute für Barrierefreiheit prüfen, was Maschinen nicht beurteilen können. Das Ergebnis ist nur ein Bruchteil des manuellen Aufbereitungsaufwands, mit einer belastbaren Nachweiskette.

Problem & Nutzen

• Heute: Die Aufbereitung ist Handarbeit in Acrobat Pro oder Spezialwerkzeugen: jede Überschrift taggen, Tabellenköpfe korrigieren, Inhalte ordnen, Alternativtexte schreiben, Sprache und Titel setzen. Agenturen rechnen pro Seite ab; Rückstände von Tausenden Alt-PDFs (Handbücher, Preislisten, Kontoauszüge, Verträge, Vorlesungsfolien) bleiben unzugänglich. Viele Organisationen bereinigen nur neue Dokumente.
• KI-Nutzen: Automatisches Tagging erledigt den Großteil der Struktur; VLMs entwerfen Alternativtexte und Tabellenzusammenfassungen; automatische Prüfprogramme sortieren vor, welche Dateien bestehen; Menschen investieren Zeit nur in die durchgefallenen und risikoreichen Dokumente. Am besten wird an der Quelle behoben (barrierefreie Word-/InDesign-Vorlagen), und die KI bereitet den Rest auf.
• Regulatorischer Treiber: Der EAA (Richtlinie (EU) 2019/882) gilt seit dem 28. Juni 2025 für Produkte und Dienstleistungen, darunter E-Commerce, Bankdienstleistungen für Verbraucher, E-Books und Informationen zum Personenverkehr; barrierefreie Dokumente sind Teil der Informationen, die eine Dienstleistung bereitstellen muss. Öffentliche Stellen unterliegen der Web-Zugänglichkeitsrichtlinie (EU) 2016/2102 und in Deutschland der BITV 2.0. Technische Referenz ist EN 301 549, die WCAG einbezieht [1][2].
• Grenze der Nutzenaussagen: Einen unabhängigen Benchmark zur Zeitersparnis, den wir hätten überprüfen können, gibt es nicht; Anbieter berichten von großen Einsparungen, doch laut Adobe-Dokumentation decken automatische Prüfungen nur einen Teil der PDF/UA- und WCAG-Kriterien ab, und eine manuelle Prüfung bleibt erforderlich, sodass vollständige Automatisierung nicht erreichbar ist [3][4].

Varianten

• Öffentlicher Sektor (BITV 2.0 / WAD): Barrierefreiheitserklärung, an Webseiten angehängte PDFs, Formulare, Ratsvorlagen und Jahresberichte.
• Finanzdienstleistungen: Kontoauszüge, Verträge, Versicherungspolicen, die in großer Menge direkt aus dem Output-Management-System in barrierefreier Form erzeugt werden (Tagging auf Vorlagenebene).
• Verlagswesen und E-Books: EPUB Accessibility und PDF/UA für Bücher, Berichte, Zeitschriften.
• Bildung (siehe EDU-001, EDU-009): Vorlesungsfolien, Skripte und Prüfungsbögen, die für Studierende mit Behinderungen barrierefrei gemacht werden; MINT-Formeln benötigen MathML oder beschriebene Alternativen.
• Alternativtexte für Web und Medien: Alternativtexte in großer Zahl für Bildbibliotheken und CMS (verwandt: CODE-017 für Webcode, SPEECH-014 für Audiodeskription von Videos).
• Formulare: barrierefreie ausfüllbare Felder, Beschriftungen, Tabulatorreihenfolge, Tooltips.
• Begleitung in Leichter Sprache: mit Fassungen in einfacher Sprache kombinieren (LANG-010).

So funktioniert es

1. intake (upload, DMS/CMS hook, batch folder)
2. source detection (Office/InDesign source available?
3. fix at source | PDF only)
4. OCR for image-only pages (language detection)
5. layout analysis: regions, reading order, headings, lists, tables, headers/footers (artifacts)
6. structure tree generation (PDF tags: H1-H6, P, L, Table, Figure, Link)
7. alt text drafting for figures/charts (VLM, context-aware, decorative detection)
8. metadata: title, language (incl. language changes), bookmarks, tab order
9. validation: veraPDF / Acrobat checker / PAC, WCAG rules
10. human QC on flagged items (reading order, alt text, complex tables, contrast)
11. publish + report (pass/fail, residual issues, accessibility statement input)

• Layout und Lesereihenfolge: Dokumentlayout-Modelle oder VLMs klassifizieren Blöcke und ordnen sie, auch bei mehrspaltigen Seiten; am schwächsten bei komplexen Layouts, gedrehtem Text und verschachtelten Tabellen.
• Alternativtext: Ein VLM erhält das Bild samt umgebendem Text und Bildunterschrift und schreibt eine kurze Beschreibung; Diagramme erhalten eine Zusammenfassung der Kernaussage plus eine Datentabelle. Dekorative Bilder werden als Artefakte markiert.
• Validierung: Deterministische Regelprüfer entscheiden über die maschinell prüfbare Konformität; die KI bewertet sich nicht selbst.
• Mensch-in-der-Schleife (Human-in-the-Loop): Eine geschulte Prüfperson gibt Alternativtexte für aussagekräftige Bilder frei, prüft Lesereihenfolge und Tabellenköpfe und zeichnet Dokumente mit rechtlichem Risiko ab.

Datenaufbereitung

Die Eingabe sind überwiegend vorhandene PDFs und Office-Dateien: Broschüren, Formulare, Berichte, Verträge und Web-Downloads. Im Mittelstand liegen sie im Website-CMS, im DMS oder auf Dateiservern, oft nur als exportiertes PDF ohne die bearbeitbare Quelle. Typische Lücken sind eingescannte reine Bild-PDFs (ohne Textebene), fehlende Dokumentsprache, Duplikate in mehreren Versionen und keine Liste, welche Dateien tatsächlich öffentlich und damit im Geltungsbereich sind.

Vorbereitungsschritte: 1. Öffentlich zugängliche Dokumente inventarisieren (Web-Crawl plus CMS-Export) und nach Zugriffszahlen und rechtlichem Risiko ordnen; veraltete Dateien aussondern, statt sie aufzubereiten (siehe PREP-001 und PREP-005). 2. Eingescannte Dateien zuerst per OCR verarbeiten (PREP-006, DOC-014, DOC-018), danach Sprache und Titel in den Metadaten korrigieren. 3. Wo möglich die bearbeitbare Quelle (Word, InDesign) ausfindig machen, damit die Barrierefreiheit an der Quelle hergestellt wird und nicht immer wieder im PDF. 4. Eine kleine Referenzmenge bereits korrekt getaggter Dateien als Qualitätsmaßstab bereithalten (PREP-016).

Grober Anteil am Gesamtaufwand: etwa 10-20 Prozent, überwiegend für Inventur und OCR; das Tagging selbst ist Aufgabe des Produkts. Dateien vor dem Senden an einen Cloud-Dienst auf personenbezogene Daten prüfen.

Umsetzungswege

Welcher Weg für wen

• KMU: A — ausgereifte, in der EU hostbare Aufbereitungswerkzeuge sind zu KMU-tauglichen Preisen verfügbar, und PDF/UA-Tagging ist ein standardisierter, klar definierter Prozess.
• Großunternehmen: A — die Aufbereitung für Barrierefreiheit ist eine Standard-Compliance-Funktion; B nur dort, wo sie in eine eigene Publikationspipeline eingebunden werden muss.
• Entwickler: B — Cloud-Layout- und Bild-APIs erlauben es, Tagging und Alternativtexte in den eigenen Dokumenten-Workflow einzubetten, ohne GPUs zu betreiben.
• Öffentliche Hand: A — öffentliche Stellen profitieren am meisten von zertifizierten Produkten mit dokumentierten PDF/UA- und BITV-Nachweisen; Selbstbetrieb bringt bei nicht sensiblen Inhalten wenig.

Weg A — Kaufen (für die meisten Organisationen empfohlen)

• Auto-Tagging- und Aufbereitungssuiten: Adobe Acrobat Pro und Acrobat Services (Auto-Tag API), CommonLook (Teil von Allyant), Foxit, Allyant (Aufbereitungsdienste und Werkzeuge), axes4 / axesPDF und der kostenlose PAC-Prüfer (Schweiz), PDFix, Equidox, Grackle Docs (übernahm 2024 AbleDocs) sowie die integrierte Barrierefreiheitsprüfung von Microsoft Word mit Alternativtext-Vorschlägen.
• Dienstleistungen: Agenturen für Barrierefreiheit und Aufbereitungsdienstleister, die KI-gestützte Stapelverarbeitung mit menschlicher Qualitätssicherung anbieten, nützlich für einmalige Altbestände.
• A wählen, wenn: das Volumen bei einigen Tausend Dokumenten oder darunter liegt, die Formate Standard sind und die Ausgabe schnell belastbar sein muss. Prüfen: Unterstützung von PDF/UA-1 und PDF/UA-2, Export des Prüfberichts, Datenhaltung in der EU, Stapelverarbeitung/API-Zugang, Unterstützung für Deutsch und andere EU-Sprachen.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Adobe PDF Services: PDF Accessibility Auto-Tag API (ergänzt Tags, Überschriften-, Listen- und Tabellenstruktur, Lesereihenfolge; optional ein Bericht) und die Accessibility Checker API (maschinell prüfbare PDF/UA- und WCAG-Kriterien, Bericht als HTML oder JSON); REST mit SDKs für Java, .NET, Node und Python [3][4].
• VLM- und Dokumenten-KI-Dienste: Azure AI Document Intelligence Layout-Modell (EU-Regionen), Google Document AI Layout Parser, Mistral OCR (EU-Anbieter) und multimodale Spitzenmodelle mit strukturierten Ausgaben für Alternativtexte und Tabellenbeschreibungen.
• Orchestrierung: n8n oder Power Automate, eine Warteschlange mit Prüf-Oberfläche, DMS- oder CMS-Anbindungen. Den Validator immer in der Schleife halten: erzeugen, prüfen, wiederholen oder eskalieren.
• B wählen, wenn: Dokumente in den eigenen Systemen erzeugt werden und Sie Tagging in der Erzeugung wollen, oder wenn Sie eine Integration in einen CMS-Upload-Ablauf brauchen.

Weg C — Selbst betreiben (Open Source)

• Parsing und Layout: Docling (IBM, mit Granite-Docling), MinerU, PaddleOCR / PaddleOCR-VL, Marker zur Strukturextraktion.
• Alternativtext: offene VLMs wie die Qwen-VL-Familie oder Gemma 3 über vLLM oder Ollama, mit Prompts, die Bildunterschrift und nahen Text enthalten.
• PDF-Schreiben und Tagging: PDFBox, pikepdf, iText (AGPL/kommerziell), das LaTeX-Projekt für getaggte PDFs und Typst für die barrierefreie Erzeugung.
• Validierung: veraPDF (quelloffener PDF/A- und PDF/UA-Validator, unterstützt von der PDF Association) [5].
• Hardware: HW2 genügt für ein 7-8B-VLM, das Alternativtexte liefert; das Tagging selbst ist CPU-Arbeit. Aufwand: Sie müssen den Strukturbaum-Schreiber und die QS-Oberfläche selbst bauen; das ist der schwerste Teil.

Weg D — Eigenes Training

Lohnt sich nur bei hohen Volumina eines Dokumenttyps (z. B. eine Bank mit Zehntausenden Kontoauszugsvarianten). Ein Layout- oder Lesereihenfolge-Modell wird auf Paaren aus ungetaggten PDFs und von Fachleuten korrigierten Tag-Bäumen feinabgestimmt (Feintuning); Korrekturen der Prüfpersonen aus Pipelines der Wege A/B sind der natürliche Datensatz.

Stand der Technik (2026)

• Standards: PDF/UA-1 (ISO 14289-1) bleibt die praktische Basis; PDF/UA-2 (ISO 14289-2, für PDF 2.0) ist veröffentlicht, und die Werkzeuge ziehen nach [6]. Der EAA-Text selbst nennt PDF/UA nicht; die Konformität wird über EN 301 549 und WCAG beurteilt, und PDF/UA ist der übliche technische Weg für PDFs (Auslegung der Anbieter, mit Rechtsberatung abklären) [2][6].
• Modelle: Dokumentlayout-Modelle und VLMs rekonstruieren Lesereihenfolge und Tabellen weit besser als das regelbasierte Auto-Tagging von vor einigen Jahren; Alternativtexte von VLMs sind flüssig und bei Fotos meist zutreffend.
• Wo es scheitert: komplexe oder verschachtelte Tabellen, mehrspaltige Magazine, Diagramme, deren Aussage Fachinterpretation braucht, Formeln, Formulare mit unbeschrifteten Feldern, Scans mit schlechter OCR, gemischte Sprachen und die Unterscheidung aussagekräftig vs. dekorativ. VLMs können im Alternativtext Inhalte erfinden oder beschreiben, was sichtbar ist, statt was wichtig ist.
• Maschinelle Prüfungen sind keine Konformität: Automatische Prüfprogramme decken nur einen Teil der Kriterien ab; den Rest (ist der Alternativtext aussagekräftig, ist die Lesereihenfolge logisch) müssen Menschen beurteilen [3].
• Trend: Tagging bei der Erstellung (barrierefreie Vorlagen, getaggte PDF-Ausgabe aus Autorenwerkzeugen) plus KI-Aufbereitung für Altdateien.

Gemeinsame Bausteine & Kombinationen

• Gleicher Stack wie DOC-014 (Layout-Parsing für RAG), DOC-005 (OCR schwieriger Scans) und DOC-008 (Posteingangsklassifikation, um Dokumente in die Aufbereitungswarteschlange zu leiten): ein OCR-/Layout-Dienst und ein VLM-Server (HW2) bedienen alle.
• DOC-018 (Anonymisierung) vor dem Senden sensibler Dokumente an externe APIs.
• LANG-010 für Fassungen in Leichter Sprache; CODE-017 für Barrierefreiheit im Web; SPEECH-014 für Video; EDU-001/EDU-009 für barrierefreie Lehrmaterialien.
• Gemeinsame Komponenten: Workflow-Engine, Prüf-Oberfläche, Validator, Audit-Protokoll.

Aufwand, Kosten & Kennzahlen

• Weg A: Tage bis Wochen bis zum Pilot; Preis pro Nutzer, pro Seite oder pro Dokument; Aufbereitung durch Agenturen wird pro Seite berechnet.
• Weg B: 1-3 Monate für eine Pipeline mit CMS-/DMS-Integration und Prüf-Oberfläche; die API-Kosten pro Seite sind im Vergleich zur manuellen Aufbereitung gering.
• Weg C: 3-6 Monate; Strukturbaum-Schreiber und QS-Oberfläche sind der Hauptaufwand.
• Kostentreiber: Seitenzahl, Komplexität (Tabellen, Diagramme, Formulare), Anteil mit manueller Qualitätssicherung, QS-Personal.
• Kennzahlen: Anteil der Dokumente, die die automatischen Prüfungen bestehen, Anteil, der die manuelle QS besteht, durchschnittliche Minuten menschlicher Arbeitszeit pro Seite, Abbau des Rückstands, Anzahl der Beschwerden zur Barrierefreiheit, Anteil der Dokumente, die bei der Erstellung barrierefrei sind.

Menschen & Veränderung

Beziehen Sie die Geschäftsleitung früh für Budget und die Barrierefreiheitserklärung ein, die Abteilungsleitung (meist Kommunikation oder Marketing) als Prozessverantwortliche, die IT für die Anbindung von Website und DMS sowie Legal/Compliance für den Geltungsbereich von EAA/BITV. Endnutzer wie Redakteure brauchen eine kurze Einweisung in das Schreiben barrierefreier Quelldokumente.

Betriebsrat: In der Regel keine Mitbestimmung nach §87 Abs. 1 Nr. 6 BetrVG, weil das Werkzeug Dokumente verarbeitet, nicht das Verhalten von Beschäftigten; prüfen Sie dies, wenn der Anbieter Aktivitäten je Nutzer protokolliert. Nach §90 Abs. 1 Nr. 3 BetrVG ist der Betriebsrat rechtzeitig zu informieren, wenn sich Redaktionsabläufe spürbar ändern. In öffentlichen Stellen ist der Personalrat in gleicher Weise zu informieren.

Datenschutz: Dokumente mit personenbezogenen Daten (Lebensläufe, Formulare) erfordern mit jedem Cloud-Anbieter einen AVV (Art. 28 DSGVO); eine DSFA ist in der Regel nicht nötig. KI-Kompetenz: Art. 4 der KI-Verordnung (AI Act) verlangt von Arbeitgebern, die KI-Kompetenz der Beschäftigten zu fördern; bieten Sie daher eine kurze Schulung zur Prüfung KI-erzeugter Alternativtexte an.

Kommunikation und Pilot: Beginnen Sie mit 20-50 stark genutzten Dokumenten, die ein Redaktionsteam bearbeitet. Typische Sorge: „Die KI ersetzt unsere Fachkraft für Barrierefreiheit.“ Antworten Sie, dass Fachleute die Ergebnisse prüfen und komplexe Tabellen, Formulare und Diagramme übernehmen. Die Freigabe jeder veröffentlichten Datei bleibt beim Menschen. Siehe GUIDE-006, GUIDE-008 und GUIDE-009.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): minimales Risiko als Dokumentenwerkzeug; die Pflicht zur KI-Kompetenz (Art. 4) gilt. Wird der Alternativtext von generativer KI zur Veröffentlichung erzeugt, prüfen Sie, ob Kennzeichnungspflichten (Art. 50) in Ihrem Kontext greifen; in der Praxis ist der Alternativtext kein täuschendes synthetisches Medium; die Prüfung sollte aber vermerkt werden.
• EAA, WAD, BITV 2.0: Nicht konforme Ausgaben bergen rechtliche Risiken und Risiken aus der Marktüberwachung; Kleinstunternehmen, die Dienstleistungen erbringen, sind nach dem EAA ausgenommen, und es gibt Klauseln zur unverhältnismäßigen Belastung, beides erfordert jedoch eine dokumentierte Bewertung [1].
• DSGVO: Dokumente (Personal, Medizin, Kundenauszüge) enthalten personenbezogene Daten; die Nutzung externer APIs erfordert einen Auftragsverarbeitungsvertrag und eine EU-Region; schwärzen Sie zuvor, wenn die Daten nicht gebraucht werden (DOC-018).
• Qualitätsrisiken: Eine falsche Lesereihenfolge oder irreführende Alternativtexte können schlimmer sein als keine. Gegenmaßnahmen: menschliche Qualitätssicherung für gut sichtbare Dokumente und Audit-Protokolle zu KI-Tags im Vergleich zu den endgültigen Tags.
• Überzogene Aussagen: Veröffentlichen Sie keine Erklärung „vollständig barrierefrei“, die allein auf einem automatischen Prüfprogramm beruht.

Erste Schritte

1. Dokumente inventarisieren: Anzahl, Alter, Verfügbarkeit der Quelle, Sichtbarkeit; öffentliche, kundennahe und häufig genutzte Dateien priorisieren.
2. Die Quelle beheben: barrierefreie Word-/InDesign-Vorlagen und das Output-Management-System für neue Dokumente.
3. Ein automatisches Prüfprogramm (Acrobat, PAC, veraPDF) über eine Stichprobe von 100 Dokumenten laufen lassen, um die Lücke abzuschätzen.
4. Zwei oder drei Werkzeuge aus Weg A oder die Adobe-APIs an den schwierigsten Mustern pilotieren, wobei eine Fachkraft für Barrierefreiheit die Ausgabe prüft.
5. Den QS-Ablauf und die Freigaberegeln festlegen, dann den Rückstand in der Reihenfolge der Priorität abbauen und die Ergebnisse für die Barrierefreiheitserklärung festhalten.

Quellen

1. European Commission — European Accessibility Act — https://commission.europa.eu/strategy-and-policy/policies/justice-and-fundamental-rights/disability/union-equality-strategy-rights-persons-disabilities-2021-2030/european-accessibility-act_en
2. Directive (EU) 2019/882 (European Accessibility Act), EUR-Lex — https://eur-lex.europa.eu/eli/dir/2019/882/oj
3. Adobe — PDF Accessibility Auto-Tag API — https://developer.adobe.com/document-services/apis/pdf-accessibility-auto-tag/
4. Adobe — PDF Accessibility Checker API — https://developer.adobe.com/document-services/apis/pdf-services/check-pdf-accessibility/
5. veraPDF — open source validator — https://verapdf.org/
6. PDF Association — ISO 14289-2 (PDF/UA-2) — https://pdfa.org/iso-14289-2-pdf-ua-2-the-gold-standard-for-accessibility-in-pdf-2-0-has-arrived/
7. PDFix — EAA PDF compliance — https://pdfix.net/pdf-compliance-software/european-accessibility-act-eaa-pdf-compliance/
8. Docling project — https://github.com/docling-project/docling
9. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj