Benimmregeln für Datentabellen

Für Webentwickler bedeutete die Umstellung von Tabellen auf CSS, dass sie alte Gewohnheiten vergessen mussten. Sämtliche Techniken und Kniffe aus den Zeiten von Layout-Tabellen sind scheinbar ›verlernt‹. Das richtige Umsetzen echter Datentabellen erfordert jedoch eine Rückbesinnung: man muss sich wieder mühsam in die Spezifikationen einlesen und in das Tabellenmodell von HTML hineindenken.
Wir erklären, wie man tabellarische Daten so aufbereitet, dass sie nicht nur hübsch aussehen, sondern auch mit den assistiven Programmen von Menschen mit Behinderung optimal nutzbar sind.

Tags: , , , ,

Stand: 31.10.2008, Autor: tc

HTML-Tabellen wurden erstmalig Mitte der neunziger Jahre gebräuchlich – damals noch mit dem klaren Ziel, tabellarische Daten darzustellen. Sehr schnell erkannten findige Webdesigner, dass man mit Tabellen weitaus mehr machen kann als nur Börsenkurse oder Wetterberichte zu formatieren und sie benutzten Tabellen zur freien Positionierung von Seiteninhalten auf den damals in der Regel einspaltigen Webseiten.

Weil sich auch schon damals nicht alle Browser gleich verhielten, kam es schnell zu den ersten Hacks mit verschachtelten Tabellen und Spacer-GIFs und ein neues Problem war geboren – die unzugängliche Layout-Tabelle. Deren Hauptproblem neben dem aufgedunsenen Code: die mangelnde Linearisierbarkeit und der damit verbundene unlogische Aufbau einer Seite, bei der die optische Darstellung nicht mehr unbedingt der Reihenfolge im Quelltext entspricht.

Auch wenn kein zwingender Zusammenhang besteht, aber die praktische Erfahrung hat gezeigt, dass Layout-Tabellen in der Regel zusammen mit unflexiblen Bemaßungen, tiefen Verschachtelungen und invalidem Code benutzt werden – Techniken, die weitere negative Folgen für die Zugänglichkeit eines Angebots nach sich ziehen. Das größte Problem bei Tabellen ist demnach nicht ihre Verwendung per se, sondern die Art und Weise wie sie eingesetzt werden.

Besonders problematisch war und ist dies für die sogenannten Screenreader - dies sind Programme, mit denen blinde oder stark sehbehinderte Nutzer eine aufbereitete akustische Ausgabe der Webinhalte erhalten. Anders als der Name vermuten lässt, lesen moderne Screenreader nicht einfach den Bildschirminhalt vor (z.B. von links oben nach rechts unten), sondern die Programme interpretieren (vereinfacht gesagt) eine eigene Version des Quelltextes einer Seite. Problematisch wird dieser Quelltext dann, wenn sich die Auszeichnung der Inhalte (das sog. Markup) nicht an Konventionen hält oder Sprachelemente von HTML zu Zwecken eingesetzt werden, für die sie nie gedacht waren.

Screenshot mit Hervorhebung von dreifach verschachtelten Layouttabellen bei einer Bundesbehörde

Ähnliches gilt natürlich auch für tabellenfreie Layouts: mit CSS kann man ebenso Seiten erstellen, die zwar hervorragend aussehen, die jedoch linearisiert (also ohne CSS) betrachtet keine sinnvolle Nutzung ermöglichen. Einen weiteren Sonderfall stellen Angebote dar, deren Inhalte bei genauerer Analyse eigentlich mit Tabellen aufgebaut sein müssten, bei denen die Entwickler jedoch versucht haben, die Optik mit CSS und verschachtelten DIV nachzubilden. Hier fehlen dann die notwendigen Strukturinformationen, die zu einer effektiven Nutzung der logischen Zusammenhänge bei den tabellarischen Daten benötigt werden, da diese nicht über DIV und SPAN erzeugt werden können.

Kein Element aus HTML ist ›schlecht‹ oder ›gut‹ im Sinne der Accessibility, sofern es so verwendet wird, wie es seinem vorgesehenen Zweck entspricht. Dazu gehört, dass Tabellen (anders als in der BITV 1.0 vorgesehen) nicht »in der Regel nur zur Darstellung tabellarischer Daten zu verwenden« sind, sondern generell im Layout einer Seite nichts verloren haben. Die Diskussion, ob Layout-Tabellen nicht doch besser seien ist schon vor Jahren zu Gunsten von CSS entschieden worden. Anders lautende Behauptungen können nicht das Gegenteil beweisen, sondern lassen nur den Schluss zu, dass sich die Verfechter von Tabellenlayouts nicht mit modernen Handwerkstechniken der Webentwicklung beschäftigen wollen.

