PDF auf Barrierefreiheit prüfen

Wer ein PDF auf Barrierefreiheit prüfen möchte, greift häufig zunächst zu einem automatisierten Prüfprogramm wie dem PAC. Zeigt der PAC einen grünen Haken, liegt die Annahme nahe, dass das PDF barrierefrei ist.

Was viele dabei übersehen: Mit der automatisierten Prüfung kann nur ein Teil der Anforderungen abgedeckt werden. Viele weitere Anforderungen, wie beispielsweise die korrekte Lesereihenfolge, erfordern eine menschliche Bewertung. Werden diese Anforderungen in der Praxis nicht vollständig geprüft, können PDFs fälschlicherweise als barrierefrei eingestuft werden, obwohl sie nicht gesetzeskonform sind.

Bevor wir uns ansehen, wie die automatisierte und die manuelle Prüfung konkret durchgeführt werden, müssen wir zunächst klären, welche Anforderungen ein barrierefreies PDF überhaupt erfüllen muss.

Grundlagen zur Prüfung barrierefreier PDFs

Eine zuverlässige Beurteilung der Barrierefreiheit setzt voraus, die zugrunde liegenden Anforderungen und Prüfprinzipien zu verstehen. Die folgenden Abschnitte erläutern diese Grundlagen und schaffen damit die Basis für die anschließende praktische Prüfung.

Wer ein PDF auf Barrierefreiheit prüfen möchte, muss zunächst wissen, welche Anforderungen ein barrierefreies PDF überhaupt erfüllen muss. Nur so lässt sich vollständig prüfen und belastbar beurteilen, ob das Dokument tatsächlich barrierefrei ist.

In der Europäischen Union ist die EN 301 549 die maßgebliche Norm für die digitale Barrierefreiheit. Speziell für die Barrierefreiheit von digitalen Dokumenten ist dabei Klausel 10 der Norm relevant, die auf Teile der Web Content Accessibility Guidelines (WCAG) verweist.

Welche WCAG-Erfolgskriterien sind für barrierefreie PDFs relevant

Die WCAG beinhalten prüfbare Erfolgskriterien, die den drei Konformitätsstufen A, AA und AAA zugeordnet sind. Je höher die erreichte Konformitätsstufe, desto mehr Anforderungen an die Barrierefreiheit werden erfüllt und desto besser sind die Inhalte grundsätzlich zugänglich. Die Stufe AAA wird weltweit jedoch typischerweise nur empfohlen und nicht vorgeschrieben. Entsprechend verweist auch die EN 301 549 nur auf Erfolgskriterien der Stufen A und AA.

Doch auch innerhalb der Stufen A und AA muss weiter eingegrenzt werden. Denn die WCAG wurden technologieübergreifend für digitale Inhalte entwickelt und sind stark auf Webinhalte ausgerichtet. Einige Anforderungen lassen sich daher nicht auf digitale Dokumente anwenden und sind somit auch nicht in Klausel 10 der EN 301 549 referenziert.
Darüber hinaus sind selbst von den in Klausel 10 referenzierten Erfolgskriterien nicht alle für PDF-Dokumente relevant, da einzelne Anforderungen zwar auf andere digitale Dokumentformate, nicht jedoch auf PDFs anwendbar sind. Für die Prüfung der Barrierefreiheit von PDF-Dokumenten reduziert sich die Anzahl der relevanten WCAG-Erfolgskriterien damit noch weiter gegenüber den in Klausel 10 der EN 301 549 referenzierten Kriterien.

Nun könnte man die für PDF-Dokumente relevanten WCAG-Erfolgskriterien herausfiltern und ein PDF direkt anhand dieser Anforderungen prüfen. In der Praxis funktioniert das jedoch nicht. Wie bereits erläutert, wurden die WCAG technologieübergreifend formuliert und legen daher nicht im Detail fest, wie ihre Anforderungen technisch in einem PDF-Dokument umgesetzt werden müssen.

PDF/UA: Technische Anforderungen an barrierefreie PDFs

Genau hier setzt die internationale Norm ISO 14289 an, auch bekannt als PDF/UA (Universal Accessibility). Sie wurde speziell für die Barrierefreiheit von PDF-Dokumenten entwickelt und beinhaltet damit technisch konkrete Anforderungen.

Von der Normenreihe ISO 14289 gibt es mittlerweile zwei Teile:

PDF/UA-1 (ISO 14289-1) basierend auf PDF 1.7
PDF/UA-2 (ISO 14289-2) basierend auf PDF 2.0

In der Praxis werden PDF-Dokumente derzeit noch überwiegend auf Grundlage von PDF 1.7 erstellt, weshalb PDF/UA-1 aktuell maßgeblich ist. Aus diesem Grund beziehen sich die folgenden Ausführungen zur Prüfung barrierefreier PDF-Dokumente zunächst auf diesen Standard.

Durch die speziell auf PDF-Dokumente ausgerichteten Anforderungen bietet die PDF/UA eine wesentlich konkretere Grundlage für die technische Prüfung der Barrierefreiheit. Die Anforderungen sind in der Norm jedoch überwiegend als Fließtext und nicht als unmittelbar anwendbare Prüfschritte formuliert. Um eine einheitliche und systematische Prüfung auf Konformität mit PDF/UA zu ermöglichen, wurde daher das Matterhorn-Protokoll entwickelt.

Matterhorn-Protokoll: Prüfgrundlage für barrierefreie PDFs

Das Matterhorn-Protokoll überführt die Anforderungen aus der PDF/UA in konkrete Prüfpunkte und strukturiert diese in verschiedene Arten von Prüfkriterien.

Nun könnte man annehmen, dass man ein PDF lediglich anhand der Kriterien des Matterhorn-Protokolls prüfen muss und es barrierefrei ist, wenn es alle Kriterien erfüllt. Das reicht jedoch nicht aus. Die PDF/UA und die für PDF-Dokumente relevanten WCAG-Erfolgskriterien überschneiden sich zwar stark, sind jedoch nicht vollständig deckungsgleich. Einige relevante WCAG-Erfolgskriterien werden durch PDF/UA nicht abgedeckt und müssen daher zusätzlich geprüft werden.

Welche Anforderungen müssen für die vollständige Prüfung berücksichtigt werden?

Für eine vollständige Prüfung der Barrierefreiheit eines PDF-Dokuments müssen daher die Kriterien des Matterhorn-Protokolls um die wenigen zusätzlichen WCAG-Erfolgskriterien ergänzt werden, die vom Matterhorn-Protokoll nicht abgedeckt werden. Zusammen bilden diese Kriterien die Grundlage für den weiteren Prüfprozess.

Die Anforderungen an barrierefreie PDF-Dokumente lassen sich grundsätzlich in zwei Arten von Kriterien unterteilen:

Deterministische Kriterien können anhand definierter technischer Bedingungen eindeutig geprüft werden. Für ihre Bewertung ist keine inhaltliche oder fachliche Beurteilung erforderlich. Sie lassen sich deshalb maschinell prüfen und die Prüfung kann vollständig automatisiert durch Software erfolgen.
So kann eine Software beispielsweise eindeutig feststellen, ob für ein PDF-Dokument eine Dokumentsprache definiert wurde.
Nicht-deterministische Kriterien erfordern dagegen eine inhaltliche oder fachliche Beurteilung. Sie können daher nicht allein anhand technischer Bedingungen geprüft werden und lassen sich mit klassischen Prüfprogrammen nicht vollständig maschinell prüfen. Aus diesem Grund werden sie derzeit überwiegend manuell durch Menschen bewertet.
Eine Software kann beispielsweise nicht zuverlässig beurteilen, ob die festgelegte Dokumentsprache tatsächlich mit der Sprache des Dokumentinhalts übereinstimmt.

In Zukunft werden KI-Systeme voraussichtlich einen zunehmenden Teil der nicht-deterministischen Prüfungen übernehmen können. Zum aktuellen Zeitpunkt sind ihre Ergebnisse jedoch noch zu unzuverlässig, um eine vollständige menschliche Prüfung zu ersetzen.

Welche Anforderungen können maschinell und daher auch automatisiert geprüft werden?

Für die maschinelle Prüfung sind zunächst die deterministischen Kriterien des Matterhorn-Protokolls 1.1 relevant. Diese sind im Protokoll mit dem Buchstaben „M“ gekennzeichnet. Hinzu kommen die zusätzlich relevanten WCAG-Erfolgskriterien, die ebenfalls maschinell geprüft werden können. Dazu zählen beispielsweise die Anforderungen an den Kontrast von Inhalten aus den Erfolgskriterien 1.4.3 und 1.4.6.

Bei der praktischen Prüfung müssen diese Kriterien nicht einzeln manuell durchgearbeitet werden, da sie von geeigneter Prüfsoftware automatisiert überprüft werden können. Entscheidend ist jedoch die Auswahl eines geeigneten Prüfprogramms. Nur wenige Prüfwerkzeuge führen eine umfassende Prüfung der deterministischen Kriterien durch und liefern dabei zuverlässige Ergebnisse.

Welche Anforderungen müssen manuell geprüft werden?

Für die manuelle Prüfung sind zunächst die nicht-deterministischen Kriterien des Matterhorn-Protokolls 1.1 relevant. Diese sind im Protokoll mit dem Buchstaben „H“ gekennzeichnet. Hinzu kommen die zusätzlich relevanten WCAG-Erfolgskriterien, die ebenfalls eine individuelle Bewertung erfordern.

Im Gegensatz zu den maschinell prüfbaren Kriterien können diese Anforderungen nicht einfach durch ein Prüfprogramm abgearbeitet werden. Sie müssen einzeln geprüft und fachlich bewertet werden. Dazu gehören beispielsweise die logische Lesereihenfolge, die korrekte semantische Struktur des Dokuments, die Angemessenheit von Alternativtexten, usw.

Eine vollständige manuelle Prüfung erfordert daher eine systematische Prüfliste, die alle relevanten H-Kriterien des Matterhorn-Protokolls sowie die zusätzlichen manuell zu prüfenden WCAG-Erfolgskriterien zusammenführt. Wie diese Anforderungen in der Praxis systematisch geprüft und bewertet werden können, wird im weiteren Verlauf dieses Artikels erläutert.

Nicht jede Prüfsoftware eignet sich gleichermaßen, um die Barrierefreiheit von PDF-Dokumenten zu prüfen. Eine geeignete Software sollte zum einen die maschinell prüfbaren Kriterien möglichst vollständig und zuverlässig überprüfen. Zum anderen sollte sie Funktionen bereitstellen, mit denen sich auch die manuell zu bewertenden Kriterien effizient und nutzerfreundlich prüfen lassen.

Im Folgenden werden PAC, veraPDF und Adobe Acrobat Pro näher betrachtet. Die drei Programme verfolgen unterschiedliche Ansätze und eignen sich daher jeweils für unterschiedliche Anwendungsfälle.

PAC

PAC wurde speziell für die effiziente und ganzheitliche Einzelprüfung von PDF-Dokumenten auf Barrierefreiheit entwickelt. Das Programm vereint eine umfassende maschinelle Prüfung mit zahlreichen Funktionen für die manuelle Bewertung. Dadurch unterstützt es den gesamten Prüfprozess in einer einzigen Anwendung.

Vorteile

Kostenfrei
PDF/UA- und WCAG-Prüfung in einem Durchlauf
Nahezu vollständige Prüfung der maschinell prüfbaren Kriterien
Einfache Fehlerlokalisierung durch visuelle Vorschau des betroffenen Elements
Umfangreiche Funktionen für die effiziente manuelle Bewertung
Einfache Installation
Sehr intuitive und nutzerfreundliche Bedienung
Maßgebliches Prüfwerkzeug bei Audits und Abnahmen im deutschsprachigen Raum

Nachteile

Erst ab PAC 2027 auch für macOS verfügbar
Keine Batchprüfung mehrerer Dokumente möglich
Serverseitige Automatisierung kostenpflichtig
Reines Prüfwerkzeug (keine Fehlerkorrektur)

veraPDF

veraPDF eignet sich insbesondere für die automatisierte Prüfung großer Dokumentenmengen und die Integration in bestehende Server- und Prüfprozesse. Darüber hinaus kann das Programm auch für die Prüfung einzelner PDF-Dokumente eingesetzt werden. Der Schwerpunkt liegt dabei jedoch auf der reinen maschinellen Prüfung. Für die manuelle Bewertung nicht-deterministischer Kriterien bietet veraPDF dagegen aktuell keine Unterstützung.

Vorteile

Kostenfrei
Plattformübergreifend (Windows, macOS und Linux)
PDF/UA- und WCAG-Prüfung möglich
Nahezu vollständige Prüfung der maschinell prüfbaren Kriterien
Batchprüfung mehrerer Dokumente möglich
Kommerzielle Servernutzung ohne zusätzliche Lizenzkosten
Open-Source-Entwicklung mit hoher Transparenz
Schnelle Fehlerbehebung durch aktive Entwicklergemeinschaft

Nachteile

Gemeinsame PDF/UA- und WCAG-Prüfung nur mit eigenem Prüfprofil
Keine visuelle Fehlerlokalisierung des betroffenen Elements
Keine Funktionen für die manuelle Bewertung
Vergleichsweise aufwendige Installation und Einrichtung (Java erforderlich)
Weniger intuitive Bedienung
Reines Prüfwerkzeug (keine Fehlerkorrektur)

Adobe Acrobat

Adobe Acrobat eignet sich insbesondere für Anwender, die das Programm bereits im Einsatz haben und keine zusätzlichen Prüfwerkzeuge verwenden können oder möchten. Zwar erreicht Acrobat nicht den Prüfumfang spezialisierter Prüfprogramme, ermöglicht jedoch bereits eine aussagekräftige maschinelle Prüfung. Ein wesentlicher Vorteil besteht darin, dass erkannte Barrierefreiheitsprobleme direkt im selben Programm korrigiert werden können. Für eine effizientere und damit wirtschaftlichere Nachbearbeitung können jedoch spezialisierte Lösungen sinnvoller sein.

Vorteile

Plattformübergreifend (Windows und macOS)
Umfangreiche Funktionen für die manuelle Bewertung (weniger effizient als PAC)
Prüfung und Fehlerkorrektur in einer Anwendung
Einfach Installation

Nachteile

Kostenpflichtig
Keine WCAG-Prüfung
Für einen möglichst hohen Prüfumfang der maschinell prüfbaren Kriterien müssen zwei Prüffunktionen kombiniert werden („Barrierefreiheit prüfen“ und „Preflight“)
Visuelle Fehlerlokalisierung nur für wenige Prüfkriterien
Keine sinnvolle Batchprüfung mehrerer Dokumente möglich
Keine sinnvolle serverseitige Automatisierung möglich
Vergleichsweise komplexe Bedienung bei der manuellen Bewertung

Empfehlung für die praktische Prüfung

Zusammenfassend eignet sich PAC am besten für die vollständige Einzelprüfung von PDF-Dokumenten auf Barrierefreiheit. Das Programm vereint eine nahezu vollständige maschinelle Prüfung mit umfangreichen Funktionen für die manuelle Bewertung und unterstützt damit den gesamten Prüfprozess in einer einzigen Anwendung. Aus diesem Grund wird für die weiteren Ausführungen und Praxisbeispiele in diesem Artikel PAC verwendet.

Praktische Prüfung eines PDFs auf Barrierefreiheit

Die praktische Prüfung eines PDFs auf Barrierefreiheit besteht aus zwei Schritten:

einer maschinellen Prüfung und
einer anschließenden manuellen Bewertung.

Nur wenn beide Schritte durchgeführt werden, lässt sich beurteilen, ob ein PDF-Dokument die gesetzlichen Anforderungen an die Barrierefreiheit erfüllt.

Für die folgenden Praxisschritte wird PAC verwendet. Warum sich PAC besonders gut für die vollständige Einzelprüfung von PDF-Dokumenten eignet und wie es sich von veraPDF und Adobe Acrobat unterscheidet, wurde im vorherigen Abschnitt erläutert.

