LaTeX und Barrierefreiheit: Der aktuelle Stand für Entwickler:innen

Warum LaTeX und Barrierefreiheit lange ein schwieriges Thema waren

LaTeX wurde in den 1980er-Jahren entwickelt, um wissenschaftliche Texte schön zu setzen. Das Ziel war druckreifes Layout – nicht maschinenlesbare Struktur. PDF, das Standard-Ausgabeformat von LaTeX, ist im Kern eine Seitenbeschreibungssprache: Es weiß genau, wo Buchstaben auf der Seite stehen, aber nicht, ob ein Textblock eine Überschrift, eine Bildunterschrift oder ein Fußnotentext ist.

Für ein zugängliches PDF reicht das nicht. Screenreader brauchen semantische Tags(siehe auch unsere Seite zu PDF-Tags ): <H1> für Überschriften, <P> für Absätze, <Table> mit <TH>-Zellen, eine korrekte Lesereihenfolge, Unicode-Mapping aller Glyphen, Sprache, Alternativtexte für Abbildungen.

Ulrike Fischer (LaTeX-Projektteam) hat es in einem 2020er Paper kompakt zusammengefasst: Standard-LaTeX produziert PDFs, in denen man nicht erkennen kann, „ob ein Text eine Abschnittsüberschrift ist oder ein Wasserzeichen oder eine Fußnote, oder ob er zu einer Tabelle gehört". Genau diese Information aber braucht jede Hilfstechnologie.

Die deutsche Bundesfachstelle Barrierefreiheit formuliert in ihrer Handreichung „Barrierefreie PDF-Dokumente erstellen" entsprechend zurückhaltend: LaTeX sei „nur bedingt zur Erstellung barrierefreier Ausgangsdateien" geeignet. Diese Aussage ist historisch korrekt – sie spiegelt aber den Stand vor der Veröffentlichung des neuen LaTeX-Tagging-Kerns wider.

Die alten Pakete: accessibility und axessibility

Wer auf Deutsch oder Englisch nach „LaTeX accessibility" sucht, stößt fast zwangsläufig auf zwei Pakete. Beide sind aus heutiger Sicht nicht mehr empfehlenswert, und es lohnt sich zu verstehen, warum.

accessibility (Schalitz / Clifton)

Das Paket accessibility entstand 2007 als Diplomarbeitsprojekt von Babett Schalitz und sollte tagged PDFs aus LaTeX2ɛ-Dokumenten produzieren. Andy Clifton hat es ab 2019 mit Schalitz' Einverständnis weiterzuführen versucht.

Ehrlich zur technischen Realität: Das Paket erzeugt zwar einen Tag-Tree im PDF, aber die zugrunde liegende PDF-Struktur ist nicht so aufgebaut, dass dieser Tree zuverlässig genutzt werden kann. Konkret:

• Das Paket arbeitet als „Aufsatz" und patched zur Laufzeit Befehle anderer Pakete – jede Änderung am LaTeX-Kern oder an verbreiteten Paketen kann es brechen.
• Section-Tags scheitern, sobald Abschnitte über Seitengrenzen laufen.
• Das Paket war ursprünglich auf KOMA-Script zugeschnitten und mit anderen Dokumentklassen oft inkompatibel.
• Die Validierung mit PAC oder Adobe-Acrobat-Prüfung scheitert typischerweise an Strukturfehlern (fehlende Pg -Einträge im Strukturbaum, falsche Verschachtelung, fehlende Rolemap-Einträge).

Schalitz selbst schrieb 2020: „Ich möchte davon abraten, das Paket weiter zu verwenden. Es ist offensichtlich, dass es in seiner jetzigen Form nicht funktionieren wird, und ich habe weder die Fähigkeiten noch die Zeit, es zu aktualisieren."

Andy Clifton hat die Wartung im Februar 2021 endgültig eingestellt. Sein Fazit auf GitHub: „Accessibility ist daher keine tragfähige Lösung für das Problem, getaggte und strukturierte PDFs aus LaTeX zu produzieren." Er verwies stattdessen auf die offizielle LaTeX-Tagging-Initiative.

axessibility

Das Paket axessibility verfolgt ein anderes, engeres Ziel: Es macht mathematische Formeln für Screenreader zugänglich, indem es den LaTeX-Quellcode der Formel als /ActualText -Attribut an das PDF anhängt. Der Screenreader liest dann den LaTeX-Code vor – also etwa „x squared equals two pi r" statt eines bedeutungslosen Glyphenfetzens.

Das ist in einem sehr engen Sinn nützlich, löst aber das eigentliche Problem nicht: Es entsteht kein getaggtes PDF mit Strukturbaum. Wer axessibility einsetzt, hat zwar lesbare Formeln, aber weiterhin ein unstrukturiertes Dokument ohne <H1>, <P> oder <Table>. Auch PDF/UA-Konformität kann damit nicht erreicht werden.