Frühere, aktuelle & kommende Standards

Nachdem der Browser-Hersteller Netscape die HTML-Tabellen-Elemente ca. 1995 auf die damals übliche Art im Alleingang eingeführt hatte, gab es mit den nie endgültig verabschiedeten HTML+ bzw. HTML 3.0 erste Versuche einer Standardisierung durch das W3C. Die damals vorgeschlagenen Elemente und Attribute dürften heute selbst unter erfahrenen HTML-Autoren nur noch Stirnrunzeln hervorrufen; das im späteren HTML3.2 festgelegte Tabellenmodell entspricht jedoch weitestgehend den nach wie vor aktuellen Vorgaben aus HTML 4.01.

Während einfache Datentabellen damit relativ gut spezifiziert sind, bietet HTML nach wie vor nur begrenzte Möglichkeiten für komplexe oder mehrdimensionale Datentabellen. Die Aufbereitung tabellarischer Daten für sehende Nutzer ist mit den zur Verfügung stehenden Mitteln schon einigermaßen schwierig; nimmt man nun noch die Vorgabe nach einer sinnvollen Interpretation durch Screenreader hinzu, so kommt man z.B. bei der Aufbereitung komplexer statistischer Daten schnell an die Grenzen der Möglichkeiten von HTML.

Dazu kommt dass der Bereich Tabellen (wie vieles im HTML4-Standard) etwas unter-spezifiziert und unter-erklärt ist. Manche Konstruktionen sind auch schlichtweg nicht besonders einleuchtend, was mit ein Grund dafür sein dürfte, dass man sie im Web nur selten antrifft (Quizfrage für HTML-Theoretiker: warum ist colgroup ein Element, rowgroup hingegen nur ein Attribut eines anderen Elementes?).

In der Theorie sind Theorie und Praxis gleich, in der Praxis sind sie es nicht.

Die wichtigste Voraussetzung für die barrierefreie Nutzung von Datentabellen ist natürlich deren Aufbereitung nach den gängigen Regeln der Kunst – im vorliegenden Fall also nach den W3C-Spezifikationen für HTML 4.01 bzw. XHTML1.x sowie den Web Content Accessibility Guidelines (WCAG 1.0 bzw. 2.0). Dies ist der Punkt, für den ausschließlich der Anbieter bzw. der Web-Entwickler die Verantwortung tragen.

Daneben gehört zu einer barrierefreien Nutzung aber auch die Unterstützung dieser Spezifikationen durch die gebräuchlichen Web-Browser und insbesondere durch die Computerhilfsmittel. Was nützt die beste optimal aufbereitete Datentabelle, wenn verbreitete Hilfsmittel diese nicht in einer Form wiedergeben können, die dem Nutzer den Zugang zu den Informationen und deren sinnvolle Verarbeitung ermöglicht? Daher sollte man im Sinne einer barrierefreien Nutzbarkeit immer zusätzlich die tatsächliche Ausgabe in verschiedenen Medien betrachten und bei Entscheidungen für oder gegen bestimmte Elemente und Attribute mit in Erwägung zu ziehen.

Einige dieser Tabellen-Elemente und -Attribute haben sich im Praxiseinsatz nicht bewährt (z.B. summary, caption), oder werden von User Agents und Hilfsmitteln nur unzureichend unterstützt (z.B. axis, headers, abbr). Daher könnte es durchaus passieren, dass diese in kommenden HTML-Versionen (namentlich HTML5) nicht mehr spezifiziert sind. Statt dessen werden wohl eine ganze Reihe neuer Elemente und Attribute eingeführt – die Diskussion über den sinnvollen Einsatz ist zum jetzigen Zeitpunkt jedoch rein akademisch, da die Fertigstellung von HTML5 noch geraume Zeit auf sich warten lässt.