Schritt 1: PDF maschinell auf Barrierefreiheit prüfen

PAC öffnen > Schaltfläche “Dokument öffnen” anklicken

Dokument auswählen > “Öffnen”

“Detail-Bericht” anklicken

Hinweis: Bevor Sie auf Detail-Bericht klicken, sehen Sie in der Ergebnisübersicht eine Zusammenfassung der Dokument-Evaluierung. Im unteren rechten Bereich der Software können Sie sich die “Screenreader-Vorschau” und die “Logische Struktur” des Dokuments anzeigen lassen. Das sind generell nützliche Funktionen zur Überprüfung der Dokumentstruktur, jedoch geben Ihnen diese Funktionen keine Hinweise darüber, welche Fehler Sie noch ausbessern müssen. Solange der PAC also noch Fehlermeldungen anzeigt, ist der Detail-Bericht die wichtigste Funktion.

Die Fehlermeldungen im Strukturbaum des Detail-Berichts erweitern/aufklappen um mehr Details zu erfahren und danach ggf. in Adobe Acrobat beheben

Für den letzten Schritt finden Sie auf dieser Webseite eine Liste mit Lösungen zu den gängigen Fehlermeldungen. Der Aufwand, den Sie im letzten Schritt haben, hängt maßgeblich von der Struktur Ihres Ursprungsdokumentes ab. Stellen Sie also sicher, dass Sie bereits Ihr Ursprungsdokument (z. B. Microsoft Word) sauber aufbauen.

Schritt 2: PDF manuell auf Barrierefreiheit prüfen

Da der PAC nur die maschinell prüfbaren Kriterien des Matterhorn-Protokolls evaluiert, müssen Sie jetzt noch alle (H)-Kriterien aus dem Matterhorn manuell überprüfen (da für deren Prüfung ein menschlicher Sachverstand notwendig ist).

Wenn dort alles passt, ist Ihr Dokument PDF/UA bzw. ISO14289-1 konform. Damit das PDF aber auch die gesetzliche Anforderung aus der deutschen BITV 2.0 (bzw. in Österreich dem WGZ, in der Schweiz dem ech0059 Standard) erfüllt, sind jetzt auch noch ein paar Restkriterien der WCAG zu prüfen. Die meisten WCAG Kriterien werden bereits über den PDF/UA Standard und über die Prüfung mit dem PAC abgedeckt. Ein paar Kriterien müssen aber zusätzlich geprüft werden. Diese sind:

1.4.6 bis 1.4.9
3.2.5
3.3.5 bis 3.3.6

Hier entsteht etwas Neues. Die Ausarbeitung wird schrittweise erfolgen und voraussichtlich bis Ende Juli 2026 abgeschlossen sein.

Hinweis: Die Prüfpunkte sind bewusst nach dem praktischen Prüfablauf und nicht nach der Reihenfolge des Matterhorn-Protokolls aufgebaut. Dadurch lassen sich PDF-Dokumente in der Praxis deutlich effizienter prüfen. Die Zuordnung zu den jeweiligen Matterhorn- und WCAG-Kriterien finden Sie am Ende jedes Prüfpunkts.

Prüfaufwand: 🟢 Gering
Häufigkeit: Hoch

Der in den Dokumenteigenschaften des PDFs hinterlegte Titel (technisch gesehen der dc:title-Eintrag in den XMP-Metadaten) muss zum Dokument passen und dieses eindeutig identifizieren. Er darf daher weder falsch noch zu allgemein formuliert sein.

Bedeutung für die Barrierefreiheit

Der Titel in den Dokumenteigenschaften bestimmt, wie PDF-Viewer und assistive Technologien das geöffnete PDF-Dokument bezeichnen. Ist der Titel falsch oder nicht eindeutig genug, können Nutzende nicht erkennen, um welches PDF-Dokument es sich handelt, ohne zuvor dessen Inhalt zu prüfen.

Typische Fehler

Ein neues Dokument wurde auf Basis eines bestehenden Dokuments erstellt. Dabei wurde jedoch vergessen, den Titel in den Dokumenteigenschaften anzupassen. Dadurch trägt das exportierte PDF den Titel des ursprünglichen Dokuments.
Der Dokumenttitel wurde zu allgemein formuliert und beschreibt nur die Art des Dokuments (z. B. „Jahresbericht“ statt „Jahresbericht 2025“). Dadurch lassen sich mehrere PDF-Dokumente dieser Art nicht eindeutig voneinander unterscheiden.

Prüfung in PAC

Übersichtsseite (Titel)

Tipp

Als Dokumenttitel eignet sich in den meisten Fällen der sichtbare Titel aus dem Inhaltsbereich des Dokuments (meist auf dem Deckblatt bzw. der ersten Seite). Bei mehreren gleichartigen Dokumenten sollte dieser jedoch um eindeutige Angaben (z. B. Jahr, Version, etc.) ergänzt werden.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.1-8
Matterhorn 1.1	06-004
EN 301 549	10.2.4.2 (basiert auf WCAG 2.2 SC 2.4.2)

Originalanforderungen

PDF/UA-1 (EN): „The Metadata stream in the document’s catalog dictionary shall contain a dc:title entry, […] which clearly identifies the document.“
PDF/UA-1 (DE): „Der Metadata-Datenstrom im Catalog-Dictionary des Dokuments muss einen Eintrag „dc:title“ enthalten […], mit dem das Dokument eindeutig identifiziert wird.“
Matterhorn 1.1 (EN): „dc:title does not clearly identify the document“
Matterhorn 1.1 (DE): „Der dc:title-Eintrag macht das Dokument nicht eindeutig identifizierbar.“
WCAG 2.2 (EN): „Web pages have titles that describe topic or purpose.“

Prüfaufwand: 🟢 Gering
Häufigkeit: Hoch

Die in den Dokumenteigenschaften des PDFs hinterlegte Dokumentsprache (technisch gesehen der Lang-Eintrag im Dokumentkatalog) muss die tatsächliche Hauptsprache des Dokuments widerspiegeln. Die Prüfung beschränkt sich dabei lediglich auf die Spracheinstellung auf Dokumentebene. Anderssprachige Textpassagen innerhalb des Dokuments werden in einem späteren Prüfschritt betrachtet.

Bedeutung für die Barrierefreiheit

Die hinterlegte Dokumentsprache steuert beispielsweise, wie Screenreader die Inhalte des PDF-Dokuments vorlesen. Ist eine falsche Sprache hinterlegt, werden Wörter häufig falsch ausgesprochen und Inhalte dadurch schwerer verständlich.

Typische Fehler

Ein Dokument wurde ausnahmsweise in einer anderen Sprache erstellt als üblich. Da die Spracheinstellung beim PDF-Export bisher nicht umgestellt werden musste, wurde die Umstellung in diesem Fall übersehen. Dadurch ist im PDF eine falsche Dokumentsprache hinterlegt.
Die Sprache wurde während der Bearbeitung des Dokuments durch eine automatische Spracherkennung unbemerkt geändert und beim PDF-Export als Dokumentsprache übernommen. Dadurch ist im PDF eine Sprache als Hauptsprache hinterlegt, die nicht der tatsächlichen Hauptsprache des Dokuments entspricht (sondern eventuell nur einen Teil des Dokuments ausmacht).

Prüfung in PAC

Übersichtsseite (Sprache)

Tipp

Als Dokumentsprache sollte immer die Sprache festgelegt werden, in der der überwiegende Teil des Dokuments verfasst ist. Einzelne anderssprachige Wörter, Sätze oder Textabschnitte ändern die Dokumentsprache in der Regel nicht. Für sie stehen separate Spracheinstellungen auf untergeordneten Ebenen zur Verfügung, die in einem späteren Prüfschritt behandelt werden.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.2-3
Matterhorn 1.1	11-007
EN 301 549	10.3.1.1 (basiert auf WCAG 2.2 SC 3.1.1)

Originalanforderungen

PDF/UA-1 (EN): „Natural language shall be declared as discussed in ISO 32000-1:2008, 14.9.2 and/or as described in ISO 32000-1:2008, 7.9.2.“
PDF/UA-1 (DE): „Eine natürliche Sprache muss wie in ISO 32000-1:2008, 14.9.2, erörtert und/oder wie in ISO 32000-1:2008, 7.9.2, beschrieben deklariert werden.“
Matterhorn 1.1 (EN): „Natural language is not appropriate.“
Matterhorn 1.1 (DE): „Die natürliche Sprache ist nicht geeignet.“
WCAG 2.2 (EN): „The default human language of each web page can be programmatically determined.“

Prüfaufwand: 🟡 Mittel
Häufigkeit: Hoch

Alle für das Verständnis eines PDF-Dokuments relevanten Inhalte müssen im Tag-Baum enthalten und mit einem semantisch passenden Tag ausgezeichnet sein. Hierzu definiert die PDF-Norm eine Vielzahl vordefinierter Standard-Tags, die jeweils für einen bestimmten Inhaltstyp vorgesehen sind (s. unten).

Eine maschinelle Prüfung erkennt bereits, ob Inhalte getaggt sind. Sie kann jedoch nicht beurteilen ob alle inhaltliche relevanten Elemente getaggt wurde und ob für den jeweiligen Inhalt auch tatsächlich das semantisch passende Tag gewählt wurde. Deshalb muss manuell sichergestellt werden, dass alle relevanten Inhalte mit dem jeweils semantisch korrekten Tag ausgezeichnet sind.

Die nachfolgende Übersicht beschreibt die in der Praxis wichtigsten Standard-Tags und deren typische Verwendung.

Document: Wurzel des Tag-baums
Part: Gliederungselement für einen größeren Dokumentabschnitt (z. B. Kapitel)
Art: Gliederungselement für einen inhaltlich geschlossenen Beitrag innerhalb eines Dokuments
Sect: Gliederungselement für einen Unterabschnitt
Div: Allgemeiner Strukturcontainer ohne eigene semantische Bedeutung
H1-H6: Überschriften
P: Absatz, Titel und Weitere, für die kein anderes Element passend ist
Link: Hyperlink
Span: Textbereich (z. B. zur Kennzeichnung anderssprachiger Passagen)
Quote: Zitat (innerhalb eines Absatzes)
BlockQuote: Zitat (als eigenständiger Absatz)
L: Listen-Container
LI: Listeneintrag-Container
Lbl: Listenzeichen (oder generell Bezeichnung von Elementen)
LBody: Inhalt eines Listeneintrags
Reference: Verweis auf eine andere Stelle im Dokument
Note: Fußnote, Endnote (bzw. ergänzende und erklärende Inhalte)
Caption: Beschriftung (z. B. einer Abbildung oder Tabelle)
Figure: Abbildung (z. B. Bild, Diagramm oder Grafik)
Table: Tabellen-Container
THead: Tabellenkopf-Container (optionales Gliederungselement)
TBody: Tabelleninhalt-Container (optionales Gliederungselement)
TFoot: Tabellenfuß-Container (optionales Gliederungselement)
TR: Tabellenzeile
TH: Tabellenkopfzelle
TD: Tabellendatenzelle
TOC: Inhaltsverzeichnis-Container
TOCI: Inhaltsverzeichnis-Eintrag
Formula: Mathematischer Ausdruck
Form: Formularfeld

Bedeutung für die Barrierefreiheit

Nur Inhalte, die im Tag-Baum enthalten sind, können von assistiven Technologien zuverlässig erfasst und ausgegeben werden. Darüber hinaus ist die semantisch korrekte Auszeichnung entscheidend, damit die Bedeutung der Inhalte richtig interpretiert wird. So nutzen Screenreader Überschriften beispielsweise zur Navigation innerhalb eines Dokuments. Wären Überschriften lediglich als Absätze () ausgezeichnet, könnten Screenreader-Nutzende nur absatzweise durch das Dokument navigieren. Insbesondere bei umfangreichen Dokumenten würde dies die Orientierung erheblich erschweren.

Typische Fehler

Im Quelldokument wurden die Kontaktinformationen ausschließlich in der Fußzeile platziert. Das Autorenprogramm zeichnete die Fußzeile beim PDF-Export als Artefakt aus, sodass die Kontaktinformationen nicht im Tag-Baum enthalten sind. Das erste Vorkommnis der Kontaktinformationen hätte im Tag-Baum ausgezeichnet werden müssen, damit die Kontaktinformationen wahrnehmbar sind.
Im Quelldokument wurde für Zitate eine Funktion oder Formatvorlage verwendet, für die das Autorenprogramm kein passendes Standard-Tag verwendet. Beim PDF-Export wurden die Zitate daher als Absätze () ausgezeichnet, obwohl das Tag <BlockQuote> semantisch korrekt gewesen wäre.
Ein bestehendes PDF-Dokument wurde automatisiert nachbearbeitet, um in PAC den grünen Haken zu erreichen. Dabei wurden nahezu alle Inhalte pauschal als Absätze () ausgezeichnet. Dadurch geht die semantische Struktur des Dokuments weitgehend verloren und assistive Technologien können die verschiedenen Inhaltstypen nicht mehr zuverlässig unterscheiden.

Prüfung in PAC

Fenster „Screenreader-Vorschau“ öffnen
(Dort werden alle getaggten Elemente einschließlich der verwendeten Tag-Typen dargestellt.)

Tipp

Erstellen Sie das Dokument möglichst bereits im Autorenprogramm technisch korrekt. Hierzu gehört insbesondere die konsequente Verwendung von Formatvorlagen (auch Absatzformate genannt) sowie der vorgesehenen Funktionen für Überschriften, Listen, Tabellen, Abbildungen und andere Inhaltstypen. Dadurch werden beim PDF-Export die meisten relevanten Inhalte automatisch mit den passenden Tags ausgezeichnet. Auch ohne geeignete Add-Ins verbleiben vor allem bei einfachen Dokumenten in der Regel nur wenige Elemente, deren Tags nach dem PDF-Export manuell korrigiert werden müssen.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.1-1, 7.1-2
Matterhorn 1.1	01-002, 01-006
EN 301 549	10.1.3.1 (basiert auf WCAG 2.2 SC 1.3.1)

Originalanforderungen

PDF/UA-1 (EN):
- „All real content shall be tagged as defined in ISO 32000-1:2008, 14.8. Artifacts (ISO 32000-1:2008, 14.8.2.2.2) shall not be tagged in the structure tree.“
- „Content shall be marked in the structure tree with semantically appropriate tags in a logical reading order. Content that does not render and does not have a rendered equivalent shall be marked as an artifact.“
PDF/UA-1 (DE):
- „Sämtlicher realer Inhalt muss nach Festlegung in ISO 32000-1:2008, 14.8, getaggt sein. Artefakte (ISO 32000-1:2008, 14.8.2.2.2) dürfen nicht im Strukturbaum getaggt werden.“
- „Inhalt muss im Strukturbaum mit semantisch geeigneten Tags in einer logischen Lesereihenfolge gekennzeichnet sein. Inhalt, der nicht dargestellt wird und für den auch kein entsprechender Ersatz dargestellt wird, muss als Artefakt gekennzeichnet sein.“
Matterhorn 1.1 (EN):
- „Real content is marked as artifact.“
- „The structure type and attributes of a structure element are not semantically appropriate for the structure element.“
Matterhorn 1.1 (DE):
- „Realer Inhalt ist als Artefakt gekennzeichnet.“
- „Der Strukturtyp und Attribute eines Strukturelementes sind nicht semantisch geeignet für das Strukturelement“
WCAG 2.2 (EN): „Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.“

Prüfaufwand: 🟡 Mittel
Häufigkeit: Hoch

Die Tags in einem PDF müssen entsprechend ihrer Bedeutung korrekt ineinander verschachtelt sein. Je nach Art des Tags sind dabei bestimmte über- und untergeordnete Tags vorgesehen. Viele fehlerhafte Verschachtelungen können bereits maschinell geprüft werden. Es gibt jedoch auch Fälle, in denen eine semantisch unpassende Verschachtelung nur manuell erkannt werden kann. So kann beispielsweise eine zweistufige Liste fälschlicherweise als zwei getrennte Listen getaggt sein, obwohl die untergeordnete Liste in ein LBody-Tag der übergeordneten Liste verschachtelt sein müsste.

