Der PDF Accessibility Checker: Stärken und Schwächen
Von der Rechnung beim Online-Shoppen bis zum amtlichen Bescheid: PDF-Dokumente sind heute allgegenwärtig. Zahlreiche Unternehmen und Organisation nutzen das Dateiformat, um Informationen darzustellen und auszutauschen. Doch sind PDFs auch barrierefrei? Die kurze Antwort: Nicht automatisch!
Foto: © ANTONI SHKRABA production / pexels.com
Der Standard PDF/UA wurde 2012 veröffentlicht. Dieser definiert, wie ein PDF-Dokument die Anforderungen an Barrierefreiheit erfüllen kann. Leider werden auch heute noch zahlreiche Dokumente erstellt, welche diesen Standard nicht einhalten.
Damit euch das nicht passiert, solltet ihr eure PDFs auf Barrierefreiheit prüfen. Diese Prüfung beginnt am besten immer mit dem PDF Accessibility Checker, kurz PAC. Dieses kostenlose Standardtool ist vor kurzem in der Version 2024 erschienen: https://pac.pdf-accessibility.org/de
Ich nutze das Tool schon seit einigen Jahren und weiß seine Stärken zu schätzen. Allerdings ersetzt das automatisierte Tool keine manuelle Prüfung, etwa mit Screenreader und Tastatur. Daher gebe ich euch einen kurzen Überblick zu den Stärken und Schwächen des PDF Accessibility Checkers.
Stärken des Prüftools
Der PAC ist ein Tool zur automatisierten Prüfung von PDF-Dokumenten auf Barrierefreiheit, gemäß dem Standard PDF/UA (DIN/ISO 14289–1). Darüber hinaus werden relevante Punkte der Web Content Accessibility Guidelines (WCAG) sowie zusätzliche Qualitätsmerkmale geprüft.
Dabei kann der PAC u.a. folgende Barrieren automatisch erkennen:
- Für das PDF-Dokument ist kein Titel gesetzt.
- Die Sprache des Dokuments ist nicht definiert.
- Die Inhalte des PDF-Dokuments sind nicht getaggt.
- Ein Bild verfügt über keinen Alternativtext.
Weiters vermittelt das Tool im WCAG-Reiter auch transparent, welche Richtlinien es überprüft und welche nicht. Richtlinien wie z.B. „2.1 Per Tastatur zugänglich“ und „3.2 Vorhersehbar“ können nur manuell geprüft werden.
Schwächen des Prüftools
Der PDF Accessibility Checker kann den Code eines PDF-Dokuments nach gewissen Regeln prüfen. Aber es kann den Inhalt des Dokuments nicht inhaltlich verstehen und interpretieren. Das können automatisierte Prüftools generell nicht.
Um die Schwächen des Tools aufzuzeigen, habe ich ein Experiment durchgeführt: Wie viele Barrieren kann ich in ein PDF-Dokument einbauen, ohne dass der PAC Alarm schlägt? Mein Test-Dokument besteht aus mehreren Überschriften, Fließtext und einem Bild. Ihr könnt das Dokument herunterladen und selbst überprüfen.
Sehen wir uns nun die einzelnen Barrieren im Detail an.
Kein aussagekräftiger Titel
Mein Test-Dokument hat den Titel „Ein schöner Titel“. PAC gibt sich damit zufrieden. Wenn jedoch Screenreader-Nutzer:innen diesen Titel zu hören bekommen, werden sie nicht viel damit anfangen können.
Der Titel einer Webseite oder eines Dokuments ist die erste Information, auf die Nutzer:innen stoßen. Der Titel sollte den Inhalt beschreiben und den Nutzer:innen Orientierung bieten. Das hierbei relevante WCAG-Erfolgskriterium 2.4.2 besagt:
Webseiten haben einen Titel, der Thema oder Zweck beschreibt.
Daher muss bei einer manuellen Prüfung ein Mensch einschätzen, ob der gesetzte Titel des PDF-Dokuments aussagekräftig genug ist.
Falsch getaggte Überschriften
Wie PAC korrekt feststellt, ist der gesamte Inhalt meines Test-Dokuments getaggt. Das bedeutet: Für jedes Element im PDF ist definiert, welche Art von Inhalt es darstellt. Diese Information ist u.a. für Screenreader-Nutzer:innen essenziell, um den Inhalt korrekt erfassen und schnell im Dokument navigieren zu können.
Allerdings habe ich PAC reingelegt: Alle Überschriften, wie z.B. „Das ist eine wunderschöne Überschrift“, sind mit dem <P>-Tag als Fließtext ausgezeichnet. Während sehende Menschen die Überschriften visuell als solche erfassen können, ist diese Information semantisch nicht erfasst. Das WCAG-Erfolgskriterium 1.3.1 fordert:
Informationen, Struktur und Beziehungen, die über die Darstellung vermittelt werden, können durch Software bestimmt werden oder stehen in Textform zur Verfügung.
Automatisierte Tools wie der PAC können nicht einschätzen, was als Überschrift getaggt sein sollte und was nicht. Daher sollte sich ein Mensch das PDF-Dokument von einem Screenreader vorlesen lassen. Zusätzlich bietet auch PAC selbst die nützliche Screenreader-Vorschau-Funktion, welche die Tagging-Struktur visualisiert.
Keine logische Lesereihenfolge
Seht euch den Screenshot oben nochmal genau an. Na, fällt euch was auf? Genau, das Bild befindet sich visuell an einer anderen Stelle als in der Screenreader-Vorschau.
In einem getaggten PDF wird die Lesereihenfolge separat gespeichert. Besonders bei Dokumenten mit komplexen Layouts kann damit eine logische Lesereihenfolge definiert werden. Wenn etwa blinde Nutzer:innen mit Screenreader durch das Dokument navigieren, folgt der virtuelle Cursor des Screenreaders dieser Reihenfolge.
Daher definiert das WCAG-Erfolgskriterium 1.3.2 folgende Bedingung für Barrierefreiheit:
Wenn die Reihenfolge, in der Inhalte präsentiert werden, sich auf deren Bedeutung auswirkt, kann die korrekte Leseabfolge durch Software bestimmt werden.
Bei einer manuellen Prüfung sollte daher ein Mensch mit aktiviertem Screenreader sequenziell durch das Dokument navigieren und dabei überlegen, ob die Abfolge der Inhalte Sinn macht. Die visuelle Anordnung dient hier als Richtschnur. Es kann jedoch auch eine davon abweichende Lesereihenfolge sinnvoll sein.
Alternativtext beschreibt das Bild nicht
Der PDF Accessibility Checker prüft Bilder nur darauf, ob diese korrekt getaggt sind und ein Alternativtext definiert ist. Das WCAG-Erfolgskriterium 1.1.1 verlangt aber mehr:
Alle Nicht-Text-Inhalte, die dem Benutzer präsentiert werden, haben eine Textalternative, die einem äquivalenten Zweck dient, mit Ausnahme der unten aufgelisteten Situationen. [...]
Das Bild in meinem Test-Dokument zeigt das blaue, offene Meer vor der Küste Mallorcas. Der Alternativtext des Bildes lautet hingegen „Eine staubtrockene Wüste“. Ein automatisiertes Tool kann nicht erkennen, dass das Quatsch ist.
Fazit
Der PDF Accessibility Checker ist ein großartiges Tool, um ein PDF-Dokument auf grobe Mängel zu prüfen. Die manuelle Prüfung ersetzt es aber nicht. Eine umfassende Prüfung der Barrierefreiheit sollte sowohl automatisierte als auch manuelle Prüfschritte umfassen.
PS: Testet auch die korrigierte Fassung meines Test-Dokuments mit dem Screenreader, um die verbesserte Nutzererfahrung selbst zu erleben.
Erstellt am