PDF/UA-1 unter der Lupe – Teil 8: Einfache und komplexe Datentabellen

Anforderungen an barrierefreie Datentabellen werden oft vor allem vor dem Hintergrund der rein-technischen Umsetzung betrachtet. Diese ist für Screenreader-Nutzer wichtig und essenziel, ist jedoch eine verkürzte Sicht und adressiert lediglich blinde Nutzer. Aber auch hinsichtlich technischer Anforderungen sollten Datentabellen differenziert betrachtet und zwischen einfachen und komplexen Datentabellen unterschieden werden. Andernfalls werden Datentabellen als „nicht-barrierefrei“ und das Dokument als fehlerhaft bezeichnet, obwohl es für Screenreader-Nutzer zu keinen Problemen kommt.

Zur Barrierefreiheit von Datentabellen

Datentabellen stehen nicht im redaktionell-luftleeren Raum, sondern in aller Regel in einem thematisch-inhaltlichen Zusammenhang mit einem Fließtext – sei es in Broschüren, wissenschaftlichen Arbeiten oder anderen Veröffentlichungen. Der Zusammenhang einer bestimmten Tabelle mit einer Aussage im Text wird durch Tabellenüberschriften bzw. Beschriftungen hergestellt. Tabellenüberschriften bzw. Beschriftungen haben zwei Funktionen: Sie beschreiben in Kurzform den tabellarischen Inhalt selber und sie verdeutlichen insbesondere bei mehreren Tabellen, welche dieser Tabellen zu welchem Inhalt gehört. Hätte man etwa 30 Tabellen ohne Tabellenüberschriften oder Beschriftungen und würde im Text lediglich „siehe Tabelle“ schreiben, dann wäre allenfalls noch – aber nicht mehr für jeden – aufgrund der visuellen Position klar, welche Tabelle eigentlich gemeint ist. Ein positives Beispiel wäre das Verwenden von Ordnungszahlen in Verbindung mit einer kurzen Beschreibung aus der aus einem Fließtext heraus quasi ähnlich wie bei Fußnoten z.B. durch „siehe Tabelle 3“ verwiesen wird. Ein negatives Beispiel wäre, wenn auf eine Tabelle über „siehe Tabelle rechts“ verwiesen wird. Negativ, weil die ausschließliche Angabe „rechts“ für Screenreader-Nutzer allenfalls dann eindeutig ist, wenn überhaupt nur eine einzige Tabelle verwendet wird. Denn mit Screenreadern werden Dokumente jeglicher Art linear gelesen.

Wichtig für die Barrierefreiheit von Datentabellen sowie ihrer Beschriftungen und Überschriften sind ausreichende Kontraste. Die technisch-besten Datentabellen nebst aussagekräftigen Überschriften und Beschriftungen stellen Menschen mit sogenannten moderaten Sehbehinderungen und damit oft auch ältere Nutzer vor Probleme, wenn sie schlecht leserlich sind. Gerade Beschriftungen von Datentabellen (sowie von Bildern) gehören leider zu den Klassikern schlechter Leserlichkeit und häufig gilt das auch für die Tabellen selber – und zwar vor allem im Format „PDF“.

Noch wenig ausgeschöpft wird das barrierefreie Potenzial von Datentabellen im Kontext von Diagrammen. Diese entstehen zwar oft aus Datentabellen, die dann aber nur selten ins Dokument gelangen. Die Folge: Statt aus den Alternativtexten von Diagrammen auf zugehörige Datentabellen verweisen zu können, werden oft lange und notwendig unstrukturierte Alternativtexte für Screenreader-Nutzer nötig, die erst noch geschrieben werden müssen und sich zudem ab einer bestimmten Menge durchaus negativ auf das Scrollen in langen PDF-Dokumenten auswirken können.