Bedeutung für die Barrierefreiheit

Assistive Technologien nutzen die Verschachtelung der Tags, um die semantischen Beziehungen der Inhalte zueinander zu erkennen. Sind Tags semantisch falsch verschachtelt, können Inhalte in einem falschen Zusammenhang ausgegeben oder ihre Bedeutung nicht korrekt vermittelt werden.

Typische Fehler

Im Autorenprogramm wurden zwei getrennte Listen erstellt, obwohl inhaltlich eine zweistufige Liste dargestellt werden sollte. Dadurch ist nach dem PDF-Export die untergeordnete Liste nicht korrekt in die übergeordnete Liste verschachtelt.
In Adobe InDesign wurde eine Tabelle erstellt und das Dokument als PDF exportiert. Beim PDF-Export verschachtelt InDesign das Table-Tag in ein P-Tag. Dadurch entspricht die Tag-Struktur nicht der semantisch korrekten Verschachtelung.
In Microsoft Word wurde ein Inhaltsverzeichnis erstellt und das Dokument als PDF exportiert. Beim PDF-Export verschachtelt Microsoft Word die Inhaltsverzeichnisüberschrift (fälschlicherweise als TOCI getaggt) in das Inhaltsverzeichnis (TOC-Tag). Dadurch entspricht die Tag-Struktur nicht der semantisch korrekten Verschachtelung.
In Microsoft Word oder Adobe InDesign wurde eine Grafik verlinkt und das Dokument als PDF exportiert. Beim PDF-Export wird das Figure-Tag nicht in das Link-Tags verschachtelt. Dadurch entspricht die Tag-Struktur nicht der semantisch korrekten Verschachtelung.

Prüfung in PAC

Fenster „Screenreader-Vorschau“ öffnen
(Dort werden die Tags einschließlich ihrer Verschachtelung dargestellt.)

Tipp

Öffnen Sie die Screenreader-Vorschau und das PDF nebeneinander. Vergleichen Sie anschließend die Verschachtelung der Tags mit der visuellen Ansicht des Dokuments. Die Beurteilung semantischer Verschachtelungen erfordert etwas Übung und setzt Kenntnisse über die zulässigen Beziehungen zwischen den einzelnen Tags voraus. Mit zunehmender Erfahrung fällt es jedoch leichter zu erkennen, ob die semantischen Beziehungen der Tags korrekt umgesetzt wurden.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.2-1
Matterhorn 1.1	09-002
EN 301 549	10.1.3.1 (basiert auf WCAG 2.2 SC 1.3.1)

Originalanforderungen

PDF/UA-1 (EN): „The most semantically appropriate tag shall be used for each logical element in the document content.“
PDF/UA-1 (DE): „Für jedes logische Element im Inhalt des Dokuments muss das semantisch am besten geeignete Tag verwendet werden.“
Matterhorn 1.1 (EN): „Structure elements are nested in a semantically inappropriate manner. (e.g., a table inside a heading).“
Matterhorn 1.1 (DE): „Strukturelemente sind in einer Weise verschachtelt, die semantisch nicht geeignet ist (zum Beispiel eine Tabelle innerhalb einer Überschrift).“
WCAG 2.2 (EN): „Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.“

Prüfaufwand: 🟢 Gering
Häufigkeit: Hoch

Jedes PDF besitzt eine sogenannte logische Inhaltsreihenfolge. Sie beschreibt die vom Autor beabsichtigte Reihenfolge, in der die Inhalte des Dokuments gelesen (oder anderweitig ausgegeben) werden sollen. Im PDF wird diese beabsichtigte Reihenfolge durch die Reihenfolge der Tags im Tag-Baum festgelegt. Daher müssen die Tags entsprechend der beabsichtigten logischen Inhaltsreihenfolge angeordnet sein.

Bedeutung für die Barrierefreiheit

Assistive Technologien orientieren sich an der Reihenfolge der Tags, um die Inhalte eines Dokuments auszugeben. Sind die Tags nicht entsprechend der logischen Inhaltsreihenfolge angeordnet, werden die Inhalte in einer falschen Reihenfolge ausgegeben. Dadurch können die Zusammenhänge zwischen den Inhalten verloren gehen, wodurch die Inhalte möglicherweise nicht mehr verständlich sind.

Typische Fehler

In Adobe InDesign wurde die logische Inhaltsreihenfolge des Dokuments nicht im Artikelfenster festgelegt. Dadurch legt InDesign die Reihenfolge der Tags beim PDF-Export selbstständig fest, wodurch diese häufig nicht der beabsichtigten logischen Inhaltsreihenfolge entspricht.
In Microsoft Word wurden schwebende Elemente (z. B. Textfelder mit der Textumbruch-Option „Vor den Text“) verwendet. Die Elemente wurden jedoch nicht an der beabsichtigten Stelle im Dokument verankert. Dadurch legt Microsoft Word die Position der Verankerung selbst fest, sodass die Reihenfolge der Tags nach dem PDF-Export häufig nicht der beabsichtigten logischen Inhaltsreihenfolge entspricht.

Prüfung in PAC

Fenster „Logische Struktur“ öffnen
Reiter „Strukturelemente“ und „Seitenansicht“ aktivieren
Document-Tag erweitern
Erstes Tag innerhalb des Document-Tags auswählen
Mit den Pfeiltasten durch den Tag-Baum navigieren
(Während der Navigation durch den Tag-Baum wird der Inhalt des jeweils ausgewählten Tags in der Seitenansicht hervorgehoben. Dadurch lässt sich prüfen, ob die Inhalte entsprechend der logischen Inhaltsreihenfolge angeordnet sind.)

Tipp

Insbesondere bei grafisch gestalteten Dokumenten (z. B. Broschüren oder Flyer) entspricht die logische Inhaltsreihenfolge nicht immer der Anordnung der Inhalte von links oben nach rechts unten. Berücksichtigen Sie bei der Prüfung daher auch mehrspaltige Layouts, Infoboxen oder andere Elemente, die an einer anderen Stelle vorgelesen/ausgegeben werden sollen als ihre Position auf der Seite vermuten lässt.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.2-1
Matterhorn 1.1	09-001
EN 301 549	10.1.3.2 (basiert auf WCAG 2.2 SC 1.3.2)

Originalanforderungen

PDF/UA-1 (EN): „Content shall be tagged in logical reading order.“
PDF/UA-1 (DE): „Inhalt muss in logischer Lesereihenfolge getaggt sein.“
Matterhorn 1.1 (EN): „Tags are not in logical reading order.“
Matterhorn 1.1 (DE): „Die Anordnung der Tags entspricht nicht der logischen Lesereihenfolge.“
WCAG 2.2 (EN): „When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.“

Prüfaufwand: 🟡 Mittel
Häufigkeit: Mittel

Informationen dürfen nicht ausschließlich durch die visuelle Darstellung vermittelt werden. Werden beispielsweise Farben, Kontraste oder Formatierungen verwendet, um zusätzliche Informationen oder Zusammenhänge zu vermitteln, müssen diese auch in anderer Form verfügbar sein. Eine Warnung darf beispielsweise nicht ausschließlich durch rote Schrift gekennzeichnet werden. Wird aber das Wort „Warnung“ vorangestellt, ist die Bedeutung auch unabhängig von der Farbe erkennbar.

Bedeutung für die Barrierefreiheit

Assistive Technologien können Informationen, die ausschließlich durch die visuelle Gestaltung vermittelt werden, in der Regel nicht erkennen. Werden Informationen daher nur durch Farbe, Kontrast, Formatierung oder die Anordnung von Inhalten vermittelt, können sie für blinde oder sehbehinderte Menschen verloren gehen. Zusätzliche textliche oder semantische Informationen stellen sicher, dass die Inhalte für alle Nutzenden zugänglich sind.

Typische Fehler

Bei der Erstellung des Dokuments wurden Warnungen ausschließlich durch rote Schrift oder eine farbige Hinterlegung hervorgehoben. Da auf eine zusätzliche textliche Kennzeichnung (z. B. „Warnung“) verzichtet wurde, ist die besondere Bedeutung nur anhand der visuellen Gestaltung erkennbar.
In einem Formular wurden Pflichtfelder ausschließlich durch eine rote Umrandung gekennzeichnet, anstatt die dafür vorgesehene Formularfeldeigenschaft zu setzen. Dadurch erkennen Nutzende assistiver Technologien nicht, dass es sich um ein Pflichtfeld handelt.

Prüfung in PAC

Fenster „Logische Struktur“ öffnen
Reiter „Strukturelemente“ und „Seitenansicht“ aktivieren
(Prüfen Sie die Seitenansicht auf Informationen, die ausschließlich durch Farben, Kontraste, Formatierungen oder die Anordnung von Inhalten hervorgehoben werden. Stellen Sie anschließend fest, ob diese Informationen zusätzlich in anderer Form, beispielsweise textlich oder semantisch, verfügbar sind.)

Tipp

Visuelle Hervorhebungen sollten in erster Linie der besseren Orientierung dienen und keine zusätzlichen Informationen vermitteln. Muss eine farbliche Hervorhebung, Formatierung oder Anordnung dennoch eine zusätzliche Bedeutung transportieren, sollte diese immer zusätzlich textlich oder semantisch bereitgestellt werden.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.1-6
Matterhorn 1.1	04-001
EN 301 549	10.1.3.1 (basiert auf WCAG 2.2 SC 1.3.1) 10.1.3.3 (basiert auf WCAG 2.2 SC 1.3.3) 10.1.4.1 (basiert auf WCAG 2.2 SC 1.4.1)

Originalanforderungen

PDF/UA-1 (EN): „Information shall not be conveyed by contrast, colour, format or layout, or by combinations thereof, unless the content is tagged to reflect all intended meaning.“
PDF/UA-1 (DE): „Informationen dürfen nicht ausschließlich durch Kontrast, Farbe, Format, Layout oder Kombinationen davon übermittelt werden, es sei denn, der Inhalt ist so getaggt, dass dadurch die gesamte beabsichtigte Bedeutung repräsentiert wird.“
Matterhorn 1.1 (EN): „Information is conveyed by contrast, color, format or layout, or some combination thereof but the content is not tagged to reflect all meaning conveyed by the use of contrast, color, format or layout, or some combination thereof.“
Matterhorn 1.1 (DE): „Informationen werden ausschließlich durch Kontrast, Farbe, Formatierung Layout oder durch deren Kombination vermittelt und der Inhalt ist dabei nicht getaggt, um die Bedeutung, die durch Kontrast, Farbe, Formatierung, Layout oder durch deren Kombination, wiederzugeben .“
WCAG 2.2 (EN):
- „Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.“
- „Instructions provided for understanding and operating content do not rely solely on sensory characteristics of components such as shape, color, size, visual location, orientation, or sound.“
- „Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element.“

Prüfaufwand: 🔴 Hoch
Häufigkeit: Mittel

Enthält ein Dokument Textpassagen oder andere textliche Inhalte, deren Sprache von der Dokumentsprache abweicht, muss für diese Inhalte die abweichende Sprache hinterlegt werden. Dies betrifft beispielsweise fremdsprachige Absätze aber auch Texte, die in Attributen hinterlegt sind (z. B. Erweiterungstexte, Ersatztexte, Alternativtexte, barrierefreie Namen von Formularfeldern und Lesezeichen).

Bedeutung für die Barrierefreiheit

Die hinterlegte Sprache steuert beispielsweise, wie Screenreader die Inhalte des PDF-Dokuments vorlesen. Ist für anderssprachige Textpassagen oder Inhalte nicht die korrekte Sprache deklariert, werden Wörter häufig falsch ausgesprochen und Inhalte dadurch schwerer verständlich.

Typische Fehler

Bei der Erstellung des Dokuments wurden fremdsprachige Textpassagen eingefügt. Die abweichende Sprache wurde jedoch nicht hinterlegt. Dadurch enthält das exportierte PDF nur eine einzige Sprachkennzeichnung für das gesamte Dokument.

Prüfung in PAC

Fenster „Logische Struktur“ öffnen
Reiter „Strukturelemente“ und „Seitenansicht“ aktivieren
Relevantes Tag finden und auswählen
Reiter „Eigenschaften“ aktivieren
(Sofern eine abweichende Sprachkennzeichnung hinterlegt ist, wird sie hier angezeigt.)

Hinweis: Die Sprachkennzeichnung muss nicht zwingend auf dem ausgewählten Tag hinterlegt sein. Sie kann sich auch auf untergeordneten Elementen innerhalb des Tags befinden.

Tipp

In der Praxis ist es in der Regel nicht erforderlich, jedes einzelne fremdsprachige Wort mit einer eigenen Sprachkennzeichnung zu versehen. So müssen beispielsweise die Wörter „Public Viewing“ im Satz „Zum Finale treffen wir uns zum Public Viewing und erleben das Spiel gemeinsam auf der großen Leinwand.“ nicht zwingend als englisch gekennzeichnet werden. Konzentrieren Sie sich stattdessen auf zusammenhängende Textpassagen in einer anderen Sprache.

Verwenden Sie für anderssprachige Textpassagen möglichst separate Formatvorlagen (auch Absatzformate genannt) mit der passenden Spracheinstellung. Dadurch wird die Sprachkennzeichnung automatisch übernommen und alle Textpassagen einer Sprache können bei Bedarf einheitlich formatiert und vom restlichen Text abgehoben werden (z. B. in kursiv).

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.2-3
Matterhorn 1.1	11-007
EN 301 549	10.3.1.2 (basiert auf WCAG 2.2 SC 3.1.2)

Originalanforderungen

PDF/UA-1 (EN): „Changes in natural language shall be declared. Changes in natural language inside text strings (e.g. inside alternate descriptions) shall be declared using a language identifier as described in ISO 32000-1:2008, 14.9.2.2.“
PDF/UA-1 (DE): „Wechsel der natürlichen Sprache sind ebenfalls zu deklarieren. Wechsel der natürlichen Sprache innerhalb von Textelementen (z. B. in alternativen Beschreibungen) müssen unter Verwendung einer Sprachkennung nach der Beschreibung in ISO 32000-1:2008, 14.9.2.2, deklariert werden.“
Matterhorn 1.1 (EN): „Natural language is not appropriate.“
Matterhorn 1.1 (DE): „Die natürliche Sprache ist nicht geeignet.“
WCAG 2.2 (EN): „The human language of each passage or phrase in the content can be programmatically determined except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding text.“

Prüfaufwand: 🟡 Mittel
Häufigkeit: Hoch

In der Praxis enthalten nahezu alle Dokumente inhaltlich irrelevante Elemente. Das können beispielsweise dekorative Grafiken, Trennlinien oder Schnittmarken sein. Solche Elemente werden als Artefakte ausgezeichnet und erscheinen daher nicht im Tag-Baum.

Darüber hinaus enthalten viele Dokumente Informationen, die auf mehreren Seiten wiederholt werden und in visuellen Darstellungen zur Orientierung beitragen können. Beispiele hierfür sind Kapitelüberschriften in der Kopfzeile (auch lebende Kolumnentitel genannt), Dokumentinformationen in der Fußzeile oder Seitenzahlen. Das erste Vorkommnis dieser Informationen wird im Tag-Baum ausgezeichnet. Alle weiteren Vorkommnisse werden als Artefakte gekennzeichnet, da sie für den Dokumentinhalt redundant sind und den Lesefluss assistiver Technologien stören würden.

Eine maschinelle Prüfung erkennt bereits, ob ein Inhalt als Artefakt ausgezeichnet wurde. Sie kann jedoch nicht beurteilen, ob diese Auszeichnung fachlich richtig ist. Deshalb muss manuell sichergestellt werden, dass nur inhaltlich irrelevante oder redundante Inhalte als Artefakte gekennzeichnet sind.

Bedeutung für die Barrierefreiheit

