Die Barrierefreiheit von PDF-Dokumenten und die Missverständnisse zu PAC

Viele Anbieter stellen ihre digitalen Inhalte als PDF-Dokumente zur Verfügung. Entsprechend wichtig ist ihre Barrierefreiheit, damit möglichst viele Nutzer:innen darauf zugreifen können. Das Format PDF erweist sich aber oft als ‘sperriger’ als andere Formate, wegen der Schwierigkeit, sie barrierefrei umzusetzen, und wegen der Missverständnisse, die gerade zur PDF-Barrierefreiheit vielfach noch bestehen. Was barrierefreie PDFs erfüllen müssen, und wie man dies testet, soll im Folgenden erläutert werden.

Was ist der PDF Accessibility Checker (PAC)?

Der PDF Accessibility Checker (PAC) ist ein Hilfsmittel, das zur automatisierten Barrierefreiheits-Überprüfung von PDF-Dokumenten dient. Der PAC ist zwar eine gute Möglichkeit zum Testen, ersetzt aber nicht das manuelle Überprüfen von PDFs. Die Anforderungen und ein sinnvoller Einsatz des PAC sollen im Folgenden beschrieben werden. Die aktuelle Version des PAC findet sich auf https://pdfua.foundation/de.

Was müssen barrierefreie PDFs leisten?

Ungeachtet der Hoffnung auf andere, möglicherweise besser barrierefreie Formate (z.B. EPUB) werden sehr viele Inhalte online weiterhin primär in Form von PDFs angeboten. Für diese gelten wie für alle anderen digitalen Formate, in der Schweiz wie auch in vielen anderen Ländern, die Anforderungen der Web Content Accessibility Guidelines (WCAG). In der Schweiz fordert der eGov-Standard eCH-0059 die Einhaltung von WCAG 2.1 AA für PDF-Dokumente der öffentlichen Hand.

Die wichtigsten Anforderungen, die barrierefreie PDFs erfüllen müssen, sind die Folgenden (vgl. auch die Anforderungen an die Barrierefreiheit von PDF-Dokumenten des Bundes; Link, abgerufen am 16.11.2022):

  • das PDF hat einen sinnvollen Dokumententitel;
  • das Dokument weist eine tag-Struktur mit korrekter Semantik auf: Absätze sind korrekt als separate Paragraphen formatiert, visuelle Überschriften auch semantisch als solche, mit korrekter Hierarchie bzw. logischer Struktur; Aufzählungen sind als Listen formatiert; Tabellen weisen Spalten- und/oder Zeilenüberschriften auf, etc.
  • Sprachdeklaration des gesamten Dokuments, und allenfalls anderssprachiger Teile sind korrekt definiert;
  • die Lesereihenfolge ist logisch korrekt, so dass etwa Screenreader auch bei mehrspaltigen Texten kein unverständliches Durcheinander ausgeben;
  • informative Grafiken weisen korrekte Textalternativen auf;
  • das Dokument hat ausreichende Kontraste (Schrift-Hintergrund erreicht mind. 4.5:1 bei normalem, 3:1 bei grossem Text);
  • Links sind tastaturbedienbar, also per Tabben zu erreichen.

Am besten berücksichtigt man alle diese Anforderungen bereits im Primärformat (z.B. in Word oder InDesign), was oft auch recht einfach zu bewerkstelligen ist (z.B. durch die korrekte Verwendung von Formatvorlagen in einer Textverarbeitung, mittels Hinterlegen von Alternativtexten, durch Festlegen der Metainformationen im Dokument, etc.).

Im nächsten Schritt, der Konvertierung zum PDF, ist wichtig, dass die getroffenen Vorkehrungen ins PDF übernommen werden. Etwa ein ‘print to file’ ist dabei zu vermeiden, weil dadurch die semantische Struktur verloren gehen kann. Zudem ist in der Textverarbeitungs-Software sicherzustellen, dass die tag-Struktur ins PDF übergeben wird.

Eine Nachbearbeitung im resultierenden PDF-Dokument ist eine Notlösung und wird am besten vermieden. So besteht das Problem, dass bei jeder Anpassung des Dokuments im Primärformat die Nachbearbeitung im PDF erneut erforderlich ist. Falls jedoch nur das PDF vorliegt, es um Aspekte geht, welche sich im Primärformat nicht definieren lassen, oder falls die erforderlichen Grundkenntnisse bei den Autor:innen fehlen, dann gibt es dazu häufig keine Alternative. Nachhaltig auf Barrierefreiheit ausgerichtete PDF-Produktionsprozesse sehen jedoch anders aus.