Auch vor dem Hintergrund der oft kontrastschwachen Diagramme sowie dem sicheren Erkennen der verwendeten Farben und ihrer Bedeutung – z.B. bei Liniendiagrammen – bieten Datentabellen einen unterstützenden alternativen Zugang für Menschen mit Sehbehinderungen. In PDF sogar dann noch, wenn bereits alle redaktionellen Schleifen durchlaufen und das PDF in Druck gegangen ist. Denn PDF bietet die Möglichkeit, Datei-Anlagen zu verwenden. So können Datentabellen in separaten Dateien angehängt werden und damit als alternative Versionen dienen – selbstverständlich muss dies dann aus dem Alternativtext eines Diagramms deutlich werden. Diese Technik eignet sich übrigens auch, wenn PDF-Dokumente Zeitungsartikel enthalten.

Schließlich und das gilt für Inhalte jeglicher Art dürfen auch in Tabellen Informationen nicht über Farbe allein vermittelt werden. In Abfallkalendern etwa sorgen zusätzliche Kürzel für einzelne Abfuhrtermine nicht nur für ein Mehr an Barrierefreiheit für Menschen mit Behinderung, sondern auch für eine deutliche Kostenersparnis bei einer evtl. nötigen Nachbearbeitung. Denn: Verwendet man nicht nur Farben, sondern ergänzende Kürzel, dann erspart man sich ein zeitaufwändiges Hinterlegen von Texten. Außerdem adressieren solche Texthinterlegungen vor allem blinde Leser. Eine Legende und damit Beschriftung könnte dann lauten: „P – Papiermüll“ statt z.B. „Blau – Papiermüll“ und natürlich sollte in der Tabelle „echter“ Text verwendet werden und keine Grafik, da sonst Alternativtexte geschrieben werden müssen. Und in Tabellen mit Belegungszeiten würden ergänzende Kürzel ebenfalls dafür sorgen, dass die Information nicht nur über Farbe vermittelt wird.

verschieden farbige Felder zur Kennzeichnung von Belegungszeiten eines Schwimmbads.
Screenshot: Ausschnitt mit ausschließlich farbiger Kennzeichnung über Belegungszeiten.

 

Wie generell bei Accessibility und Usability gilt auch bei Datentabellen: Sie müssen von Beginn an im Konzept, im Design sowie redaktionell eine Rolle spielen und natürlich korrekt ausgezeichnet werden. Um die technische Auszeichnung geht es im folgenden Abschnitt.

Technische Auszeichnung von Datentabellen

Datentabellen lassen sich in einfache und komplexe Datentabellen einteilen. Als „einfache Datentabellen“ können solche mit einem 1:1-Verhältnis von Spalten- oder Zeilenüberschriften zur Anzahl der zugehörigen Spalten bzw. Zeilen bezeichnet werden. Als „komplexe Datentabellen“ können Tabellen mit mehreren Ebenen, Zwischenüberschriften und Untergliederungen bezeichnet werden. Die Auszeichnung von Datentabellen ist in PDF und HTML ebenso ähnlich wie der Umgang von Screenreadern damit. Die vorgesehenen Standard-Tags sind:

  • TH-Tags für Spalten- bzw. Zeilenüberschriften
  • TD-Tags für Datenzellen
  • TR-Tags für Zeilen und
  • Caption-Tags für Beschriftungen und Tabellenüberschriften.

Bezüglich Tabellenüberschriften sei angemerkt, dass abhängig vom Dokument H-Tags bei der konkreten Usability für Screenreader-Nutzer besser sein können. Z.B. wenn mehrere Datentabellen einander folgen. Der Grund ist: H-Tags können von Screenreader-Nutzern mit der H-Taste direkt angesteuert werden und erscheinen in von Screenreadern erzeugten Inhaltsverzeichnissen. Das ist bei Caption-Tags nicht der Fall.