Artefakte enthalten keine für das Verständnis des Dokuments relevanten Informationen. Wären sie fälschlicherweise getaggt, könnten sie bei der Ausgabe durch assistive Technologien den Lesefluss stören und eine unnötige kognitive Belastung darstellen. Die Kennzeichnung als Artefakt stellt sicher, dass assistive Technologien solche Elemente ignorieren, sofern sie diese nicht für alternative visuelle Darstellungen gezielt auswerten.

Typische Fehler

Ein auf jeder Seite wiederkehrendes Firmenlogo wurde auf jeder Seite getaggt. Während das erste Vorkommnis des Logos im Tag-Baum enthalten sein muss, hätten die weiteren Vorkommnisse als Artefakte ausgezeichnet werden müssen. Ansonsten wird das Logo von assistiven Technologien mehrfach ausgegeben und der Lesefluss gestört.
Wiederkehrende Kontaktinformationen in der Fußzeile wurden auf jeder Seite getaggt. Während das erste Vorkommnis im Tag-Baum enthalten sein muss, hätten die weiteren Vorkommnisse als Artefakte ausgezeichnet werden müssen.
Die Linie einer Unterstreichung wurde gemeinsam mit dem unterstrichenen Wort getaggt, obwohl sie keine eigenständige inhaltliche Information vermittelt. Die Linie hätte daher als Artefakt ausgezeichnet werden müssen.

Prüfung in PAC

Fenster „Logische Struktur“ öffnen
Reiter „Artefakte“ und „Seitenansicht“ aktivieren
Seite erweitern
Erstes Artefakt innerhalb der Seite auswählen
Mit den Pfeiltasten durch den Artefakt-Baum navigieren
(Während der Navigation wird das jeweils ausgewählte Artefakt in der Seitenansicht hervorgehoben. Prüfen Sie, ob ausschließlich inhaltlich irrelevante oder redundante Inhalte hervorgehoben werden.)

Tipp

Lassen Sie sich nicht davon irritieren, wenn beim Navigieren durch den Artefakt-Baum scheinbar Inhalte von Tabellenzellen hervorgehoben werden. Häufig handelt es sich dabei lediglich um die Rahmenlinien der Tabelle. Solche Artefakte tragen im PAC meist die Bezeichnung „[Path]“ und stellen grafische Elemente ohne inhaltliche Bedeutung dar.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.1-1
Matterhorn 1.1	01-001
EN 301 549	10.1.3.1 (basiert auf WCAG 2.2 SC 1.3.1)

Originalanforderungen

PDF/UA-1 (EN): „Artifacts (ISO 32000-1:2008, 14.8.2.2.2) shall not be tagged in the structure tree.“
PDF/UA-1 (DE): „Artefakte (ISO 32000-1:2008, 14.8.2.2.2) dürfen nicht im Strukturbaum getaggt werden.“
Matterhorn 1.1 (EN): „Artifact is tagged as real content.“
Matterhorn 1.1 (DE): „Artefakte sind als realer Inhalt getaggt.“
WCAG 2.2 (EN): „Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.“

Prüfaufwand: 🟡 Mittel
Häufigkeit: Hoch

Einem Artefakt können verschiedene Eigenschaften zugewiesen werden. Für Kopf- und Fußzeilen müssen dabei mindestens die Eigenschaften Type und Subtype definiert sein. Type muss den Wert Pagination besitzen, während Subtype den Wert Header oder Footer besitzen muss.

Bedeutung für die Barrierefreiheit

Zusätzlich enthalten viele Dokumente Informationen, die auf jeder Seite wiederholt werden und in visuellen Darstellungen zur Orientierung beitragen können. Beispiele hierfür sind Kapitelüberschriften in der Kopfzeile (auch lebende Kolumnentitel genannt), Dokumentinformationen in der Fußzeile oder Seitenzahlen. Auch diese Elemente werden als Artefakte ausgezeichnet.

Für manche assistive Technologien ist die Unterscheidung zwischen den verschiedenen Arten von Artefakten unerheblich. Ein Screenreader sollte beispielsweise weder dekorative Elemente ansagen noch einen Kolumnentitel mitten im Absatz vorlesen, nur weil ein Absatz auf die nächste Seite umbricht und der Kolumnentitel dort das erste Element ist.

Andere assistive Technologien basieren jedoch auf einer alternativen visuellen Darstellung des PDF-Dokuments. Für diese kann die zusätzliche Klassifizierung als Pagination-Artefakt hilfreich sein. Während rein dekorative Artefakte weiterhin ausgeblendet werden können, lassen sich Kopf- und Fußzeilen bei Bedarf gezielt darstellen. Ein lebender Kolumnentitel, eine Seitenzahl oder andere wiederkehrende Informationen können dabei zur Orientierung innerhalb des Dokuments beitragen.

Typische Fehler

Ein bestehendes PDF wurde nachträglich in Adobe Acrobat barrierefrei gemacht und die Kopf- und Fußzeilen als Artefakte ausgezeichnet. Bei der Auswahl des Artefakttyps wurde jedoch fälschlicherweise „Seite“ oder „Layout“ statt „Paginierung“ gewählt. Dadurch ist der Type-Eintrag auf Page bzw. Layout statt auf Pagination gesetzt.
Ein bestehendes PDF wurde nachträglich in Adobe Acrobat barrierefrei gemacht und die Kopf- und Fußzeilen korrekt als Pagination-Artefakte ausgezeichnet. Da der Subtype-Eintrag (Header bzw. Footer) jedoch nur separat über einen Umweg und auch nur mit tiefgehenden Fachkenntnissen ergänzt werden kann, wurde er nicht gesetzt. Dadurch fehlt die Information, ob es sich um Kopf- oder Fußzeileninhalte handelt.

Prüfung in PAC

Fenster „Logische Struktur“ öffnen
Reiter „Artefakte“ und „Seitenansicht“ aktivieren
Relevanten Inhalt finden und auswählen
Reiter „Eigenschaften“ aktivieren
(Sofern Einträge für Type und Subtype vorhanden sind, werden sie hier angezeigt.)

Tipp

Nicht jedes Artefakt in einer Kopf- oder Fußzeile ist automatisch ein Pagination-Artefakt. Als Pagination-Artefakte sollten nur Inhalte gekennzeichnet werden, die den Nutzenden zusätzliche Orientierung oder Informationen bieten. Entscheidend ist dabei die Funktion des Elements und nicht seine Position auf der Seite. Rein dekorative Elemente bleiben daher „normale“ Artefakte, selbst wenn sie sich in der Kopf- oder Fußzeile befinden.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.8-1
Matterhorn 1.1	18-001, 18-002
EN 301 549	–

Originalanforderungen

PDF/UA-1 (EN): „Running headers and footers shall be identified as Pagination artifacts and shall be classified as either Header or Footer subtypes as per ISO 32000-1:2008, 14.8.2.2.2, Table 330.“
PDF/UA-1 (DE): „Fortlaufende Kopf- und Fußzeilen müssen nach ISO 32000-1: 2008, 14.8.2.2.2, Tabelle 330, als Pagination-Artefakte identifiziert werden und müssen als Subtyp Header oder Footer gekennzeichnet werden.“
Matterhorn 1.1 (EN):
- „Headers and footers are not marked as pagination artifacts.“
- „Header or footer artifacts are not classified as Header or Footer subtypes.“
Matterhorn 1.1 (DE):
- „Kopf- und Fußzeilen sind nicht als Artefakte des Typs Pagination gekennzeichnet.“
- „Als Artefakte gekennzeichnete Kopf- oder Fußzeilen sind nicht als Subtyp Header oder Footer klassifiziert.“

Prüfaufwand: 🟡 Mittel
Häufigkeit: Hoch

Grundsätzlich wird zwischen zeichenbasierten und nummerierten Listen (auch ungeordnete und geordnete Listen genannt) unterschieden.

Zeichenbasierte Listen: werden mit Aufzählungszeichen bzw. Symbolen gekennzeichnet (z. B. • / ■ / □).
Nummerierte Listen: verwenden arabische Zahlen, römische Zahlen oder Buchstaben (z. B. 1 / i /a), um die Reihenfolge der Listeneinträge sichtbar zu machen.

Zur Beschreibung der verwendeten Listenkennzeichnung gibt es das sogenannte ListNumbering-Attribut. Für zeichenbasierte Listen ist dieses Attribut optional. Nummerierte Listen müssen dagegen ein ListNumbering-Attribut besitzen. Hierfür stehen die folgenden Werte zur Verfügung:

Decimal: 1, 2, 3, …
UpperRoman: I, II, III, …
LowerRoman: i, ii, iii, …
UpperAlpha: A, B, C, …
LowerAlpha: a, b, c, …

Der gewählte Wert muss mit der tatsächlich verwendeten Nummerierungsart übereinstimmen.

Hinweis: Neben zeichenbasierten und nummerierten Listen gibt es auch weitere Listenarten (z. B. Definitionslisten). Für diese ist das ListNumbering-Attribut genau wie bei zeichenbasierten Listen jedoch auch optional bzw. existiert für manche Listen-Arten gar kein geeignetes ListNumbering-Attribut. Der aktuelle Prüfschritt ist daher ausschließlich für nummerierte Listen relevant.

Bedeutung für die Barrierefreiheit

Die Art der Nummerierung besitzt eine semantische Bedeutung und muss daher in maschinenlesbarer Form zur Verfügung stehen. Das ListNumbering-Attribut stellt diese Information assistiven Technologien bereit. In der Praxis wird das Attribut zwar bislang nur von wenigen assistiven Technologien ausgewertet, es ermöglicht jedoch bereits heute und auch zukünftig, nummerierte Listen unabhängig von ihrer visuellen Darstellung korrekt zu interpretieren.

Ein Beispiel hierfür sind assistive Technologien, die Dokumente in einer alternativen visuellen Darstellungsform ausgeben. Mithilfe des ListNumbering-Attributs können solche Technologien die korrekte Nummerierungsart übernehmen, ohne diese aus den Inhalten der Listenpunktbezeichnungen (Lbl-Tags) ableiten zu müssen.

Die Unterscheidung der Nummerierungsarten ist dabei übrigens keineswegs nur eine optische Frage. Listenpunkte werden im Fließtext häufig direkt referenziert, beispielsweise „siehe Klausel I.b)“ oder „siehe Punkt c)“. Würde eine assistive Technologie die ursprüngliche Nummerierungsart nicht beibehalten und stattdessen beispielsweise alle Listen arabisch nummerieren, wären solche Verweise nicht mehr konsistent.

Typische Fehler

In einem grafisch gestalteten Dokument wurden die Listen im Autorenprogramm manuell statt mit den vorgesehenen Listenfunktionen erstellt. Nach dem PDF-Export wurden die Listen zwar manuell nachgetaggt. Aus Unwissenheit oder aufgrund der nur eingeschränkten Möglichkeiten zur Bearbeitung von PDF-Attributen wurde das ListNumbering-Attribut jedoch nicht ergänzt. Dadurch fehlt die semantische Information über die verwendete Nummerierungsart.
Ein bestehendes PDF wurde nachträglich barrierefrei gemacht und die Listen dabei korrekt getaggt. Das ListNumbering-Attribut wurde zwar ergänzt, jedoch mit einem falschen Wert versehen (z. B. Decimal statt LowerAlpha). Dadurch stimmt die maschinenlesbare Nummerierungsart nicht mit der tatsächlich verwendeten Listenkennzeichnung überein.

Prüfung in PAC

Fenster „Logische Struktur“ öffnen
Reiter „Strukturelemente“ und „Seitenansicht“ aktivieren
Relevantes L-Tag finden und auswählen
Reiter „Eigenschaften“ aktivieren
(Sofern ein Eintrag für das ListNumbering-Attribut vorhanden ist, wird er hier angezeigt.)

Tipp

Nummerierte Listen sollten möglichst bereits im Autorenprogramm mit den vorgesehenen Listenfunktionen erstellt werden. Denn in diesem Fall wird das ListNumbering-Attribut beim PDF-Export häufig automatisch korrekt gesetzt. Werden Listen erst nachträglich im PDF getaggt, muss das ListNumbering-Attribut dagegen in der Regel manuell ergänzt werden.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.6-1
Matterhorn 1.1	16-001, 16-002
EN 301 549	–

Originalanforderungen

PDF/UA-1 (EN): „An explicit ListNumbering attribute shall be used for L tags in ordered lists as specified in ISO 32000-1:2008, 14.8.5.5, Table 347.“
PDF/UA-1 (DE): „bei nummerierten Listen müssen die L-Tags wie in ISO 32000-1:2008, 14.8.5.5, Tabelle 347, festgelegt explizit über ein ListNumbering-Attribut verfügen.“
Matterhorn 1.1 (EN):
- „List is an ordered list, but no value for the ListNumbering attribute is present.“
- „List is an ordered list, but the ListNumbering value is not one of the following: Decimal, UpperRoman, LowerRoman, UpperAlpha, LowerAlpha.“
Matterhorn 1.1 (DE):
- „Bei einer nummerierten Liste ist für das ListNumbering-Attribut kein Wert eingetragen.“
- „Bei einer nummerierten Liste fehlt einer der folgenden ListNumbering-Werte: Decimal, UpperRoman, LowerRoman, UpperAlpha, LowerAlpha.“

Prüfaufwand: 🟡 Mittel
Häufigkeit: Hoch

Eine Tabelle besteht im Wesentlichen aus Tabellenkopfzellen (TH-Tags) und Tabellendatenzellen (TD-Tags). Für jede Tabellendatenzelle muss eindeutig festgelegt sein, welche Tabellenkopfzellen zu ihr gehören.

Diese Zuordnung kann auf zwei Arten erfolgen. Die erste Möglichkeit ist das Scope-Attribut. Dieses wird auf dem TH-Tag definiert und legt den Geltungsbereich der Tabellenkopfzelle anhand einer Richtung fest. Das Scope-Attribut kann dabei folgende Werte annehmen:

Row: Die Kopfzelle gilt für alle restlichen Zellen derselben Zeile.
Column: Die Kopfzelle gilt für alle restlichen Zellen derselben Spalte.
Both: Die Kopfzelle gilt für alle restlichen Zellen derselben Zeile und Spalte.

Die zweite Möglichkeit besteht darin, jeder Tabellenkopfzelle eine eindeutige ID zuzuweisen. Jede Tabellendatenzelle erhält anschließend ein Headers-Attribut, in dem die IDs aller zugehörigen Tabellenkopfzellen aufgeführt sind. Dieses Verfahren wird insbesondere bei komplexen Tabellen eingesetzt, bei denen sich die Zuordnung nicht allein über das Scope-Attribut beschreiben lässt.

Ob einer Tabellendatenzelle grundsätzlich Tabellenkopfzellen zugeordnet sind, lässt sich bereits maschinell prüfen. In der Praxis kommt es jedoch häufig vor, dass die Zuordnung unvollständig oder falsch ist. Einzelnen Tabellendatenzellen fehlen dann beispielsweise relevante Tabellenkopfzellen oder es werden Tabellenkopfzellen zugeordnet, die für die jeweilige Zelle gar nicht gelten. Bei diesem Prüfschritt geht es daher vor allem darum, die Vollständigkeit und Korrektheit der Zuordnung zu überprüfen.

Bedeutung für die Barrierefreiheit

Für visuelle Nutzende ohne Einschränkungen lassen sich Tabellen meist intuitiv erfassen. Die räumliche Anordnung der Zellen macht unmittelbar deutlich, welche Tabellenkopfzellen zu einer bestimmten Tabellendatenzelle gehören. Nutzende assistiver Technologien verfügen über diese visuelle Orientierung jedoch häufig nicht oder nur eingeschränkt.

Eine eindeutige Zuordnung zwischen Tabellenkopfzellen und Tabellendatenzellen ist daher absolut entscheidend. Sie ermöglicht es assistiven Technologien, beim Navigieren durch eine Tabelle sowohl den Inhalt der aktuellen Tabellendatenzelle als auch die zugehörigen Tabellenkopfzellen auszugeben. Erst durch diese gemeinsame Ausgabe lässt sich der Inhalt einer Tabellenzelle eindeutig interpretieren.