Im Idealfall wird damit erreicht, dass PDF-Dokumente barrierefrei sind, und ihre Inhalte für möglichst viele Nutzer:innen, inklusive jener mit unterschiedlichen Formen von Behinderungen, zugänglich sind.

Der sinnvolle Einsatz des PAC bei der Prüfung von PDFs

Website-Betreiber:innen, die sich einer umfangreichen Altlast von PDFs gegenüber sehen, oder Auftraggeber, denen neue PDFs von Agenturen angeliefert werden, wissen meist nicht, ob diese Dokumente barrierefrei sind. Hier kommt der PAC ins Spiel, und der folgende, grundlegende Prüf-Ablauf wird durch dieses Werkzeug gut unterstützt:

  1. Testen, ob das PDF korrekte Metadaten aufweist (Dokumententitel, Sprachdeklaration) – wird unmittelbar bei der Prüfzusammenfassung angezeigt;
  2. Feststellen, ob überhaupt eine tag-Struktur vorhanden ist – wird ebenfalls unmittelbar bei der Prüfzusammenfassung angezeigt: falls keine solche vorliegt, dann kann man die Prüfung beenden, dann ist das Dokument eine unstrukturierte Bleiwüste, und mittels Screenreader nicht effizient zu nutzen; wenn die Struktur einfach ist (u.a. einspaltig, ohne Tabellen, etc.), was oft bei Dokumenten aus Word, o.ä. gegeben ist, dann sind die Inhalte immerhin sequenziell lesbar und verständlich;
  3. Falls eine Struktur vorhanden ist, dann muss man im Detail prüfen, ob diese tag-Struktur korrekt ist, per Funktion ‘Screenreader-Vorschau’: im direkten Vergleich zum Ursprungsdokument kann man dort mit einer Sichtprüfung vergleichen, ob visuelle Überschriften korrekt als Überschriften (auf korrekter, logischer Ebene), Listen als Listen, Paragraphen als Paragraphen, Tabellen mit Spalten- und Zeilenüberschriften (th), etc. umgesetzt wurden; zudem ist wichtig, dass sich auch alle Inhalte in dieser Struktur wiederfinden, und dass die Lesereihenfolge korrekt ist, und auch Textalternativen für Grafiken sind erkennbar;
  4. Kontraste: Inzwischen prüft PAC unter dem Tab ‘WCAG’ recht zuverlässig auch Kontraste;
  5. Tastaturbedienbarkeit: für diesen Prüfpunkt kann der PAC Hinweise geben, auch wenn dieser Test erfahrungsgemäss noch eher unzuverlässig ausfällt. Am besten prüft man in einem vielverwendeten PDF-Reader direkt mittels Tastatur.

Besonders der 3.Schritt, die ‘manuelle Sichtprüfung’ der logischen Struktur des Dokuments mittels Screenreader-Vorschau ist zentral, sie ist oft der wichtigste Prüfschritt. So weisen viele Dokumente zwar eine Struktur auf, sie kann aber komplett falsch sein (z.B. gibt es nur Paragraphen, und gar keine Überschriften o.ä.). Aufgrund der mangelnden automatisierten Prüfbarkeit kann PAC dies aber nicht ausreichend klar bemängeln. Das automatisiert generierte Prüfergebnis im PAC (die ‘roten Kreuze’) – zumindest im Tab ‘PDF/UA’ – lassen Laien am besten erstmal ganz beiseite, die gestellten Anforderungen an PDF-Dokumente sind ja zumeist die WCAG, und nicht PDF/UA. Und der Aufwand für deren Lösung steht häufig auch in keinem Verhältnis zum realen Gewinn an praktischer Barrierefreiheit eines PDF-Dokuments.

Missverständnisse bei der Verwendung von Prüfwerkzeugen im Allgemeinen, und bei PAC im Besonderen