Das Paket kann sinnvoll mit dem neuen LaTeX-Tagging-Kern kombiniert werden, ist aber kein Ersatz dafür.

Der Wendepunkt: Das LaTeX Tagged PDF Project

Seit etwa 2019 arbeitet das LaTeX-Projektteam unter Federführung von Ulrike Fischer und Frank Mittelbach daran, Tagging in den LaTeX-Kern selbst zu integrieren. Die zentrale Erkenntnis aus dem Scheitern des accessibility -Pakets: Tagging als externes Patch-Paket ist zu fragil. Es muss direkt im Kernel verankert sein.

Mit TeX Live 2025 ist erstmals eine produktionsreife Version verfügbar. Die offizielle Empfehlung des LaTeX-Projektteams vom 1. November 2025: Tagging wird über die Deklaration \DocumentMetadata vor \documentclass aktiviert.

Wichtig zu verstehen: Das Projekt ist ausdrücklich auf PDF/UA-1 und PDF/UA-2 ausgerichtet. Das Ziel ist nicht ein zufällig getaggtes PDF, sondern eines, das die international anerkannten Standards der ISO 14289 erfüllt. Damit ist es auch geeignet, die WCAG 2.1 AA-Anforderungen aus EAA und BFSG zu erfüllen.

Minimalbeispiel mit DocumentMetadata

So sieht ein minimales Dokument aus, das nach aktuellem Stand ein getaggtes, PDF/UA-2-konformes PDF erzeugt:

 \DocumentMetadata 
{
  lang        = de,
  pdfstandard = ua-2,
  pdfstandard = a-4f,
  tagging     = on,
  tagging-setup = {math/setup=mathml-SE}
} \documentclass 
{article} \usepackage 
{unicode-math} % für Mathe + LuaLaTeX 
 \title 
{Beispieldokument} \author 
{Silta} \begin 
{document} \maketitle 
 \section 
{Einleitung}
Dies ist ein Absatz, der automatisch als <P> 
getaggt wird. Auch die Überschrift oben wird automatisch als <H1> 
getaggt. \begin 
{figure} \includegraphics 
[width=8cm, alt={Diagramm der
    Komponenten}]{diagramm.png} \caption 
{Systemüberblick.} \end 
{figure} \end 
{document}

Drei Dinge sind hier neu gegenüber „klassischem" LaTeX:

• Die \DocumentMetadata -Deklaration vor \documentclass – das ist der Einstiegspunkt für das neue Tagging-System.
• Der Schlüssel tagging=on aktiviert das automatische Tagging.
• Der alt -Schlüssel direkt in \includegraphics – jedes Bild braucht entweder einen Alternativtext oder muss als artifact markiert werden.

Das Ergebnis ist ein PDF mit echter Tag-Struktur, in dem Überschriften, Absätze, Listen, Abbildungen und Tabellen automatisch korrekt ausgezeichnet sind. Der Aufwand für Autor:innen bleibt minimal – das System nutzt die ohnehin verwendeten semantischen LaTeX-Befehle ( \section , \begin{itemize} , \caption ) und übersetzt sie in passende PDF-Tags.

Was 2026 schon funktioniert

Mit TeX Live 2025 und dem LaTeX-Release vom 1. November 2025 lassen sich folgende Strukturen automatisch korrekt taggen:

• Überschriften( \section bis \subparagraph ) als <H1> bis <H6>
• Absätze, Hervorhebungen( \textbf , \emph )
• Listen( itemize , enumerate , description ) als <L>-Strukturen mit korrekten <LI>-Einträgen
• Tabellen( tabular ) als <Table> – Header-Zeilen müssen einmalig deklariert werden via \tagpdfsetup{table/header-rows={1,2}}
• Abbildungen( \includegraphics ) mit alt -Schlüssel oder artifact -Markierung
• Querverweise und Verlinkungen via hyperref
• Sprachauszeichnung via lang in \DocumentMetadata
• PDF/A-4 und PDF/UA-2 als Standard-Kombination ( pdfstandard = a-4f und pdfstandard = ua-2 )

Das LaTeX-Team gibt selbst an, dass die Tagging-Ausgabe so weit fortgeschritten ist, dass WCAG 2.1 AA-konforme PDFs aus typischen Dokumenten ohne manuelles Nacharbeiten entstehen können. Overleaf hat das System seit 2025 produktiv integriert.

Was noch nicht oder nur eingeschränkt funktioniert

Genauso wichtig wie das Funktionierende: Wo Vorsicht angebracht ist.

Pakete, die mit Tagging brechen

Das LaTeX-Tagging-Projekt ist eine substanzielle Änderung am Kern – nicht alle Pakete sind dafür angepasst. Beispiel: Im Dezember 2025 brach das verbreitete caption -Paket nach einem \DocumentMetadata -Update. Die Empfehlung des LaTeX-Teams: aktuelles TeX Live verwenden, Pakete aktuell halten und das Dokument regelmäßig neu validieren.

Bekannte Problemfälle (Stand Mai 2026):