Insbesondere bei komplexen Tabellen, bei denen mehrere Tabellenkopfzellen gleichzeitig für eine Tabellendatenzelle gelten, ist eine korrekte Zuordnung unverzichtbar. Fehlt sie oder ist sie fehlerhaft, können Tabelleninhalte und deren Zusammenhänge missverständlich oder gar nicht mehr nachvollziehbar sein.

Typische Fehler

Eine Tabellenkopfzelle gilt sowohl für die Zellen derselben Zeile als auch derselben Spalte. Im Autorenprogramm konnte jedoch nur ein Geltungsbereich festgelegt werden (z. B. „Erste Spalte“ oder „Kopfzeile“). Daher wurde das Scope-Attribut nur auf Row oder Column statt auf Both gesetzt. Dadurch ist der Geltungsbereich der Tabellenkopfzelle unvollständig beschrieben.
Ein bestehendes PDF wurde nachträglich barrierefrei gemacht und enthält eine komplexe Tabelle. Einer Tabellendatenzelle wurden dabei nicht alle IDs der zugehörigen Tabellenkopfzellen zugewiesen. Dadurch ist die Zuordnung der Tabellenkopfzellen zu dieser Tabellendatenzelle unvollständig.

Prüfung in PAC

Fenster „Logische Struktur“ öffnen
Reiter „Strukturelemente“ und „Seitenansicht“ aktivieren
Relevante Tabellenkopfzellen innerhalb von Tabellen finden und auswählen
(Sofern Zuordnungen zu bestimmten Tabellendatenzellen bestehen, werden diese farbig hervorgehoben.)

Tipp

Komplexe Tabellen sollten nach Möglichkeit vermieden werden. Häufig lassen sie sich ohne Informationsverlust in mehrere einfachere Tabellen aufteilen. Der Vorteil hierbei ist, dass die Zuordnung zwischen den Tabellenkopfzellen und Tabellendatenzellen in der Regel vollständig über Scope-Attribute erfolgen kann. Dadurch entfällt die deutlich aufwendigere Zuordnung über IDs und Headers-Attribute, bei der jeder Tabellenkopfzelle zunächst eine ID zugewiesen und anschließend jeder Tabellendatenzelle alle zugehörigen IDs manuell zugeordnet werden müssen.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.5-2
Matterhorn 1.1	15-005
EN 301 549	10.1.3.1 (basiert auf WCAG 2.2 SC 1.3.1)

Originalanforderungen

PDF/UA-1 (EN): „Structure elements of type TH should have a Scope attribute. If the table’s structure is not determinable via Headers and IDs, then structure elements of type TH shall have a Scope attribute.“
PDF/UA-1 (DE): „Strukturelemente des Typs TH sollten über ein Scope-Attribut verfügen. Kann die Struktur einer Tabelle nicht unter Rückgriff auf Headers- und ID-Attribute ermittelt werden, dann müssen Strukturelemente des Typs TH über ein Scope-Attribut verfügen.“
Matterhorn 1.1 (EN): „A given cell’s header cannot be unambiguously determined.“
Matterhorn 1.1 (DE): „Eine vorhandene Zeilen- oder Spaltenüberschrift zu einer Zelle kann nicht eindeutig ermittelt werden.“
WCAG 2.2 (EN): „Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.“

Prüfaufwand: 🟢 Gering
Häufigkeit: Hoch

Inhaltlich relevante Grafiken werden mit Figure-Tags ausgezeichnet. Ein Figure-Tag muss dabei immer eine Textalternative besitzen. Hierfür stehen zwei Arten der Textalternative zur Verfügung, von denen abhängig vom Inhalt des Figure-Tags die richtige gewählt werden muss:

Alternativtext: für Grafiken, die nicht primär als Text wahrgenommen werden sollen (z. B. ein Profilbild eines Autors oder ein Diagramm). Der Alternativtext muss die Inhalte der Grafik beschreiben, die für den Kontext relevant sind.
Ersatztext: für Grafiken, die primär Text darstellen (z. B. eine grafisch gestaltete Überschrift oder ein aus Pfaden bestehender Schriftzug). Der Ersatztext muss den in der Grafik enthaltenen Text vollständig und wortgleich wiedergeben.

Eine maschinelle Prüfung erkennt zwar bereits, ob ein Figure-Tag einen Alternativtext oder einen Ersatztext besitzt. Sie kann jedoch nicht beurteilen, welche der beiden Angaben für die jeweilige Grafik fachlich richtig ist. Deshalb muss manuell sichergestellt werden, dass Figure-Tags die korrekte Art der Textalternative besitzen.

Bedeutung für die Barrierefreiheit

Die Art der Textalternative bestimmt, wie assistive Technologien ein Figure-Tag verarbeiten und ausgeben. Figure-Tags mit einem Alternativtext werden als Grafik angekündigt und anschließend mit ihrem Alternativtext beschrieben. Dadurch erkennen Nutzer assistiver Technologien, dass sich an dieser Stelle eine Grafik befindet und erhalten zugleich die für das Verständnis relevanten Informationen über deren Inhalt.

Figure-Tags mit einem Ersatztext werden dagegen vollständig durch den hinterlegten Text ersetzt. Sie werden nicht als Grafik angekündigt. Stattdessen wird ausschließlich der Ersatztext ausgegeben. Dies entspricht dem Zweck von Grafiken, die primär Text darstellen, da nicht ihre grafische Gestaltung, sondern ausschließlich ihr Textinhalt relevant ist.

Enthält eine Grafik beispielsweise lediglich die grafisch gestaltete Überschrift „Veranstaltungsdetails“, so soll ein Screenreader nicht ankündigen, dass es sich um eine Grafik handelt. Stattdessen soll er die Überschrift mit dem Text „Veranstaltungsdetails“ ausgeben. Dass die Überschrift im Original grafisch dargestellt wurde, ist für das Verständnis nicht relevant und würde die schnelle Erfassung der Dokumentinhalte eher behindern.

Typische Fehler

Das Dokument wurde in einem Autorenprogramm (z. B. Microsoft Word) erstellt, das keine Möglichkeit bietet, einen Ersatztext für Grafiken zu hinterlegen. Stattdessen wurde ein Alternativtext verwendet, obwohl für die betreffende Grafik ein Ersatztext erforderlich wäre.
Das Dokument wurde in einem Autorenprogramm (z. B. Adobe InDesign) erstellt, welches separate Funktionen für Alternativtext und Ersatztext bietet. Aus Unkenntnis über deren unterschiedliche Bedeutung wurde jedoch ein Alternativtext statt des erforderlichen Ersatztexts hinterlegt.

Prüfung in PAC

Fenster „Screenreader-Vorschau“ öffnen
(Sofern als Textalternative ein Alternativtext verwendet wurde, werden das Figure-Tag einschließlich der Grafik sowie darunter der Alternativtext in der Vorschau angezeigt. Sofern ein Ersatztext verwendet wurde, werden weder das Figure-Tag noch die Grafik angezeigt. Stattdessen wird ausschließlich der Ersatztext angezeigt.)

Tipp

Enthält eine Grafik primär Text, ist dies ein starkes Indiz dafür, dass ein Ersatztext erforderlich ist. Entscheidend ist jedoch, welchem Zweck die Grafik dient. Soll sie in erster Linie einen Text vermitteln, ist ein Ersatztext zu verwenden. Dient sie dagegen hauptsächlich der visuellen Darstellung, ist stattdessen ein Alternativtext erforderlich.

Ein Firmenlogo, das ausschließlich aus Buchstaben besteht, benötigt beispielsweise keinen Ersatztext sondern einen Alternativtext. Denn obwohl es nur Text enthält, besteht der primäre Zweck des Logos darin, das Unternehmen visuell zu repräsentieren.

Auch die grafische Vorschau einer Schriftart (z. B. als Bild in einem Branding Guide) benötigt in der Regel keinen Ersatztext sondern einen Alternativtext. Der dargestellte Dummy-Text dient lediglich dazu, das Erscheinungsbild der Schrift zu veranschaulichen. Entscheidend ist hier die visuelle Darstellung der Schrift und nicht der Wortlaut des angezeigten Textes.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.3-3, 7.3-4
Matterhorn 1.1	13-005, 13-008
EN 301 549	10.1.1.1 (basiert auf WCAG 2.2 SC 1.1.1) 10.1.3.1 (basiert auf WCAG 2.2 SC 1.3.1)

Originalanforderungen

PDF/UA-1 (EN):
- „Figure tags shall include an alternative representation or replacement text that represents the contents marked with the Figure tag as noted in ISO 32000-1:2008, 14.7.2, Table 323.“
- „If text represented in a graphic is not text in a natural language that is meant to be read by a human reader, alternative text describing the nature or purpose of the graphic shall be provided.“
PDF/UA-1 (DE):
- „Figure-Tags müssen eine alternative Darstellung oder einen Ersatztext enthalten, der den mit dem Figure-Tag gekennzeichneten Inhalt repräsentiert, wie in ISO 32000-1:2008, 14.7.2 Tabelle 323, vermerkt.“
- „Wenn es sich bei in einer Grafik enthaltenem Text nicht um die Darstellung von Text in einer natürlichen Sprache handelt, der von einem Menschen gelesen werden soll, muss ein alternativer Text vorhanden sein, in dem Art oder Zweck der Grafik beschrieben werden.“
Matterhorn 1.1 (EN):
- „ActualText used for a <Figure> for which alternative text is more appropriate.“
- „ActualText not present when a <Figure> is intended to be consumed primarily as text.“
Matterhorn 1.1 (DE):
- „Bei einem Bild, für das ein Alternativtext geeigneter wäre, wird Ersatztext (ActualText) verwendet.“
- „Für ein Figure-Tag, welches primär als Text genutzt werden soll, ist kein Ersatztext (ActualText) vorhanden.“
WCAG 2.2 (EN):
- „All non-text content that is presented to the user has a text alternative that serves the equivalent purpose […]“
- „Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.“

Prüfaufwand: 🟢 Gering
Häufigkeit: Mittel

Werden mehrere grafische Objekte zusammen als eine einzige Grafik im Dokument verwendet, müssen alle diese zusammengehörenden grafischen Objekte auch gemeinsam mit einem einzigen Figure-Tag ausgezeichnet werden.
Dies betrifft beispielsweise Vektorgrafiken, die aus mehreren einzelnen grafischen Objekten aufgebaut sind. Ein Symbol kann beispielsweise aus einem Ring und einem darin angeordneten Pluszeichen bestehen. Obwohl beide Bestandteile technisch getrennte Objekte sind, bilden sie gemeinsam eine einzige Grafik und müssen daher auch gemeinsam mit einem einzigen Figure-Tag ausgezeichnet werden.

Bedeutung für die Barrierefreiheit

Assistive Technologien kündigen Figure-Tags als Grafiken an und geben deren Textalternative aus. Werden Bestandteile einer einzigen zusammengehörenden Grafik fälschlicherweise mit jeweils separaten Figure-Tags ausgezeichnet, werden sie als mehrere voneinander unabhängige Grafiken mit jeweils eigener Textalternative ausgegeben. Dadurch kann die inhaltliche Aussage der Grafik redundant, unverständlich oder irreführend werden.

Typische Fehler

Ein bestehendes PDF wurde nachträglich barrierefrei aufbereitet. Dabei wurden die grafischen Objekte eines Diagramms mit mehreren Figure-Tags ausgezeichnet, obwohl sie gemeinsam nur eine einzige zusammengehörige Grafik bilden.

Prüfung in PAC

Fenster „Screenreader-Vorschau“ öffnen
(Sofern ein zusammengehörender grafischer Inhalt mit mehreren Figure-Tags ausgezeichnet wurde, wird für jedes Figure-Tag eine eigene Grafik mit der jeweiligen Textalternative in der Screenreader-Vorschau angezeigt.)

Tipp

Komplexe Grafiken sollten nach dem Tagging darauf geprüft werden, ob sie vollständig von einem einzigen Figure-Tag umfasst werden. Insbesondere bei nachträglich barrierefrei aufbereiteten PDFs können zusammengehörende grafische Objekte versehentlich mit mehreren Figure-Tags ausgezeichnet werden.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.3-5
Matterhorn 1.1	13-006
EN 301 549	10.1.3.1 (basiert auf WCAG 2.2 SC 1.3.1)

Originalanforderungen

PDF/UA-1 (EN): „Graphics that possess semantic value only in combination with other graphics shall be tagged with a single Figure tag for each group.“
PDF/UA-1 (DE): „Grafiken, die nur in Kombination mit anderen Grafiken eine Bedeutung haben, müssen mit einem Figure-Tag je Gruppe von Grafiken versehen werden.“
Matterhorn 1.1 (EN): „Graphics objects that possess semantic value only within a group of graphics objects is tagged on its own.“
Matterhorn 1.1 (DE): „Grafikobjekte, die zu einer Gruppe von Grafikelementen gehören und nur als Teil davon einen semantischen Wert besitzen, sind als getrennte Elemente getaggt.“
WCAG 2.2 (EN): „Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.“

Prüfaufwand: 🟡 Mittel
Häufigkeit: Mittel

In der Praxis kommen immer wieder inhaltlich relevante Grafiken vor, die mit einem Link versehen sind (z. B. ein verlinkter QR-Code oder ein verlinktes Logo). In diesem Fall enthält das Link-Tag neben der Link-Annotation (OBJR-Element) auch das Figure-Tag als Kind-Element. Da die Grafik Bestandteil des Links ist, muss der Alternativtext des relevanten Link-Tags sowohl die Grafik als auch den Link beschreiben.

Bedeutung für die Barrierefreiheit

Bei verlinkten Grafiken bilden die Grafik und der Link eine inhaltliche Einheit. Assistive Technologien geben daher in der Regel den Alternativtext des Link-Tags aus und nicht zusätzlich den Alternativtext des darin enthaltenen Figure-Tags. Damit Nutzende alle relevanten Informationen erhalten, muss der Alternativtext des Link-Tags also beide Elemente beschreiben.

Typische Fehler

Im Autorenprogramm wurde eine Grafik eingefügt und mit einem Alternativtext versehen. Anschließend wurde die Grafik verlinkt. Bei der Erstellung des Link-Alternativtextes wurde die Grafik jedoch nicht berücksichtigt, sodass der Alternativtext nur den Link beschreibt.

Prüfung in PAC

Fenster „Logische Struktur“ öffnen
Reiter „Strukturelemente“ und „Seitenansicht“ aktivieren
Relevantes Link-Tag finden und erweitern
Link Annotation auswählen
Reiter „Eigenschaften“ aktivieren
(Der Alternativtext des Links wird im Contents-Eintrag angezeigt.)

Tipp

Verlinkte Grafiken stellen einen Sonderfall dar. Da Grafiken und Links im Arbeitsalltag meist getrennt voneinander verwendet werden, ist man es gewohnt, den Alternativtext jeweils nur für das einzelne Element zu formulieren. Bei einer verlinkten Grafik muss der Alternativtext des Link-Tags jedoch sowohl die Grafik als auch den Link beschreiben. Prüfen Sie daher den Alternativtext des Link-Tags in solchen Situationen besonders sorgfältig.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.3-1
Matterhorn 1.1	13-002
EN 301 549	10.1.1.1 (basiert auf WCAG 2.2 SC 1.1.1) 10.2.4.4 (basiert auf WCAG 2.2 SC 2.4.4)

Originalanforderungen

PDF/UA-1 (EN): „[…] the graphic appears as a background to a link annotation, in which case, the alternative text on the link shall describe both the graphic and the link.“
PDF/UA-1 (DE): „[…] die Grafik erscheint als Hintergrund einer Link-Annotation – in diesem Fall muss der alternative Text zum Link sowohl die Grafik als auch den Link beschreiben.“
Matterhorn 1.1 (EN): „A link with a meaningful background does not include alternative text describing both the link and the graphic’s purpose.“
Matterhorn 1.1 (DE): „Ein Link mit einer inhaltlich relevanten Darstellung weist keinen Alternativtext auf, der sowohl den Link als auch den Zweck der Grafik beschreibt.“
WCAG 2.2 (EN):
- „All non-text content that is presented to the user has a text alternative that serves the equivalent purpose […]“
- „The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.“