Die automatisierte Prüfbarkeit der Barrierefreiheit digitaler Inhalte ist derzeit begrenzt. Selbst Anbieter solcher Werkzeuge sprechen meist nicht von mehr als einem Viertel der WCAG-Anforderungen, welche sich als zuverlässig prüfbar erweisen. Im Angesicht von sehr vielen potentiellen WCAG-Verletzungen auf einem komplexen System kann dies durchaus sehr hilfreich sein. Und Warnungen zu potentiell identifizierten Verstössen können auf die Erfordernis einer manuellen Nachprüfung durch Expert:innen hinweisen. Und diese Einschätzung der Grenzen der automatisierten Prüfbarkeit von Barrierefreiheit scheint derzeit recht breit akzeptiert.

Gerade bei PDF-Dokumenten bestehen diesbezüglich jedoch deutliche Missverständnisse. Da wird vielfach völlig falsch ‘PAC-Konformität’, also der automatisierte Check mittels des PDF Accessibility Checkers PAC, als Zielgrösse für PDFs definiert, notabene: nicht die reale Barrierefreiheit eines Dokuments! Damit wird das automatisierte Testergebnis dieses einen Prüf-Werkzeugs kurzerhand als Nachweis der Barrierefreiheit von Dokumenten akzeptiert, was komplett falsch ist.

Weil, die automatisierte Prüfung ist fehleranfällig, und jedes Prüfwerkzeug kann ausgetrickst werden. So begegnen wir immer wieder PDF-Dokumenten, die im automatisierten PAC-Check 0 Fehler aufweisen, aber komplett unzugänglich sind. Vielfach ist da die logische Struktur der Inhalte (Paragraphen, Überschriften, Listen, etc.) falsch, wodurch ein Dokument mittels Screenreader nicht mehr effizient, oder gar nicht mehr verständlich ist. Aber der PAC kann dies aufgrund des fehlenden Textverständnisses nicht testen. Wenn nun aber Auftraggeber nur noch diese Zielgrösse berücksichtigen, und Agenturen nur noch auf ‘PAC-Konformität’, und nicht mehr auf Barrierefreiheit hinarbeiten, dann entstehen falsche Anreize. Es führt nicht unbedingt zu guter praktischer Barrierefreiheit und auch nicht zu WCAG-Compliance.

Fazit

PDF-Barrierefreiheit bleibt relevant, und die grundlegenden Anforderungen an barrierefreie PDFs sind meist mit vertretbarem Aufwand realisierbar. Die Zielgrösse muss dabei aber praktische Barrierefreiheit und WCAG-Compliance sein, und nicht die Konformität mit einem einzelnen, nur begrenzt zuverlässigen, automatisierten Prüfwerkzeug. Mit diesem Verständnis kann der PDF Accessibility Checker PAC sinnvoll eingesetzt werden, v.a. zur Unterstützung der Sichtprüfung der Dokumenten-Struktur.

3 Kommentare zu “Die Barrierefreiheit von PDF-Dokumenten und die Missverständnisse zu PAC

  1. Bisher war immer die Devise, dass man für die Generierung des PDF den Adobe Acrobat benötigt. Geht das auch mit anderen Tools, z.B: PDFExchange?

    1. Hallo Beat Wyler
      Vielen Dank für den Kommentar und die Rückfrage.
      Man kann auch mit anderen Tools PDFs mit Tags erstellen. Für die Nachbearbeitung und Korrektur der Tags braucht es aber weiterhin Adobe Acrobat. Dies ist zum Beispiel nötig bei Tabellen oder wenn das Dritttool falsche Tags setzt. Wie gut PDFExchange ein Dokument taggt, können wir leider nicht beurteilen. Gerne können Sie uns aber ein PDF per Mail senden, damit wir einen Blick darauf werfen können.
      Beste Grüsse
      Thinh-Lay Wonesky

  2. Tatsächlich habe ich erlebt, dass ein Schlaumeier in unserer Firma versucht hat unser Accessibility Quality-Gate zu täuschen, mit einem fetten PDF (mehrseitige Broschüre aus Indesign).
    Wir checken im workflow mit PAC und stichprobenmässig manuell. In dem mehrseitigen Dokument wurde aller Inhalt als Artefakte getaggt, mit dem Resultat, dass PAC nur noch 100% accessiblen Code sieht!
    Das PAC-Resultat war eindrücklich aber etwas zu gut und es wurde nachgeschaut 🙂
    Ich war erstaunt dass dies so einfach möglich ist, doch es zeigt uns nur die Limiten des automatischen Testens.

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahren Sie mehr darüber, wie Ihre Kommentardaten verarbeitet werden .