• sidenotes , marginnote – Marginalien-Pakete kooperieren nicht zuverlässig mit Tagging.
• Komplexe Custom-Klassen aus Verlagshäusern – brauchen oft eigene Anpassungen.
• Sehr alte Pakete, die direkt in den TeX-Output schreiben (z. B. ältere tikz -Varianten ohne Tagging-Hooks).

Engine-Beschränkungen

Das neue Tagging funktioniert mit pdfLaTeX und LuaLaTeX. LuaLaTeX ist die empfohlene Engine – besonders für Dokumente mit Mathematik. Andere Engines (XeLaTeX, plain pdfTeX, dvipdfmx-Pipelines) sind teils noch nicht unterstützt oder im Beta-Stadium.

Adobe Auto-Tagging zerstört die Struktur

Mathematik bleibt das schwierigste Feld

Mathematik in zugänglichen PDFs ist generell ein offenes Problem – nicht nur in LaTeX. Mehr dazu im nächsten Abschnitt.

Mathematik: Drei Wege, drei Kompromisse

Das LaTeX-Tagging-Projekt bietet drei Methoden, mit denen Formeln in das getaggte PDF eingebettet werden können. Welche die richtige ist, hängt von Zielpublikum und Engine ab.

Eine wichtige Realität: Selbst die beste MathML-Einbettung nützt nur dann etwas, wenn Reader und Screenreader sie auch interpretieren.

• JAWS kann MathML in PDFs derzeit nicht vorlesen (Stand Dezember 2025) – nur in HTML- und Word-Dokumenten.
• NVDA liest MathML in PDFs nur mit dem MathCAT -Addon.
• Adobe Acrobat und viele PDF-Reader ignorieren MathML aktuell.
• VoiceOver auf macOS und iOS hat sehr begrenzte Unterstützung.

Das ist kein LaTeX-spezifisches Problem, sondern eines des gesamten PDF-Ökosystems. Für Dokumente mit zentraler Mathematik ist deshalb eine begleitende HTML-Version mit MathJax oder vergleichbarem oft die robustere Lösung – ergänzend, nicht ersetzend.

PDFs prüfen: veraPDF, PAC, Screenreader

Nach der LaTeX-Kompilierung folgt die Validierung. Vorsicht: kein einzelnes Werkzeug deckt alles ab, und mehrere Tools liefern inkonsistente Ergebnisse.

veraPDF

Aktuell die empfohlene erste Wahl für PDF/UA-2 und PDF/A-4. Open Source, plattformübergreifend, versteht beide Standards. Das LaTeX-Tagging-Team empfiehlt explizit veraPDF.

PAC (PDF Accessibility Checker)

Das verbreitete PAC der Schweizer Stiftung „Access for all" ist Windows-only und versteht derzeit nur PDF 1.7 mit PDF/UA-1, nicht PDF 2.0 mit PDF/UA-2. PDFs mit MathML-Tagging werden von PAC oft als fehlerhaft markiert, obwohl sie technisch korrekt sind. Für PDF/UA-2-LaTeX-Output ist PAC also nicht das richtige Werkzeug.

Test mit echten Screenreadern

Validatoren prüfen Strukturen, aber nicht das tatsächliche Lese-Erlebnis. Realer Test mit mindestens einem Screenreader bleibt wichtig:

• NVDA(Windows, kostenfrei) – mit MathCAT -Addon für MathML.
• JAWS(Windows, kommerziell) – für viele blinde Nutzer:innen im Berufskontext der Referenz-Screenreader.
• VoiceOver(macOS/iOS, eingebaut) – für die Apple-Welt.

Praktische Empfehlung

Für Entwickler:innen und Autor:innen, die heute mit LaTeX arbeiten und barrierefreie PDFs brauchen, ist die Lage klarer als noch vor zwei Jahren – auch wenn die deutschsprachigen Anleitungen das oft noch nicht widerspiegeln:

1. Aktuelles TeX Live verwenden(mindestens 2025), oder die „Rolling TeXLive"-Option auf Overleaf.
2. LuaLaTeX als Engine – besonders bei Mathematik. Für reine Textdokumente reicht auch pdfLaTeX.
3. \DocumentMetadata mit tagging=on vor \documentclass .
4. Bei jedem Bild: entweder alt oder artifact .
5. Bei jeder Tabelle mit Header-Zeile: \tagpdfsetup{table/header-rows={1}} .
6. Vom accessibility -Paket Abstand nehmen – es ist offiziell verworfen.
7. Mit veraPDF validieren, nicht mit PAC – für PDF/UA-2.
8. Mit einem echten Screenreader testen, bevor das Dokument veröffentlicht wird.

Für komplexe Dokumente mit viel Mathematik, ungewöhnlichen Klassen oder historisch gewachsenen Satzpipelines lohnt es sich, eine technische Beratung hinzuzuziehen – die Tagging-Initiative bewegt sich schnell, und Tutorials von vor zwei Jahren sind oft schon veraltet.