Prüfaufwand: 🟡 Mittel
Häufigkeit: Mittel

Formularfelder sind häufig mit einer sichtbaren Beschriftung versehen, die sich oberhalb, unterhalb oder neben dem Formularfeld befindet. Da diese Beschriftung technisch nicht Bestandteil des Formularfeldes ist, benötigen Formularfelder zusätzlich einen sogenannten barrierefreien Namen (Accessible Name). Dieser wird direkt am Formularfeld hinterlegt und ermöglicht dessen eindeutige Identifizierung. In PDF-Dokumenten wird der barrierefreie Name häufig über den TU-Eintrag definiert, der in vielen PDF-Editoren als „QuickInfo“ oder „ToolTip“ bezeichnet wird.

Der barrierefreie Name muss nun den vollständigen Text der visuellen Beschriftung enthalten. Zusätzliche Informationen dürfen ergänzt werden, sofern die visuelle Beschriftung vollständig enthalten bleibt.

Ob für ein Formularfeld ein barrierefreier Name definiert ist, wird bereits maschinell geprüft. Im Rahmen dieses Prüfschritts ist daher ausschließlich zu beurteilen, ob der Inhalt des barrierefreien Namens den vollständigen Text der visuellen Beschriftung enthält.

Bedeutung für die Barrierefreiheit

Personen, die mithilfe von Spracheingaben navigieren und Aktionen auslösen, verwenden häufig die visuellen Beschriftungen von Formularfeldern in ihren Sprachbefehlen. Enthält der barrierefreie Name diese Beschriftung nicht vollständig, kann das Formularfeld unter Umständen nicht per Spracheingabe bedient werden. Die vollständige Übernahme der visuellen Beschriftung in den barrierefreien Namen stellt sicher, dass Formularfelder zuverlässig per Spracheingabe bedient werden können.

Typische Fehler

Für mehrere Formularfelder wurde als barrierefreier Name lediglich „Formularfeld“ hinterlegt. Da der barrierefreie Name nicht der visuellen Beschriftung entspricht, können die Formularfelder auch nicht über deren sichtbare Beschriftung per Spracheingabe bedient werden.
Als barrierefreier Name eines Formularfeldes wurde ein interner Feldname wie „txtName“, „Field1“ oder „Kunde_01“ verwendet. Der barrierefreie Name enthält dadurch nicht die sichtbare Beschriftung des Formularfeldes und kann nicht über Spracheingaben angesprochen werden.
Die visuelle Beschriftung eines Formularfeldes lautet „Telefonnummer“, als barrierefreier Name wurde jedoch lediglich „Telefon“ hinterlegt. Da die sichtbare Beschriftung nicht vollständig im barrierefreien Namen enthalten ist, kann das Formularfeld unter Umständen nicht zuverlässig per Spracheingabe angesprochen werden.

Prüfung in PAC

Fenster „Screenreader-Vorschau“ öffnen
(Dort werden alle getaggten Formularfelder mit ihren jeweils definierten barrierefreien Namen angezeigt.)

Tipp

Enthält der barrierefreie Name zusätzliche Informationen, sollte der Text der visuellen Beschriftung vollständig und möglichst am Anfang des barrierefreien Namens stehen. Beispielsweise kann für ein schreibgeschütztes Formularfeld mit der visuellen Beschriftung „Unterschrift“ der barrierefreie Name „Unterschrift (bitte handschriftlich unterzeichnen)“ verwendet werden.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	–
Matterhorn 1.1	–
EN 301 549	10.2.5.3 (basiert auf WCAG 2.2 SC 2.5.3)

Originalanforderungen

WCAG 2.2 (EN): „For user interface components with labels that include text or images of text, the name contains the text that is presented visually.“

Seltene relevante Prüfpunkte

Prüfaufwand: 🟢 Gering
Häufigkeit: Hoch

Für die Auszeichnung der Dokumentstruktur stehen in PDFs vordefinierte Standard-Tags zur Verfügung (z. B.  für Absätze, <H1> für Überschriften erster Ebene, <BlockQuote> für Zitate, usw.). Darüber hinaus können auch benutzerdefinierte Tags verwendet werden. Diese müssen jedoch über eine sogenannte Rollenzuordnung (Role Map) jeweils einem vordefinierten Standard-Tag zugeordnet werden, damit assistive Technologien ihre Bedeutung korrekt interpretieren können.

Eine maschinelle Prüfung erkennt bereits, ob benutzerdefinierte Tags einem Standard-Tag zugeordnet sind. Sie kann jedoch nicht beurteilen, ob die gewählte Rollenzuordnung auch semantisch korrekt ist. Deshalb muss manuell sichergestellt werden, dass benutzerdefinierte Tags einer semantisch passenden Standardrolle zugeordnet sind.

Autorenprogramme erzeugen für Formatvorlagen (auch Absatzformate genannt) häufig benutzerdefinierte Tags. Deren Name entspricht dabei meist dem Namen der jeweiligen Formatvorlage. Für diese benutzerdefinierten Tags erstellen die Programme in der Regel zusätzlich auch eine Rollenzuordnung auf eines der vordefinierten Tags. Ob diese Rollenzuordnung semantisch korrekt ist, muss manuell geprüft werden.

Bedeutung für die Barrierefreiheit

Assistive Technologien können nur die in den Normen vordefinierten Standard-Tags interpretieren. Benutzerdefinierte Tags werden daher erst durch eine semantisch korrekte Rollenzuordnung verständlich. Ist das zugeordnete Standard-Tag falsch gewählt, wird die Bedeutung des Inhalts-Elements falsch vermittelt.

Typische Fehler

In Adobe InDesign wurde für Zitate ein eigenes Absatzformat erstellt. Für jedes Absatzformat erzeugt InDesign beim PDF-Export ein benutzerdefiniertes Tag. Im Absatzformat kann zwar festgelegt werden, welchem Standard-Tag dieses benutzerdefinierte Tag zugeordnet werden soll, jedoch stehen dort nur wenige Standard-Tags zur Auswahl. Da das semantisch korrekte Tag <BlockQuote> nicht verfügbar war, wurde die Einstellung „[Automatisch]“ beibehalten. Dadurch ordnet InDesign beim PDF-Export das benutzerdefinierte Tag automatisch dem Tag  zu, obwohl diese Rollenzuordnung semantisch falsch ist.
In Microsoft Word wurde für Zitate eine eigene Formatvorlage anstelle der integrierten Formatvorlage „Zitat“ erstellt. Für jede eigene Formatvorlage erzeugt Word beim PDF-Export ein benutzerdefiniertes Tag für welches keine Rollenzuordnung zu einem Standard-Tag festgelegt werden kann. Dadurch ordnet Word beim PDF-Export das benutzerdefinierte Tag automatisch dem Tag  zu, obwohl diese Rollenzuordnung semantisch falsch ist.

Prüfung in PAC

Fenster „Logische Struktur“ öffnen
Reiter „Rollenzuordnungen“ aktivieren

Tipp

Verwenden Sie nach Möglichkeit Werkzeuge, mit denen sich für jede Formatvorlage das Export-Tag bzw. die Rollenzuordnung gezielt festlegen lässt. Geeignete Erweiterungen wie axesWord oder MadeToTag bieten hierfür deutlich mehr Möglichkeiten als die Standardfunktionen der Autorenprogramme und unterstützen eine semantisch korrekte Tag-Struktur.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.1-3
Matterhorn 1.1	02-002
EN 301 549	10.1.3.1 (basiert auf WCAG 2.2 SC 1.3.1)

Originalanforderungen

PDF/UA-1 (EN): „Non-standard structure types are permitted. However, they shall be mapped to the nearest functionally equivalent standard type, as defined in ISO 32000-1:2008, 14.8.4, in the role map dictionary of the structure tree root. This mapping may be indirect; within the role map a non-standard type can map directly to another non-standard type, but eventually the mapping shall terminate at a standard type.“
PDF/UA-1 (DE): „Nicht vordefinierte Strukturtypen sind zulässig. Sie müssen jedoch nach Festlegung in ISO 32000-1:2008, 14.8.4, demjenigen vordefinierten Strukturtyp im Rollen-Zuweisungs-Dictionary der Wurzel des Strukturbaums zugewiesen werden, der ihnen funktionell am nächsten kommt. Diese Zuweisung darf indirekt erfolgen. So kann innerhalb der Rollen-Zuweisung ein nicht vordefinierter Strukturtyp direkt einem weiteren nicht vordefinierten Strukturtyp zugewiesen werden, aber letztlich muss die Zuweisung bei einem vordefinierten Strukturtyp enden.“
Matterhorn 1.1 (EN): „The mapping of one or more non-standard types is semantically inappropriate.“
Matterhorn 1.1 (DE): „Die Zuordnung mindestens eines nicht vordefinierten Strukturtyps ist semantisch nicht geeignet.“
WCAG 2.2 (EN): „Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.“

Prüfaufwand: 🟡 Mittel
Häufigkeit: Gering

Interaktive Formularfelder wie Schaltflächen können auf verschiedene Mausereignisse reagieren. Für die Barrierefreiheit darf die zugehörige Aktion erst beim Loslassen der Maustaste (Mouse-Up-Event) ausgelöst werden. Wird die Aktion bereits beim Drücken der Maustaste (Mouse-Down-Event) ausgeführt, kann sie nicht mehr abgebrochen werden (indem der Mauszeiger beispielsweise vor dem Loslassen von der Schaltfläche wegbewegt wird).

Bedeutung für die Barrierefreiheit

Wird eine Formular-Aktion erst beim Loslassen der Maustaste ausgelöst, kann die Aktion vor ihrer Ausführung noch abgebrochen werden, indem der Mauszeiger von dem interaktiven Element wegbewegt wird. Dadurch lassen sich unbeabsichtigte Eingaben oder Aktionen vermeiden und die Bedienung von Formularen wird fehlertoleranter.

Typische Fehler

Die Aktion einer Schaltfläche wurde dem Mouse-Down-Event zugeordnet. Dadurch wird die Aktion bereits beim Drücken der Maustaste ausgelöst und kann nicht mehr abgebrochen werden, indem der Mauszeiger vor dem Loslassen von der Schaltfläche wegbewegt wird.
Die Aktion einer Schaltfläche wurde dem Mouse-Enter-Event zugeordnet. Dadurch wird die Aktion bereits ausgelöst, sobald der Mauszeiger über die Schaltfläche bewegt wird, ohne dass diese angeklickt werden muss. Dies kann zu unbeabsichtigten und vollkommen unvorhersehbaren Aktionen führen.

Prüfung in PAC

Eine Prüfung in PAC ist nicht möglich. Stattdessen müssen geeignete PDF-Editoren verwendet werden, mit denen sich die für Formularfelder definierten Aktionen und deren Auslöser (Trigger) anzeigen lassen. Browserbasierte PDF-Viewer eignen sich hierfür in der Regel nicht, da sie Formularskripte und Aktionen häufig nur eingeschränkt oder gar nicht unterstützen. Eine reine Funktionsprüfung aus Nutzersicht ist ebenfalls nicht ausreichend, da sich daraus nicht zuverlässig erkennen lässt, welchem Ereignis die jeweilige Formular-Aktion zugeordnet ist.

Tipp

Werden Formulare in gängigen PDF-Editoren erstellt, werden Aktionen in der Regel bereits standardmäßig dem Mouse-Up-Event (Maustaste loslassen) zugeordnet. Eine manuelle Änderung des Auslösers ist daher meist nicht erforderlich.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1
Matterhorn 1.1
EN 301 549	10.2.5.2 (basiert auf WCAG 2.2 SC 2.5.2)

Originalanforderungen

WCAG 2.2 (EN): „[…] The down-event of the pointer is not used to execute any part of the function; […] Completion of the function is on the up-event […]“

Prüfaufwand: 🟡 Mittel
Häufigkeit: Gering

Neben interaktiven Formularfeldern gibt es auch nicht-interaktive Formularfelder. Diese entstehen beispielsweise, wenn ein PDF nachträglich „geflattened“ wird, also die Interaktivität der Formularfelder entfernt wird. Dies entspricht vereinfacht einem digitalen Drucken und wird häufig eingesetzt, um ausgefüllte Formulare vor weiteren Änderungen zu schützen. Durch das Entfernen der Interaktivität gehen jedoch auch die technischen Informationen des ursprünglichen Formularfelds verloren. Hierzu gehören beispielsweise die Art des Formularfelds (z. B. Textfeld, Kontrollkästchen, Optionsfeld oder Schaltfläche), der Auswahlstatus von Kontrollkästchen und Optionsfeldern sowie der barrierefrei zugängliche Name des Formularfelds.

Aus diesem Grund müssen für Form-Tags nicht-interaktiver Formularfelder zusätzlich die (korrekten) PrintField-Attribute definiert werden.

Der Role-Eintrag beschreibt die ursprüngliche Art des Formularfelds. Hierfür stehen vier Werte zur Verfügung:

tv für Felder mit Textinhalt
cb für Kontrollkästchen
rb für Optionsfelder
pb für Schaltflächen

Die ursprüngliche Art eines textbasierten Formularfelds (z. B. Textfeld, Kombinationsfeld oder Listenfeld) spielt dabei keine Rolle und wird stets mit tv angegeben.

Für Kontrollkästchen und Optionsfelder soll zusätzlich über den checked-Eintrag (on, off oder neutral) der Auswahlstatus angegeben werden.

Der Desc-Eintrag dient zur Hinterlegung einer barrierefrei zugänglichen Feldbezeichnung und entspricht in seiner Funktion dem TU-Eintrag (in der Praxis auch bekannt als QuickInfo oder ToolTip) interaktiver Formularfelder.

Bedeutung für die Barrierefreiheit

Sind nicht-interaktive Formularfelder mit einem Form-Tag ohne PrintField-Attribute ausgezeichnet, fehlt assistiven Technologien die Information über die Art der Formularfelder, wie deren barrierefrei zugänglicher Name lautet und bei Auswahlfeldern auch, ob diese aktiviert sind oder nicht.

Typische Fehler

Ein nicht-interaktives Formularfeld wurde zwar korrekt mit einem Form-Tag ausgezeichnet. Aus Unwissenheit oder aufgrund der nur eingeschränkten Möglichkeiten zur Bearbeitung von PDF-Attributen wurden jedoch keine PrintField-Attribute ergänzt. Dadurch fehlen assistiven Technologien relevante Informationen zum Formularfeld.
Bei einem nicht-interaktiven Formularfeld wurden die PrintField-Attribute zwar ergänzt, der Role-Eintrag beschreibt jedoch einen falschen Formularfeldtyp (z. B. „tv“ statt „cb“). Dadurch wird das Formularfeld von assistiven Technologien als falscher Feldtyp interpretiert.
Bei einem nicht-interaktiven angekreuzten Kontrollkästchen wurde der Role-Eintrag zwar korrekt auf cb, der checked-Eintrag jedoch nicht auf on gesetzt. Dadurch wird das Kontrollkästchen nicht als angekreuzt erkannt.

Prüfung in PAC

Fenster „Logische Struktur“ öffnen
Reiter „Strukturelemente“ und „Seitenansicht“ aktivieren
Relevantes Form-Tag finden und auswählen
Reiter „Eigenschaften“ aktivieren
(Sofern PrintField-Attribute vorhanden sind, werden sie hier angezeigt.)

Tipp

Das korrekte Tagging nicht-interaktiver Formularfelder erfordert deutlich tiefere Kenntnisse der PDF-Struktur als das Tagging interaktiver Formularfelder. Stehen diese Kenntnisse intern nicht zur Verfügung, sollte die Umsetzung oder Prüfung durch entsprechend spezialisierte Fachpersonen erfolgen.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.14-1
Matterhorn 1.1	24-001
EN 301 549	10.1.3.1 (basiert auf WCAG 2.2 SC 1.3.1) 10.4.1.2 (basiert auf WCAG 2.2 SC 4.1.2)