TH-Tags in PDF (bzw. TH-Elemente in HTML) für Spalten- und/oder Zeilenüberschriften sorgen dafür, dass diese sicher Screenreadern als solche erkannt und beim Navigieren durch eine Tabelle gemeinsam mit dem zugehörigen Inhalt der Datenzelle angesagt werden können. Dabei werden bei einfachen Datentabellen TH-Tags bzw. TH-Elemente automatisch und ohne weitere Attribute wie Scope oder Headers (zusammen mit ID) auf die Inhalte einer Spalte bzw. Zeile angewandt und vorgelesen.

Bei komplexeren Datentabellen benötigen Screenreader für die korrekte Auswertung weitere Attribute wie ’scope‘, wenn beispielsweise eine Spaltenüberschrift für zwei Spalten gilt, oder ‚headers‘ und ‚ID‘ für noch komplexere Datentabellen mit weiteren Untergliederungen.

Wie sich Tabellen mit Screenreadern anhören und wie Datentabellen korrekt in HTML ausgezeichnet werden, kann im Artikel Benimmregeln für Datentabellen von Tomas Caspers nachgelesen und nachgehört werden. Für das Format „PDF“ funktioniert das letztlich ähnlich, weswegen hier keine Audio-Beispiele zur Verfügung gestellt werden.

Datentabellen in WCAG 2.0 / EN 301549 und der BITV 2.0

Hinsichtlich der Anforderungen an die Barrierefreiheit von Datentabellen bestehen zwischen WCAG 2.0 und BITV 2.0 kein Unterschied. Außerdem gelten die Aussagen für die Anforderungen gemäß dem europäischen Standard EN 301 549 und damit auch für die Umsetzung der EU-Richtlinie 2016/2102 zur Barrierefreiheit. Für Datentabellen sind mehrere Erfolgskriterien relevant:

  • Dass Daten in Zellen sowie Spalten- und Zeilenüberschriften als auch Tabellenüberschriften bzw. -beschriftungen mindestens einen Kontrast von 4,5:1 zum Hintergrund haben müssen ergibt sich aus Erfolgskriterium 1.4.3 (Konformitätsstufe AA).
  • Werden Tabellenüberschriften und Beschriftungen verwendet, dann müssen diese aussagekräftig sein (Erfolgskriterium 2.4.6, Konformitätsstufe AA).
  • Inhalte dürfen nicht über Farbe allein vermittelt werden (Erfolgskriterium 1.4.1, Konformitätsstufe A).
  • Inhalte sollen nicht nur über sensorische Merkmale vermittelt werden (Erfolgskriterium 1.3.3, Konformitätsstufe A). Dies würde – negativ – dann greifen, wenn eine Datentabelle nur über „siehe Tabelle rechts“ referenziert wird und nicht beispielsweise über „siehe Tabelle 5 rechts“ (bei durchnummerierten Datentabellen) oder über „siehe Tabelle ‚Titel xy'“.

Anforderungen an die technische Auszeichnung schließlich ergeben sich formatunabhängig und damit für sowohl HTML als auch PDF aus Erfolgskriterium 1.3.1 (Konformitätsstufe A):

„1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)“

Deutsche autorisierte Übersetzung:

„1.3.1 Info und Beziehungen: Informationen, Struktur und Beziehungen, die über die Darstellung vermittelt werden, können durch Software bestimmt werden oder stehen in Textform zur Verfügung. (Stufe A)“

Das Erfolgskriterium nennt die Aspekte „Information“, „Struktur“ und „Beziehung“ und deren Ermittelbarkeit für Programme und damit für Screenreader.

Sind Spalten- und/oder Zeilenüberschriften nicht über TH-Elemente bzw. TH-Tags ausgezeichnet, sondern nur rein-visuell z.B. durch Farbe oder fetter Schrift gekennzeichnet, dann können sie von Screenreadern nicht sicher ermittelt und angesagt werden. Formal ergibt sich daraus ein Verstoß gegen WCAG 2.0 auf Stufe A.

