Leitfaden „Tagged PDF Best Practice Guide: Syntax” veröffentlicht

Die Frage, was in Bezug auf die Barrierefreiheit von PDF-Dokumenten Best-Practice ist, würden viele vermutlich reflexartig mit „PDF/UA Standard“ beantworten. Im Juni 2019 wurde nun der Leitfaden „Tagged PDF Best Practice Guide: Syntax” veröffentlicht. Herausgeber ist die PDF/UA-Arbeitsgruppe (PDF/UA TWG) der PDF Association. Ist das also die neue Bibel für Barrierefreie PDF, also best practice?

Vorneweg, der Name „Tagged PDF Best Practice Guide“ ist etwas irreführend. Und wer sich nicht die Mühe macht, den Leitfaden zu lesen, sondern einfach nur anhand des Titels unterstellt, dass der Leitfaden die Antwort auf alle Fragen in Bezug auf barrierefreie PDF-Dokumente hat, verursacht vielleicht mehr Konfusion, als notwendig.

Der Best Practice Guide wendet sich an Entwickler

Fakt ist, der Best Practice Guide wendet sich an Entwickler. Direkt in der Einleitung des 70-seitigen Leitfadens steht frei übersetzt folgendes geschrieben: „das Dokument richtet sich an Entwickler, die Tagged PDF und den PDF/UA Standard implementieren müssen. Es kann zwar auch für Ersteller von PDF-Dokumenten hilfreich sein, wenn diese technisches Grundverständnis und Erfahrung mit Barrierefreiheit haben, aber in erster Linie ist es ein Entwickler-Leitfaden. Auch Tester können den Best-Practice Guide für Barrierefreie PDF heranziehen, um PDF/UA Konformität zu überprüfen.

Der Best Practice Guide ist keine Tagging-Anleitung

In dem Handbuch gibt es keine Schritt -für-Schritt Anleitung, wie man PDF/UA Konformität herstellt. Auch werden nicht alle Struktur-Elemente abgedeckt, bzw. behandelt. Und auch wenn das Dokument selbst für Hersteller von barrierefreien PDF-Dokumenten hilfreich sein kann, soll der Best-Practice Guide keine direkte Anleitung sein, wie Dokumente zu taggen sind.

WCAG gelten für Barrierefreiheit – nicht der Best Practice Guide

Darüber hinaus behandelt der Best-Practice Guide keine Aspekte der WCAG 2.1 oder anderer Richtlinien für Barrierefreiheit, wie beispielsweise die Section 508 oder die BITV. Fairerweise muss man natürlich auch sagen, dass die WCAG für Web Content gemacht sind und ein deutlich größeres Spektrum abdecken, als dies für barrierefreie PDF in der Regel notwendig ist. Deshalb gibt es beim W3C auch noch mal explizit zusätzliche PDF-Techniken für die WCAG 2.0 (nicht WCAG 2.1).

Best-Practice sollte in der Praxis funktionieren

Wer sich schon lange mit dem Thema barrierefreie PDF-Dokumente auseinandersetzt, findet in dem Leitfaden „Tagged PDF Best Practice Guide: Syntax” tatsächlich wenig Neues. Wobei das ja auch immer im Auge des Betrachters liegt, bzw. vom jeweiligen Kenntnisstand abhängt. Aber wenn wir mal die absolute Basis barrierefreier PDF-Dokumente außenvor lassen, wie beispielsweise eine hierarchische Überschriftenstruktur, maschinenlesbare Datentabellen und Table of Contents, Listenstrukturen, sinnvolle Alternativtexte, richtiger Umgang mit Schmuckgrafiken sowie eine korrekte Lesereihenfolge, dann finden sich im „Tagged PDF Best Practice Guide: Syntax“ trotzdem noch ein paar spannende Ansätze, die wir mal ausprobiert haben.

Reference-Note-Tag-Konstrukt

Ein interessanter Ansatz für die Verknüpfung von Fußnoten im Text mit Fußnoten am Seitenende soll laut Best-Practice Guide über einen Reference-Tag im Fließtext und mit einem Note-Tag bei der Fußnote selbst realisiert werden. Ergänzt soll das Ganze noch mit einem Lbl-Tag (gesprochen Label-Tag) für die Sternchen oder Zahlen der Fußnoten. Und idealerweise wünscht sich der Best-Practice-Guide für barrierefreie PDF-Dokumente dann noch eine Kreis-Verlinkung von den Fußnoten im Fließtext zu den Fußnoten am Seitenende (oder wo sie auch sind) und wieder zurück. Diese Kreis-Verlinkung mit einem entsprechenden Link-Tag ist allerdings von keiner Richtlinie für Barrierefreiheit abgedeckt, sondern eher eine Forderung im Bereich Usability. Man könnte auch sagen Nice to have. Je nachdem wie viele Fußnoten ein Dokument hat, entsteht daraus zudem ein ziemlich hoher Aufwand, den am Ende ja der Kunde bezahlen muss. Sprich: Kann man machen, muss man aber nicht.

Leider hat das Reference-Note-Tag-Konstrukt einen Haken. Denn wenn man die Kreis-Verlinkung nicht vorsehen möchte, weil es einfach zu aufwendig ist, dann führt der Reference-Tag zu einem unbefriedigenden Ergebnis mit Screenreadern. Denn zumindest im NVDA wird der Reference-Tag als Link angekündigt, auch wenn kein klickbarer Link enthalten ist. Das ist sehr irreführend und unpraktisch. Für uns ein Grund den Reference-Tag nicht zu verwenden. Traditionell nutzen wir für ein solches Konstrukt lieber einen Span-Tag mit dem Alternativtext „Siehe Fußnote 1“. Der Reference-Tag scheint nur in Kombination mit einer Kreis-Verlinkung richtig Sinn zu ergeben.