Originalanforderungen

PDF/UA-1 (EN): „Non-interactive forms shall be tagged using the PrintField attributes, as defined in ISO 32000-1:2008, 14.8.5.6.“
PDF/UA-1 (DE): „Nicht-interaktive Formulare müssen nach Festlegung in ISO 32000-1:2008, 14.8.5.6, unter Verwendung der PrintField-Attribute getaggt werden.“
Matterhorn 1.1 (EN): „Non-interactive forms are not tagged with the PrintFields attribute.“
Matterhorn 1.1 (DE): „Nicht interaktive Formularfelder sind nicht mit dem Attribut PrintField getaggt.“
WCAG 2.2 (EN):
- „Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.“
- „For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined […]“

Prüfaufwand: 🟢 Gering
Häufigkeit: Gering

Grafiken von reinem Text müssen in echten Text umgewandelt werden. Dies gilt beispielsweise für Scans oder Screenshots von Textabschnitten, die als Bild in das Dokument eingefügt wurden. Bewusst grafisch gestaltete Texte (z. B. grafische Überschriften, die in Adobe Illustrator als Pfade erstellt wurden) dürfen dagegen als Grafik erhalten bleiben (benötigen dann jedoch einen Ersatztext).

Bedeutung für die Barrierefreiheit

Echter Text kann in vielen Softwares an individuelle Bedürfnisse angepasst werden. So lassen sich beispielsweise Schriftgröße, Schriftart, Farben oder Kontraste verändern. Bilder von Text bieten diese Anpassungsmöglichkeiten nicht und können dadurch die Zugänglichkeit des Dokuments einschränken.

Typische Fehler

Für ein neues Quelldokument wurden Inhalte aus einem physischen Dokument benötigt. Anstatt den Text abzutippen oder einen Scan per OCR-Texterkennung in echten Text umzuwandeln und gegebenenfalls zu korrigieren, wurden die relevanten Stellen lediglich eingescannt und als Bilder in das Quelldokument eingefügt.
Ein Textausschnitt wurde in einem anderen Dateiformat erstellt und im Gesamtdokument als verknüpftes Element eingebunden. Aufgrund falscher Einstellungen wurde das verknüpfte Element beim PDF-Export als Bild übernommen, obwohl sein Inhalt im Ursprungsdokument als echter Text vorliegt.

Prüfung in PAC

Fenster „Screenreader-Vorschau“ öffnen
(Sofern Texte als Bilder in das Dokument eingefügt wurden, werden diese innerhalb von Figure-Tags angezeigt.)

Tipp

Texte sollten möglichst immer direkt im Autorenprogramm erstellt werden. Müssen Inhalte aus anderen Quellen übernommen werden, sollte vorhandener Text kopiert oder Scans zunächst per OCR-Texterkennung in echten Text umgewandelt und korrigiert werden.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.3-6
Matterhorn 1.1	13-007
EN 301 549	10.1.4.5 (basiert auf WCAG 2.2 SC 1.4.5)

Originalanforderungen

PDF/UA-1 (EN): „When a more accessible representation exists, the more accessible representation should be used instead of a graphic.“
PDF/UA-1 (DE): „Wenn eine zugänglichere Repräsentation vorhanden ist, sollte diese anstelle einer Grafik verwendet werden.“
Matterhorn 1.1 (EN): „A more accessible representation is not used.“
Matterhorn 1.1 (DE): „Eine Repräsentationsform, die eine bessere Zugänglichkeit ermöglicht, wird nicht verwendet.“
WCAG 2.2 (EN): „If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text […]“

Prüfaufwand: 🔴 Hoch
Häufigkeit: Gering

Bei pixelbasierten Textinhalten (z. B. eingescanntes Dokument) kann mithilfe einer Texterkennung (Optical Character Recognition, OCR) maschinenlesbarer Text erzeugt werden. Dabei können Zeichen, Wörter oder ganze Textpassagen fehlerhaft erkannt oder ausgelassen werden. Der durch die OCR erzeugte Text muss daher überprüft und gegebenenfalls korrigiert werden, sodass er dem tatsächlichen Inhalt des Dokuments entspricht.

Bedeutung für die Barrierefreiheit

Assistive Technologien geben sämtliche getaggten Inhalte eines Dokuments aus, darunter auch den durch die OCR erzeugten Text. Enthält dieser Text Fehler oder fehlen Textbestandteile, wird auch der Inhalt des Dokuments fehlerhaft oder unvollständig vermittelt.

Typische Fehler

Ein eingescanntes Dokument wurde mithilfe einer Texterkennung (OCR) verarbeitet. Da der erzeugte Text nicht überprüft und korrigiert wurde, enthält das PDF fehlerhafte Textstellen.

Prüfung in PAC

Fenster „Screenreader-Vorschau“ öffnen
(Sofern OCR-generierter Text vorhanden und getaggt ist, wird dieser anstelle der gescannten Seiten angezeigt und kann dort korrekturgelesen werden.)

Tipp

Nutzen Sie vorhandene Prüfmechanismen der OCR-Software. Viele Programme markieren Wörter oder Zeichen, bei denen die Texterkennung unsicher war. Prüfen Sie diese Stellen besonders sorgfältig, bevor Sie das PDF weiterverwenden.

Verfügt die OCR-Software über keine integrierte Rechtschreib- oder Grammatikprüfung, kann es sinnvoll sein, den erkannten Text vorübergehend in ein Textverarbeitungsprogramm wie Microsoft Word zu übernehmen. Die dort verfügbaren Rechtschreib- und Grammatikfunktionen helfen dabei, fehlerhaft erkannte Stellen schneller zu finden.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.1-10
Matterhorn 1.1	08-001
EN 301 549	10.1.4.5 (basiert auf WCAG 2.2 SC 1.4.5)

Originalanforderungen

PDF/UA-1 (EN): „Documents consisting of raster-based images may be processed to generate machine-readable content. In such cases, errors resulting from the content-generation process shall be corrected […]“
PDF/UA-1 (DE): „Dokumente, die aus pixelbasierten Bildern bestehen, können so verarbeitet werden, dass maschinenlesbarer Inhalt generiert wird. In solchen Fällen müssen während des Inhalts-Generierungs-Prozesses entstandene Fehler korrigiert werden […]“
Matterhorn 1.1 (EN): „OCR-generated text contains significant errors.“
Matterhorn 1.1 (DE): „Text, der über OCR erstellt wurde, enthält erhebliche Fehler.“
WCAG 2.2 (EN): „If the technologies being used can achieve the visual presentation, text is used to convey information rather than images of text […]“

Prüfaufwand: 🔴 Hoch
Häufigkeit: Extrem selten

In einem „normalen“ PDF sind in der Regel keine Zeichen vorhanden, die aus mehreren Glyphen zusammengesetzt sind, sodass dieser Prüfschritt in der Praxis nur selten relevant ist.
Derartige Konstruktionen finden sich heute fast nur noch in sehr alten PDF-Dokumenten. Dort wurden einzelne Zeichen teilweise aus mehreren Glyphen zusammengesetzt, obwohl sie gemeinsam nur ein einziges Zeichen darstellen. Dies betrifft beispielsweise besonders große Klammern in mathematischen Formeln. Obwohl sie technisch aus mehreren Glyphen bestehen, bilden sie gemeinsam nur ein einziges Zeichen. Für diese Glyphen muss daher dann ein gemeinsamer Ersatztext hinterlegt sein.

Bedeutung für die Barrierefreiheit

Besteht ein einzelnes Zeichen technisch aus mehreren Glyphen und ist kein Ersatztext vorhanden, so würden assistive Technologien die einzelnen Glyphen separat oder gar nicht sinnvoll ausgeben. Der Ersatztext stellt sicher, dass das zusammengesetzte Zeichen als ein einziges Zeichen erkannt und korrekt wiedergegeben wird.

Typische Fehler

In der Praxis treten Fehler in diesem Bereich heute kaum noch auf, da moderne Autorenprogramme solche Zeichen in der Regel korrekt erzeugen. Beispielsweise passt der Formeleditor in Microsoft Word die Größe einer Klammer automatisch an den eingeschlossenen Inhalt an und erzeugt sie dabei als einzelnes Zeichen.

Prüfung in PAC

Fenster „Screenreader-Vorschau“ öffnen
(Sofern ein Zeichen aus mehreren Glyphen besteht und kein passender Ersatztext vorhanden ist, werden in der Screenreader-Vorschau die einzelnen Glyphen separat angezeigt.)

Tipp

Verwenden Sie für mathematische Zeichen und andere Sonderzeichen möglichst die dafür vorgesehenen Unicode-Zeichen oder Funktionen des Autorenprogramms. Verzichten Sie auch darauf, ein einzelnes Zeichen durch die Kombination mehrerer Glyphen nachzubilden (verwenden Sie z. B. → statt =>).

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.2-4
Matterhorn 1.1	12-001
EN 301 549	10.1.3.1 (basiert auf WCAG 2.2 SC 1.3.1)

Originalanforderungen

PDF/UA-1 (EN): „Stretchable characters such as parentheses or brackets (often drawn by combining several individual glyphs to form the appearance of a single glyph) shall be tagged using ActualText, as specified in ISO 32000-1:2008, 14.9.4.“
PDF/UA-1 (DE): „Streckbare Zeichen wie runde oder eckige Klammern (die oft eine Kombination mehrerer einzelner Glyphen sind, welche aussieht wie eine einzige Glyphe) müssen mit ActualText getaggt werden, wie in ISO 32000-1:2008, 14.9.4, festgelegt.“
Matterhorn 1.1 (EN): „Stretched characters are not represented appropriately.“
Matterhorn 1.1 (DE): „Streckbare Zeichen sind nicht in geeigneter Form repräsentiert.“
WCAG 2.2 (EN): „Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.“

Prüfaufwand: 🔴 Hoch
Häufigkeit: Extrem selten

Damit ein PDF auf jedem Gerät korrekt dargestellt werden kann, werden beim PDF-Export alle verwendeten Zeichen der genutzten Schriftarten in das Dokument eingebettet. Dadurch können Texte auch dann korrekt angezeigt werden, wenn die verwendete Schrift auf einem Gerät nicht installiert ist. Ob die erforderlichen Schriftdaten vollständig eingebettet wurden, wird bereits im Rahmen der maschinellen Prüfung überprüft.
Dieser Prüfschritt stellt sicher, dass die verwendeten Schriftarten entsprechend ihrer Lizenzbedingungen rechtmäßig in ein PDF eingebettet werden dürfen.

Bedeutung für die Barrierefreiheit

Dieses Prüfkriterium hat keinen direkten Einfluss auf die Barrierefreiheit eines PDF-Dokuments. Es soll vielmehr sicherstellen, dass bei der Erstellung barrierefreier PDFs nur Schriftarten verwendet werden, deren Einbettung rechtlich zulässig ist. Da sich die tatsächliche Rechtslage anhand des PDF-Dokuments allein meist nicht zuverlässig beurteilen lässt, spielt dieses Prüfkriterium bei der praktischen Prüfung häufig nur eine untergeordnete Rolle. Stattdessen sollte bereits während der Dokumenterstellung auf geeignete Schriftlizenzen geachtet werden.

Typische Fehler

In der Praxis treten zu diesem Prüfkriterium nur äußerst selten Fehler auf.
Die meisten Organisationen verwenden etablierte Schriftarten mit unproblematischen Lizenzbedingungen (z. B. Arial) oder unternehmenseigene Schriftarten, für die die erforderlichen Einbettungsrechte in der Regel bereits berücksichtigt wurden. Bestehen dennoch Zweifel an den verwendeten Schriftlizenzen, sollte der Auftraggeber oder Autor darauf hingewiesen werden.

Prüfung in PAC

Eine Prüfung in PAC ist nicht möglich. Stattdessen müssen die Lizenzbedingungen der verwendeten Schriftarten geprüft werden. Diese müssen die Einbettung der Schrift zur Darstellung erlauben.

Hinweis: Einige Schriftdateien enthalten einen maschinenlesbaren Parameter, der die erlaubten Einbettungsrechte beschreibt (z. B. Installable, Editable, Preview & Print oder Restricted Embedding). Dieser kann einen ersten Hinweis geben, ersetzt jedoch nicht die Prüfung der tatsächlichen Lizenzbedingungen.

Tipp

Die Prüfung der Schriftlizenzen sollte nach Möglichkeit bereits vor der Dokumenterstellung erfolgen. Werden während der Dokumenterstellung ausschließlich Schriftarten verwendet, deren Einbettung lizenzrechtlich geklärt ist, spielt dieses Prüfkriterium bei der späteren PDF-Prüfung in der Regel keine Rolle mehr.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.21.4.1-2
Matterhorn 1.1	31-010
EN 301 549	–

Originalanforderungen

PDF/UA-1 (EN): „Only font programs that are legally embeddable in a file for unlimited, universal rendering shall be used.“
PDF/UA-1 (DE): „Es dürfen nur Schriftprogramme verwendet werden, deren Einbettung in eine Datei zur uneingeschränkten, universellen Darstellung keine rechtlichen Gründe entgegenstehen.“
Matterhorn 1.1 (EN): „A font program is embedded that is not legally embeddable for unlimited, universal rendering.“
Matterhorn 1.1 (DE): „Ein Schriftprogramm, das aus rechtlichen Gründen nicht für eine uneingeschränkte, universelle Darstellung eingebettet werden kann, ist eingebettet.“

Prüfaufwand: 🟢 Gering
Häufigkeit: Extrem selten

In einem „normalen“ PDF sind in der Regel keine Audio- oder Videoinhalte (zeitbasierte Medien) vorhanden, sodass dieser Prüfschritt in der Praxis nur selten relevant ist.
Enthält ein PDF dennoch Audio- oder Videoinhalte, müssen die dadurch vermittelten Informationen auch in einer anderen Form verfügbar sein. Je nach Art des Mediums kommen dafür unterschiedliche Alternativen in Betracht. Für reine Audioinhalte ist beispielsweise ein Transkript erforderlich. Reine Videoinhalte benötigen eine textliche oder akustische Alternative, welche die wesentlichen visuellen Informationen beschreibt. Bei Videos mit Ton sind zusätzlich Untertitel für die gesprochenen Inhalte und gegebenenfalls eine Audiodeskription erforderlich. Akustische Signale (z. B. Benachrichtigungstöne) müssen außerdem durch eine gleichwertige visuelle oder textliche Information ergänzt werden.

Bedeutung für die Barrierefreiheit

Audio- und Videoinhalte sind nicht unmittelbar maschinell auswertbar. Die darin enthaltenen Informationen stehen daher zunächst nur über den Hörsinn oder den Sehsinn zur Verfügung und sind ohne geeignete Alternativen nicht universell zugänglich. Transkripte, Untertitel, Audiodeskriptionen oder andere gleichwertige Alternativen stellen sicher, dass diese Informationen unabhängig vom verwendeten Sinnesorgan zugänglich sind.

Typische Fehler

In ein PDF wurden Audio- oder Videoinhalte eingebettet. Die dafür erforderlichen Alternativen wurden jedoch nicht bereitgestellt. Dadurch sind die darin enthaltenen Informationen nicht für alle Nutzenden zugänglich.

Prüfung in PAC

Eine Prüfung in PAC ist nicht möglich. Stattdessen sollte das PDF in einem geeigneten PDF-Viewer geöffnet und vorhandene Audio- oder Videoinhalte dort abgespielt werden. Anschließend ist zu prüfen, ob für die jeweiligen Medien geeignete Alternativen vorhanden sind und diese sämtliche relevanten Informationen des Audio- oder Videoinhalts wiedergeben.

Tipp