Kein Verstoß und damit nach WCAG 2.0 kein Fehler ist, wenn für einfache Datentabellen weder Scope bzw. keine Headers und ID definiert sind. Der Grund: Screenreader wenden hier TH-Tags bzw. TH-Elemente bereits korrekt an. Dies bestätigten erst kürzlich durchgeführte Screenreader-Tests einfacher Datentabellen jeweils mit und ohne Scope mit den Screenreadern JAWS und NVDA (gegengetestet von Jan Eric Hellbusch. Vielen Dank dafür). Ein Fehler bei einfachen Datentabelle wäre jedoch, wenn der Scope für eine Spaltenüberschrift auf „2“ gesetzt wäre, obwohl sie sich nur auf eine Spalte erstreckt.

Nach WCAG 2.0, EN 301549 (und damit für die EU-Richtlinie 2016/2102) und BITV 2.0 sind Scope oder Headers und ID für komplexe Datentabellen freilich obligatorisch, nicht aber für einfache Datentabellen. Entstehen PDF-Dokumente zunächst in Word und werden nur einfache Datentabellen verwendet, dann können diese spätestens seit Word 2016 (z.B über Speichern unter als PDF) ohne zusätzlichen Aufwand oder zusätzlicher Software sehr gut barrierefrei erstellt werden. Ein Problem, das Microsoft inzwischen gelöst hat, waren lange Zeit Zeilenüberschriften. Hier entstand regelmäßig das Problem, dass Zeilenüberschriften lediglich als TD ausgezeichnet waren.

Sind hingegen zwar – unabhängig vom Format – Datentabellen technisch-ausreichend, aber Kontraste nicht ausreichend, dann kann nur noch Stufe A der WCAG 2.0 erfüllt werden. Da der europäische Standard EN 301 549 die Stufe AA vorsieht, würden diese Dokumente den EU-Standard und damit auch die Europäische Richtlinie zur Barrierefreiheit verfehlen. Analog gilt dies für ggf. weitere relevante Aspekte, wie oben genannt.

Hinweis: Die Themen „Kontraste“, „Aussagekräftige Überschriften und Beschriftungen“, „Informationen nicht über Farbe allein vergeben“ und nicht „nur über sensorische Merkmale allein“ wurden in anderen Teilen dieser Artikelserie ausführlich behandelt.

Datentabellen in PDF/UA-1

Das Thema „Datentabellen“ wird auch in PDF/UA-1 (PDF Universal Accessibility) behandelt. Neben der Anforderung, dass Spalten- und Zeilenüberschriften als TH-Tags auszuzeichnen sind, beschränkt sich PDF/UA-1 auf eine generalisierte rein-technische Umsetzung bzgl. Scope bzw. Headers und ID – unabhängig davon, ob es sich um einfache oder komplexe Datentabellen handelt. Die Fehlerbedingung im Matterhorn-Protokoll lautet:

„In einer Tabelle, deren Zellenzuordnungen nicht mit Hilfe von Header-Attributen und IDs geregelt sind, sind TH-Zellen ohne Scope-Attribut vorhanden.“

In der Spalte „Wie“ (man das prüft) wird „Software“ genannt. Weitere Anforderungen an die Umsetzung von Datentabellen werden abgesehen davon, dass nur tabellarische Inhalte auch Tabellen sein sollen nicht formuliert. Eine separate Fehlerbedingung ist außerdem: „Eine vorhandene Zeilen- oder Spaltenüberschrift zu einer Zelle kann nicht eindeutig ermittelt werden“ – ein Fehler, der sich mindestens teilweise bereits aus den schon als Fehler genannten nicht-vorhandenen TH-Tags für Zeilen- und Spaltenüberschriften ergibt.

Kompatibilität von PDF/UA-1, WCAG 2.0 und BITV 2.0

Während PDF/UA-1 für die Auszeichnung komplexer Datentabellen nichts zufügt, was sich nicht bereits aus den WCAG 2.0 ergeben würde – woraus sich natürlich eine Kompatibilität ergibt – , wirken sich die Anforderungen für einfache Datentabellen deutlich auf diese aus.