Dass es dann aber erst einmal wieder zu einem Bruch zwischen den Standards und ihren Implementierungen in Browsern und Hilfsmitteln kommen wird liegt in der Natur der Dinge und sollte niemanden davon abhalten, solche Standards weiterzuentwickeln und damit Grenzen zu verschieben. Es ist das alte Ei-oder-Henne-Problem: für die Verbesserung der Zugänglichkeit braucht man zunächst Anwendungsfälle, die neue Standards sinnvoll einsetzen. Erst dann können die Hersteller von Zugangssoftware diese implementieren; aber erst wenn sie implementiert und damit für die Anwender nutzbar sind, werden sie von Autoren auch verwendet werden. Dass es in diesem Zeitfenster zum Problem der mangelnden Zugänglichkeit solcher Innovationen kommt liegt in der Natur der Dinge und spricht nicht gegen, sondern gerade für solche Verbesserungen und vor allem für ihre schnellere Umsetzung.

Es bleibt zu hoffen dass es damit schneller vorangeht als beim HTML 4.01-Standard, der auch 10 Jahre nach Fertigstellung von marktbeherrschenden Hilfsmitteln immer noch nicht vollständig unterstützt wird.

Wann ist eine Tabelle eine Tabelle?

Eine Tabelle ist zunächst einmal nichts anderes als die Anordnung von einzelnen Daten und Metadaten in einem zweidimensionalen Raster, wobei sich die Bedeutung der Daten aus ihrer Position im Raster und der Zuordnung zu den Metadaten ergibt. Dabei werden in HTML die eigentlichen Daten in Tabellenzellen (<td>foo</td>) gesetzt, die Metadaten wiederum stehen in der Regel in Überschriftenzellen (<th>bar</th>). Diese Metadaten (Kategorien o.ä.) beschreiben die ihnen zugeordneten Daten und sollten für sich selbst stehend einen Sinn ergeben; die Daten in den Datenzellen wiederum sind für sich genommen sinnfrei bzw. nur sinnvoll interpretierbar, wenn ihnen Metadaten über eine oder mehrere Überschriftenzellen zugeordnet sind (1 was? 5 wovon?).

Eine ganz einfache Regel mit der Sie feststellen können, ob Ihre Inhalte in eine Tabelle gehören: wenn Sie die Daten umsortieren und damit in eine andere Beziehung zueinander setzen können, dann handelt es sich um eine Tabelle. Ist dies nicht der Fall, dann hat man maximal eine eindimensionale Tabelle, die in HTML besser in einer Liste (ul oder ol) aufgehoben wäre.

Wann ist eine Tabelle eine barrierefreie Tabelle?

Der Unterschied liegt nun darin, dass eine barrierefreie Tabelle neben der rein optischen auch eine programmatische Zuordnung der Daten zu ihren Metadaten und umgekehrt besitzt. Der Quelltext einer solchen Tabelle besteht aus Elementen und Attributen, die es nicht-visuellen Zugangsarten ermöglichen, die notwendigen Verknüpfungen herzustellen und dem Nutzer entsprechend zu präsentieren. Falls Sie sich für die technischen Details interessieren: im HTML-Standard findet sich ein ganzer Abschnitt (»11.4 – Tabellendarstellung durch nicht visuelle Benutzerprogramme«), in dem die Algorithmen beschrieben sind, nach denen Browser und Hilfsmittel bei der Verarbeitung von Datentabellen vorgehen sollten.

Für die Diskussion barrierefreier Datentabellen sind also zwei Aspekte von Bedeutung: die visuelle Präsentation für sehende Nutzer und die darunter liegende Struktur für Nutzer assistiver Programme. Dass für die barrierefreie Nutzung von einigermaßen komplexen Datentabellen auch konforme Hilfsmittel benötigt werden, die sich ihrerseits an die etablierten Standards halten, darf von Web-Autoren einfach vorausgesetzt werden können. Auch wenn einige Screenreader von sich aus Überschriftenzellen in eine Tabelle ›hineininterpretieren‹ – zu einer wirklich barrierefreien Tabelle gehört zwingend auch die Zuordnung der Daten zueinander und zu ihren Überschriften, um absolute Eindeutigkeit zu garantieren.

Sehende Nutzer haben es da relativ einfach: Überschriftenzellen (TH) werden von grafischen Browsern generell anders formatiert dargestellt (in der Regel fett und zentriert) als normale Datenzellen. Will man nun wissen, zu welcher Überschrift eine Datenzelle gehört, so schaut man einfach nach oben oder zur Seite und assoziiert so die Informationen. Blinden oder stark sehbehinderten Nutzern stehen diese Möglichkeiten naturgemäß nicht zur Verfügung. Sie sind darauf angewiesen, dass diese logischen Verknüpfungen auch für eine Software ersichtlich sind, damit diese die Inhalte entsprechend ausgeben kann.

In der nächsten Folge geht es um den Aufbau von einfachen Datentabellen.