Zeitbasierte Medien lassen sich im Web in der Regel besser barrierefrei bereitstellen als in PDF-Dokumenten. Erwägen Sie daher, Audio- und Videoinhalte nicht direkt in das PDF einzubetten, sondern auf entsprechende Inhalte im Web zu verlinken. Dort stehen häufig spezialisierte Medienplayer zur Verfügung, die beispielsweise Untertitel, Audiodeskriptionen oder weitere Bedienungshilfen unterstützen. Nutzende können diese Funktionen bei Bedarf selbst aktivieren oder an ihre individuellen Anforderungen anpassen.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.1-7
Matterhorn 1.1	05-001, 05-002, 05-003
EN 301 549	10.1.1.1 (basiert auf WCAG 2.2 SC 1.1.1) 10.1.2.1 (basiert auf WCAG 2.2 SC 1.2.1) 10.1.2.2 (basiert auf WCAG 2.2 SC 1.2.2) 10.1.2.3 (basiert auf WCAG 2.2 SC 1.2.3) 10.1.2.5 (basiert auf WCAG 2.2 SC 1.2.5)

Originalanforderungen

PDF/UA-1 (EN): „All information conveyed with sound should also be available without sound.“
PDF/UA-1 (DE): „Alle per Ton übermittelten Informationen sollten auch ohne Ton verfügbar sein.“
Matterhorn 1.1 (EN):
- „Media annotation present, but audio content not available in another form.“
- „Audio annotation present, but content not available in another form.“
- „JavaScript uses beep function but does not provide another means of notification.“
Matterhorn 1.1 (DE):
- „Medien-Annotationen sind vorhanden, die per Ton übermittelten Informationen sind jedoch nicht in einer anderen Form verfügbar.“
- „Audio-Annotationen sind vorhanden, aber die Informationen sind nicht in einer anderen Form verfügbar.“
- „JavaScript verwendet ein Tonsignal, liefert aber keine alternative Form der Benachrichtigung.“
WCAG 2.2 (EN):
- „All non-text content that is presented to the user has a text alternative that serves the equivalent purpose […]“
- „For prerecorded audio-only and prerecorded video-only media, the following are true, except when the audio or video is a media alternative for text and is clearly labeled as such […]“
- „Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such.“
- „An alternative for time-based media or audio description of the prerecorded video content is provided for synchronized media, except when the media is a media alternative for text and is clearly labeled as such.“
- „Audio description is provided for all prerecorded video content in synchronized media.“

Prüfaufwand: 🟡 Mittel
Häufigkeit: Extrem selten

In einem „normalen“ PDF sind in der Regel keine Inhalte vorhanden, die visuelles Flimmern verursachen, sodass dieser Prüfschritt in der Praxis nur selten relevant ist.
Enthält ein PDF interaktive Inhalte (z. B. JavaScript, Aktionen oder eingebettete Videoinhalte), muss sichergestellt werden, dass dadurch keine visuellen Effekte entstehen, die flimmern, blinken oder blitzen.

Bedeutung für die Barrierefreiheit

Flimmernde, blinkende oder blitzende Inhalte können bei empfindlichen Personen gesundheitliche Beschwerden bis hin zu epileptischen Anfällen auslösen. Der Verzicht auf solche visuellen Effekte trägt dazu bei, dass PDF-Dokumente sicher und ohne gesundheitliche Risiken genutzt werden können.

Typische Fehler

In der Praxis treten zu diesem Prüfkriterium nur äußerst selten Fehler auf.
Die meisten PDF-Dokumente enthalten keine interaktiven Inhalte oder Multimedia-Inhalte und erfüllen diese Anforderung daher automatisch

Prüfung in PAC

Eine Prüfung in PAC ist nicht möglich. Stattdessen sollte das PDF in einem geeigneten PDF-Viewer geöffnet und vorhandene interaktive Inhalte ausgeführt werden. Anschließend ist zu prüfen, ob dabei flimmernde, blinkende oder blitzende visuelle Effekte entstehen. Browserbasierte PDF-Viewer eignen sich für die Prüfung in der Regel nicht, da sie interaktive Inhalte häufig nur eingeschränkt oder gar nicht unterstützen.

Tipp

Werden interaktive Inhalte oder Multimedia-Inhalte verwendet, sollten blinkende oder flimmernde Effekte grundsätzlich vermieden werden. Ruhige Übergänge oder statische Darstellungen sind in der Regel die bessere Wahl.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.1-5
Matterhorn 1.1	03-001, 03-002, 03-003
EN 301 549	10.2.3.1 (basiert auf WCAG 2.2 SC 2.3.1)

Originalanforderungen

PDF/UA-1 (EN): „Flickering, blinking, or flashing shall not be used (WCAG 2.0, Guideline 2.3).“
PDF/UA-1 (DE): „Flimmer-, Blink- oder Blitzeffekte dürfen nicht verwendet werden (WCAG 2.0, Richtlinie 2.3).“
Matterhorn 1.1 (EN):
- „One or more Actions lead to flickering.“
- „One or more multimedia objects contain flickering content.“
- „One or more JavaScript actions lead to flickering.“
Matterhorn 1.1 (DE):
- „Mindestens eine Aktion führt zu Flimmer-, Blink- oder Blitzeffekten.“
- „Mindestens ein Multimedia-Objekt enthält Inhalt, der flimmert, blinkt oder blitzt.“
- „Mindestens eine JavaScript-Aktion führt zu Flimmer-, Blink- oder Blitzeffekten.“
WCAG 2.2 (EN): „Web pages do not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.“

Prüfaufwand: 🔴 Hoch
Häufigkeit: Extrem selten

In einem „normalen“ PDF werden in der Regel keine Links mit IsMap-Eintrag verwendet, sodass dieser Prüfschritt in der Praxis nur selten relevant ist.
Bei einem Link mit IsMap-Eintrag wird nicht nur eine feste URL aufgerufen, sondern zusätzlich die Position des Mausklicks an den Webserver übermittelt. Der Webserver wertet diese Position aus und entscheidet anschließend, welches Ziel geöffnet werden soll. Dadurch kann derselbe Link – je nachdem, an welcher Stelle geklickt wurde – unterschiedliche Ziele aufrufen. Dies wird beispielsweise verwendet, wenn ein Klick auf verschiedene Bereiche einer Landkarte zu unterschiedlichen Webseiten führen soll. Für Nutzende, die diese Funktion nicht verwenden können, muss dieselbe Funktion zusätzlich auf andere Weise erreichbar sein (z. B. über eine separate Linkliste), die sämtliche Ziele abdeckt.

Bedeutung für die Barrierefreiheit

Serverseitige Image Maps machen die Funktion eines Links von der genauen Position des Mausklicks abhängig. Nutzende, die keinen Mauszeiger verwenden oder die gewünschte Position nicht gezielt auswählen können, können dadurch bestimmte Linkziele nicht erreichen. Eine gleichwertige Alternative stellt sicher, dass alle Ziele auch ohne IsMap-Funktion erreichbar sind.

Typische Fehler

In der Praxis treten zu diesem Prüfkriterium nur äußerst selten Fehler auf.
Serverseitige Image Maps werden in modernen PDF-Dokumenten kaum noch verwendet. Werden sie dennoch eingesetzt, wird häufig übersehen, eine gleichwertige Alternative bereitzustellen. Dadurch können einzelne Linkziele für bestimmte Nutzende unzugänglich sein.

Prüfung in PAC

Eine Prüfung in PAC ist nicht möglich. Selbst PDF-Editoren können lediglich anzeigen, ob ein Link die IsMap-Funktion verwendet. Anhand des PDF-Dokuments allein lässt sich jedoch nicht beurteilen, welche verschiedenen Linkziele darüber erreicht werden können. Hierfür ist eine Rücksprache mit dem Betreiber des Webservers erforderlich, damit dieser die möglichen Linkziele nennt. Erst anschließend kann geprüft werden, ob sämtliche Linkziele auch über alternative Wege im PDF erreichbar sind.

Tipp

Links mit IsMap-Eintrag sollten grundsätzlich vermieden werden. In den meisten Fällen lassen sich dieselben Funktionen auch ohne IsMap umsetzen.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.18.5-3
Matterhorn 1.1	28-013
EN 301 549	10.1.1.1 (basiert auf WCAG 2.2 SC 1.1.1) 10.2.4.4 (basiert auf WCAG 2.2 SC 2.4.4)

Originalanforderungen

PDF/UA-1 (EN): „The IsMap key shall not be present with a value of true in the URI action dictionary (ISO 32000-1:2008, 12.6.4.7) unless its functionality is also provided in an equivalent manner elsewhere in the content without using an IsMap key.“
PDF/UA-1 (DE): „Der IsMap-Schlüssel darf im „URI-action“-Dictionary nicht den Wert true haben (ISO 32000-1:2008, 12.6.4.7), sofern seine Funktion nicht auch in gleicher Weise an einer anderen Stelle im Inhalt ohne Verwendung eines IsMap-Schlüssels bereitgestellt wird.“
Matterhorn 1.1 (EN): „An IsMap entry is present with a value of true but the functionality is not provided in some other way.“
Matterhorn 1.1 (DE): „Der IsMap-Schlüssel ist vorhanden mit dem Wert true, ohne die Funktionsweise zusätzlich in alternativer Form zur Verfügung zu stellen.“
WCAG 2.2 (EN):
- „All non-text content that is presented to the user has a text alternative that serves the equivalent purpose […]“
- „The purpose of each link can be determined from the link text alone or from the link text together with its programmatically determined link context, except where the purpose of the link would be ambiguous to users in general.“

Prüfaufwand: 🔴 Hoch
Häufigkeit: Extrem selten

In einem „normalen“ PDF sind in der Regel keine Skripte vorhanden, sodass dieser Prüfschritt in der Praxis nur selten relevant ist.
PDF-Dokumente können jedoch Skripte enthalten, mit denen beispielsweise Formulareingaben überprüft oder andere Aktionen ausgelöst werden können. Werden solche Skripte verwendet und werten sie zugleich Tastatureingaben aus, dürfen sie keine bestimmten zeitlichen Vorgaben für einzelne Tastenanschläge voraussetzen.

Bedeutung für die Barrierefreiheit

Spezifische Zeitvorgaben für einzelne Tastenanschläge können Personen mit motorischen Einschränkungen (z. B. Tremor) oder alternativen Eingabemethoden von der Nutzung eines PDFs ausschließen. Tastatureingaben dürfen daher nicht von einer bestimmten Eingabegeschwindigkeit abhängen.

Beispiel

Das folgende Beispiel-PDF enthält ein Skript, das verlangt, dass die Zahlenfolge „1234“ eingegeben wird. Für jede Ziffer stehen jedoch maximal 0,5 Sekunden zur Verfügung. Da das Skript eine zeitkritische Tastatureingabe voraussetzt, ist es hinsichtlich dieses Prüfkriteriums nicht barrierefrei

Beispiel-PDF herunterladen

Typische Fehler

In der Praxis treten zu diesem Prüfkriterium nur äußerst selten Fehler auf.
Die meisten PDF-Dokumente enthalten keine Skripte und erfüllen diese Anforderung daher automatisch. Aber auch PDFs mit Skripten enthalten in der Regel keine zeitbasierten Vorgaben für Tastatureingaben.

Prüfung in PAC

Eine Prüfung in PAC ist nicht möglich. Stattdessen müssen geeignete PDF-Editoren verwendet werden, mit denen sich der Quellcode der vorhandenen Skripte anzeigen lässt. Browserbasierte PDF-Viewer eignen sich hierfür in der Regel nicht, da sie Skripte häufig nur eingeschränkt oder gar nicht unterstützen. Eine reine Funktionsprüfung aus Nutzersicht ist ebenfalls nicht ausreichend, da sich dabei nicht zuverlässig alle möglichen Tastatureingaben und Programmabläufe abdecken lassen.

Tipp

Zeitkritische Tastatureingaben sollten in PDF-Skripten grundsätzlich vermieden werden. In den meisten Fällen lassen sich dieselben Funktionen ohne zeitliche Vorgaben umsetzen.

Abgedeckte Anforderungen

Prüfgrundlage	Referenz
PDF/UA-1	7.19-3
Matterhorn 1.1	29-001
EN 301 549	10.2.1.1 (basiert auf WCAG 2.2 SC 2.1.1)

Originalanforderungen

PDF/UA-1 (EN): „A script shall not require specific timings for individual keystrokes.“
PDF/UA-1 (DE): „Ein Skript darf keine spezifischen Zeitvorgaben für bestimmte Tastenanschläge machen.“
Matterhorn 1.1 (EN): „A script requires specific timing for individual keystrokes.“
Matterhorn 1.1 (DE): „Ein Skript erfordert bestimmte Tastenanschläge innerhalb einer festgelegten zeitlichen Vorgabe.“
WCAG 2.2 (EN): „All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes […]“

Grundlagen zur Prüfung barrierefreier PDFs

Welche Anforderungen gelten bei der Prüfung eines PDFs auf Barrierefreiheit?

Welche WCAG-Erfolgskriterien sind für barrierefreie PDFs relevant

PDF/UA: Technische Anforderungen an barrierefreie PDFs

Matterhorn-Protokoll: Prüfgrundlage für barrierefreie PDFs

Welche Anforderungen müssen für die vollständige Prüfung berücksichtigt werden?

Maschinelle und manuelle Prüfung: Was ist der Unterschied?

Welche Anforderungen können maschinell und daher auch automatisiert geprüft werden?

Welche Anforderungen müssen manuell geprüft werden?

Welche Software eignet sich, um PDFs auf Barrierefreiheit zu prüfen?

PAC

veraPDF

Adobe Acrobat

Empfehlung für die praktische Prüfung

Praktische Prüfung eines PDFs auf Barrierefreiheit

Schritt 1: PDF maschinell auf Barrierefreiheit prüfen

Schritt 2: PDF manuell auf Barrierefreiheit prüfen

Titel in den Dokumenteigenschaften ist korrekt und eindeutig

Bedeutung für die Barrierefreiheit

Typische Fehler

Prüfung in PAC

Tipp

Abgedeckte Anforderungen

Dokumentsprache ist korrekt

Bedeutung für die Barrierefreiheit

Typische Fehler

Prüfung in PAC

Tipp

Abgedeckte Anforderungen

Relevante Inhalte sind im Tag-Baum vorhanden und mit semantisch passenden Tags ausgezeichnet

Bedeutung für die Barrierefreiheit

Typische Fehler

Prüfung in PAC

Tipp

Abgedeckte Anforderungen

Tags sind semantisch korrekt ineinander verschachtelt

Bedeutung für die Barrierefreiheit

Typische Fehler

Prüfung in PAC

Tipp

Abgedeckte Anforderungen

Lesereihenfolge der Tags ist korrekt

Bedeutung für die Barrierefreiheit

Typische Fehler

Prüfung in PAC

Tipp

Abgedeckte Anforderungen

Informationen werden nicht ausschließlich visuell vermittelt

Bedeutung für die Barrierefreiheit

Typische Fehler

Prüfung in PAC

Tipp

Abgedeckte Anforderungen

Für anderssprachige Textpassagen ist die korrekte Sprache hinterlegt

Bedeutung für die Barrierefreiheit

Typische Fehler

Prüfung in PAC

Tipp

Abgedeckte Anforderungen

Nicht relevante Inhalte und wiederkehrende Elemente sind als Artefakte gekennzeichnet

Bedeutung für die Barrierefreiheit

Typische Fehler

Prüfung in PAC

Tipp

Abgedeckte Anforderungen

Kopf- und Fußzeilen sind als Artefakte mit dem Typ Pagination und dem Subtyp Header bzw. Footer klassifiziert

Bedeutung für die Barrierefreiheit

Typische Fehler

Prüfung in PAC

Tipp

Abgedeckte Anforderungen

L-Tags von nummerierten Listen besitzen ein korrektes ListNumbering-Attribut

Bedeutung für die Barrierefreiheit

Typische Fehler

Prüfung in PAC

Tipp

Abgedeckte Anforderungen

Jedem TD-Tag sind alle zugehörigen TH-Tags vollständig zugeordnet

Bedeutung für die Barrierefreiheit

Typische Fehler