Kompatibel ist die Auszeichnung von Spalten- und Zeilenüberschriften selber; kompatibel ist die korrekte Verwendung von Scope bzw. Headers und ID bei komplexen Datentabellen. Nicht kompatibel ist die zwingende Verwendung von Scope bzw. Heaers und ID für einfache Datentabellen. Nur bei falschen Werten für das Scope-Attribut wiederum kann von Kompatibilität gesprochen werden. Für konkrete PDF-Dateien mit ausschließlich einfachen Datentabellen kann also nicht davon ausgegangen werden, dass ein PDF/UA-1-Fehler auch tatsächlich ein Fehler nach WCAG 2.0 ist und die konkrete Barrierefreiheit für blinde Leser betroffen ist.

Auch weitere Aspekte sind nicht kompatibel, denn Tabellen – seien sie einfach oder komplex – ohne (ausreichende) Kontraste können aufgrund fehlender Anforderungen dazu PDF/UA-1-konform, erfüllen aber nicht die WCAG 2.0 auf Stufe AA und verfehlen damit die EU-Richtlinie zur Barrierefreiheit insgesamt. Sind Überschriften und Beschriftungen nicht nur nicht aussagekräftig, sondern sogar falsch, dann ist das PDF-Dokument ebenfalls aufgrund fehlender Anforderungen durchaus formal-konform mit PDF/UA-1, aber nicht mit WCAG 2.0 auf Stufe AA. Weitere betroffene Aspekte sind je nach Tabelle u.U. Informationen, die nur über Farbe vermittelt werden sowie im Zusammenspiel mit Fließtexten Informationen, die nur über sensorische Merkmale vermittelt werden.

Folgen für die Praxis

Obwohl das zusätzlich verlangte Scope-Attribut bei einfachen Datentabellen kein Problem löst, wird das Fehlen im PAC 3.0 bemängelt. Der Grund ist einfach: Wenn ein Prüftool explizit PDF/UA-1 prüfen soll, dann muss es das auch prüfen – selbst dann, wenn es sich um einen bloß-formalen Aspekt handelt und man hier nicht die Barrierefreiheit prüft. Für die Praxis sind die Folgen jedoch meiner Auffassung nach durchaus erheblich – und zwar für Dokumentersteller und natürlich Dienstleister:

  • Man muss – dies betrifft insbesondere die händische Nacharbeitung – für einfache Datentabellen Zeit für einen Bearbeitungsvorgang (Setzen des Scope für einfache Datentabellen) investieren, der dies zeigen die oben erwähnten Screenreadertests kein vorhandenes Problem löst. Dadurch werden insbesondere PDF-Dateien mit einfachen Datentabellen insbesondere bei manueller Bearbeitung teurer.
  • Man hat bei der Auszeichnung einfacher Datentabellen eine mögliche Fehlerquelle mehr, denn falsche Angaben für Scope sind sowohl in WCAG 2.0 als auch BITV 2.0 als auch PDF/UA-1 ein Fehler.
  • Bei dem populären Weg von Word nach PDF funktioniert inzwischen die Auszeichnung von Datentabellen sehr gut, aber bei der Konvertierung über den hier eigentlich völlig ausreichenden Weg über „Speichern unter als PDF“ wird Scope nicht gesetzt. Das bedeutet, dass man für PDF/UA-1 entweder in Lizenzen für zusätzliche Software investieren oder händisch nacharbeiten muss, um in diesem Fall ein Problem zu lösen, das schon vorher nicht bestand – wie jüngste Tests mit NVDA und JAWS und damit den meist-verwendeten Screenreadern zeigen.