Lbl-Tag nicht nur für Listenpunkte

Jeder, der mit barrierefreien PDF-Dokumenten schon mal zu tun hatte, wird einige Standard-Tags bereits kennen. Eines davon ist der Lbl-Tag. Dieser wird zumeist für Listenpunkte verwendet. Laut Spezifikationen lassen sich damit aber auch andere Elemente labeln, wie beispielsweise „Abb: 1“ oder „Tabelle 1“ oder Ähnliches.

Der Best-Practice Guide schlägt für das Reference-Note-Tag-Konstrukt ein Lbl-Tag für die Nummerierung vor. An sich keine schlechte Idee. Allerdings nur dann, wenn Fußnoten auf der gleichen Seite auftauchen und zwischen der Fußnote 1 im Fließtext und der referenzierten Fußnote 1 kein anderes Lbl-Element mit einer 1 auftaucht. Das bedeutet also zwischen Fußnote im Fließtext mit Lbl-Tag und referenzierter Fußnote mit Lbl-Tag darf kein weiterer Lbl-Tag mit gleichem Inhalt auftauchen. Das wäre aber beispielsweise mit einer nummerierten Liste schon gegeben. Und wenn Fußnoten kapitelweise oder sogar am Dokumentenende zusammengefasst werden, dann liegt die Wahrscheinlichkeit, dass zwischen den sich referenzierenden Tags eine nummerierte Liste liegt, bei umfangreicheren Dokumenten vermutlich bei 100 %. Und dann funktioniert das Konstrukt nicht. Deshalb nutzen wir auch diesen Vorschlag nicht.

Index-Tag ist interessant

Ein anderer Tag ist uns im „Tagged PDF Best Practice Guide“ aufgefallen, der durchaus mehr Semantik für ein typisches Dokumenten-Element mit sich bringen würde. Wir sprechen vom Index-Tag. Dieser bietet eine gute Möglichkeit, beispielsweise einem Abbildungsverzeichnis oder einem Literaturverzeichnis noch etwas mehr Semantik mitzugeben. Hier kann der Index-Tag sicherlich eine Lücke füllen, wenn assistive Technologien diesen Tag unterstützen, indem sie ihn zum einen ankündigen und zum anderen beispielsweise direkt anspringbar machen.

Private-Tag und NonStruct

Auch zwei andere Tags im Best-Practice Guide haben Potenzial. Zum einen der Private-Tag zum anderen der NonStruct-Tag. Der Private-Tag soll dazu führen, dass alles was in ihm selbst und in untergeordneten Tag-Elementen enthalten ist, komplett ignoriert wird. Also auch von Screenreadern. Das wäre praktisch, weil es bisher de facto keine Möglichkeit gibt, Inhalte vor Screenreadern zu verstecken, ohne dass diese als Artifact getaggt werden und so beispielsweise auch in anderen, alternativen Darstellungsformen unsichtbar werden. Einen Tag, der ein Element sichtbar lässt, aber nicht mehr vorliest, gibt es noch nicht. Hier verstehen wir den Best-Practice Guide so, dass der Private-Tag genau dies tun soll. In der Praxis konnten wir das allerdings mit NVDA leider nicht bestätigen. Gleiches gilt für den NonStruct-Tag. Laut Best-Practice Guide handelt es sich hierbei eher um einen individuellen Custom-Tag, für Inhalte, die sich über keinen anderen Standard Struktur-Tag semantisch korrekt beschreiben lassen. Inhalte in einem NonStruct-Tag sollen von Screenreadern vorgelesen werden, haben aber keine eigene Bedeutung. Da der Best-Practice Guide keine Beispiele dazu mitliefert, ist hier nicht ganz schlüssig, was das am Ende genau sein könnte. Ich persönlich fände den NonStruct-Tag tatsächlich interessant, wenn die Inhalte eben nicht an Screenreader übergeben würden, damit man mit diesem Tag bedeutungslose Inhalte vor Screenreader verstecken kann. NonStruct klingt für mich diesbezüglich auch plausibler, als der Private-Tag.

Fazit: Best-Practice und/oder Barrierefreiheit

Der Leitfaden „Tagged PDF Best Practice Guide: Syntax” ist vor allem für Einsteiger interessant. Er bietet für Experten eigentlich nicht viel Neues. Und einige Best-Practice Ansätze scheinen nicht wirklich Praxis erprobt zu sein, wie die Beispiele mit dem Reference-Tag oder dem Lbl-Tag zeigen. Bestehende Lücken kann der Best-Practice Guide leider nicht schließen. So gibt es auch in dem Best-Practice Guide keine Ansätze, um beispielsweise Hinweis-Boxen im Fließtext oder Zusatz-Informationen in einer Seitenspalte so zu kennzeichnen, dass sie innerhalb der Dokumentenstruktur eines barrierefreien PDF-Dokuments als spezieller Content auch für Screenreader-Nutzer erkennbar wären, vergleichbar mit HTML5-Eelmenten wie Footer, Header oder Aside bzw. den entsprechenden, passenden Landmark-Roles.