Wir haben hier eine ähnliche Situation wie bei der Auszeichnung des Sprachwechsels. Der Unterschied: Während die nach PDF/UA-1 offenbar vorgesehene Auszeichnung jedes einzelnen anderssprachigen Wortes Screenreader-Nutzer sogar stören kann, stören bei einfachen Datentabellen korrekte Scopes zwar nicht, haben aber auch keinen echten Effekt.

Ein kritischer Aspekt ist außerdem, dass das Matterhorn-Protokoll in der Spalte „Wie“ (man das prüft) „Software“ nennt. Bei einfachen Datentabellen können Screenreader nicht gemeint sein, denn TH-Tags werden wie oben ausgeführt auch ohne Scope erkannt und vorgelesen. Und schaut man sich die Ergebnisse von Prüfwerkzeugen an, so liefern diese keine identischen Ergebnisse. Darunter explizite Prüfwerkzeuge für PDF/UA-1. Das zeigt sich am Matterhorn-Protokoll selber.

Der PAC 2.0 gibt als Ergebnis 0 Fehler aus (Hinweis: PAC 2.0 prüft Zuweisungen bei Tabellen nicht) und der PAC 3.0 liefert 0 Fehler aus.

Screenshot Prüfergebnis PAC 3.0 für Matterhorn-Protokoll - 0 Fehler
Prüfbericht des PAC 3.0 für das Matterhorn-Protokoll.

Die PDF/UA-1-Prüfroutine des im internationalen Kontext relevante Prüftool Commonlook PDF Validator hingegen bemängelt die Tabelle auf Seite 3 des Matterhorn-Protokolls.

Screenshot Bericht für Tabelle S. 3 Matterhornprotokoll mit gemeldeten 6 Fehlern bei Zellenzuordnungen
Prüfbericht Commonlook PDF Validator für Tabelle auf Seite 3 des Matterhorn-Protokolls (PDF/UA-1-Prüfroutine)

Unterschiedliche Prüfergebnisse aber sind für Dienstleister fatal. Das betrifft auch die Unterschiede zwischen PAC 2.0 und PAC 3.0 für Datentabellen – auch wenn das Feedback im PAC 3.0 für PDF/UA-Fehler nun nicht mehr lautetet, dass Accessibility-Probleme gefunden wurden, sondern dass die Datei nicht PDF-UA-konform ist.

Abschließend sei angemerkt, dass weder PAC 3.0 noch PAC 2.0 in der Liste von Prüftools für die Evaluierung nach WCAG 2.0 (und damit der EU-Richtlinie zur Barrierefreiheit) beim W3C aufgeführt sind. Aussagen, wonach der PAC 2.0 vom W3C als Prüftool für WCAG 2.0 empfohlen würde, sind seit dem Update der Understanding-Dokumente zur WCAG 2.0 vom Juni 2016 nicht mehr aktuell (Stand 4.05.2018). Als Software für die Evaluierung werden neben API-Checking-Tools die integrierte Prüfroutine von Adobe Pro und der o.g. Commonlook PDF Validator, der auch eine Prüfroutine für WCAG 2.0 enthält. Bei Tests fiel jedoch auf, dass auch unter der WCAG-2.0-Prüfroutine sowohl die Tabelle auf Seite 3 des Matterhorn-Protokolls sowie Scope bzw. dessen Fehlen generell und damit auch bei einfachen Datentabellen geprüft wird.

Screenshot. Laut Commonlook PDF Validator sind in Tabelle 3 sechs Zellen nicht den Zeilenüberschriften zugewiesen.
Prüfbericht des Matterhorn-Protokolls im Commonlook PDF Validator für Tabelle auf Seite 3 nach WCAG 2.0-Prüfroutine.

Testdokumente

Die folgenden Testdokumente enthalten zur Nachvollziehbarkeit und insbesondere der Evaluierung der Aussagen für Assistive Technologien dieses Artikels drei Demo-Datentabellen mit Zeilenüberschriften, Spaltenüberschriften sowie Zeilen- und Spaltenüberschriften – jeweils mit und ohne Scope.