| Version | bis 30.05.2007 | Aktuell |
|---|---|
| BITV-Bedingung | 5.1 |
| Bewertungsalternativen | ja / eher erfüllt / eher nicht erfüllt / nein / nicht anwendbar |
| Gewichtung | hohes Gewicht (3 Punkte) |
| Abwertung | auf "schlecht zugänglich" |
| Bezieht sich auf | einzelne Webseite |
| Prüfschritt erfüllt | Datentabellen sind richtig aufgebaut und ausgezeichnet. |
| Prüfschritt nicht anwendbar | Datentabellen sind nicht vorhanden. |
Datentabellen sind strukturell richtig aufgebaut, Zeilen- und Spaltenüberschriften sind mit th ausgezeichnet.
Visuell orientierte Personen nutzen für die Orientierung in einer Datentabelle neben den Überschriften wenn nötig auch den Wertebereich. Es ist für sie daher relativ leicht möglich, strukturelle Mängel, zum Beispiel Wechsel in der Bedeutung von Zeilen oder Spalten zu erkennen und mit ihnen umzugehen.
Sehbehinderte und blinde Benutzer erschließen sich das Angebot von Datentabellen dagegen eher analytisch. Sie entwickeln ausgehend von den Überschriften und anderen im Kontext verfügbaren Informationen eine Vorstellung vom Aufbau der Tabelle. Diese Vorstellung ist die Grundlage für den Zugriff auf die angebotenen Daten.
Damit das möglich ist und funktioniert, müssen zwei Bedingungen erfüllt sein:
Die klare Struktur ist die Grundlage der Barrierefreiheit von Datentabellen. Es ist nicht möglich, eine mangelhaft strukturierte Datentabelle durch spezielle Auszeichnung barrierefrei zugänglich zu machen. Auf Grundlage einer klaren, nachvollziehbaren Struktur ist die korrekte Auszeichnung aber nützlich und wichtig. Mögliche Anwendungen der Auszeichnung von Tabellenüberschriften:
Der Prüfschritt ist anwendbar, wenn die Seite Datentabellen enthält.
Prüfen, ob die Tabelle strukturell sinnvoll aufgebaut ist. Schwierigkeiten entstehen in den meisten Fällen dadurch, dass die Tabelle auch Layoutzwecken dient, das Tabellengitter also für die Anordnung von Inhalten auf dem Bildschirm genutzt wird. Problematisch können zum Beispiel sein:
Bei einer sinnvoll aufgebauten Tabelle kann man sagen, welche Informationen in den einzelnen Spalten und Zeilen der Tabelle enthalten sind. Man kann diesen Inhalt allgemein fassen, nicht nur als eine Zusammenstellung der in den einzelnen Zellen abgelegten Werte.
Mehr ist eigentlich nicht dran.
Die Bedeutung der einzelnen Spalten und Zeilen kann in den Überschriften gefasst sein. Das ist aber nicht zwangsläufig so, auch eine Tabelle ohne Überschriften kann sinnvoll strukturiert sein.
Wenn aussagekräftige Überschriften vorhanden sind, sollte man auch prüfen, ob das, was in den zugeordneten Zellen steht, den Überschriften entspricht. Nichtssagende Überschriften können darauf hinweisen, dass die betreffende Zeile oder Spalte keine allgemein fassbare Bedeutung hat, also eher dem Layout dient. Aber es kann auch sein, dass einfach keine bessere Überschrift gefunden worden ist.
Auch komplexe Tabellen sind aus einfachen Spalten und Zeilen zusammengesetzt, die Anforderungen sind so weit die selben. Hinzu kommt allerdings, dass benachbarte Zeilen oder Spalten durch übergreifende Überschriften zusammengefasst sind. Auch den Inhalt dieser zusammengefassten Bereiche muss man allgemein fassen können, wie den Inhalt der einzelnen Spalten und Zeilen.
Man nimmt eine beliebige Zelle und liest sie zusammen mit den zugehörigen Spalten- und Zeilenüberschriften:
"[Überschrift(en) der Spalte] - [Überschrift(en) der Zeile]: [Inhalt der Zelle]"
Ist die Bedeutung der Zelle so verständlich?
Gezielt untersucht werden sollen Auffälligkeiten: Ist irgendwo andersartiger Inhalt vorhanden, sind Zellen hervorgehoben? Man prüft, ob auch in diesen Bereichen alle Zellen in gleicher Weise, unabhängig von ihren Nachbarzellen, nur zusammen mit den beiden Überschriften benutzbar sind. Ist das der Fall? Dann ist die Tabelle richtig aufgebaut und per Screenreader benutzbar.
th ausgezeichnet sind.Für Datenzellen, die zugleich als Überschriften dienen, kann statt th auch das scope-Attribut genutzt werden (siehe "3. Korrekte Auszeichnung von zweideutigen Zellen").
Die Mindestanforderung: Offenkundige, unverzichtbare und visuell hervorgehobene Überschriften müssen ausgezeichnet sein (siehe "4. Woran erkennt man Zeilenüberschriften").
Zellen mit Daten können zugleich als Überschriften dienen. Der typische Fall: Die erste Spalte einer Tabelle hat eine Überschrift, die zugeordneten Daten dieser Spalte dienen zugleich als Zeilenüberschriften.
Wie soll man solche Zellen auszeichnen?
Nach den Empfehlungen zur Spezifikation von HTML 4.01 soll man Zellen, die zugleich Überschriften und Daten enthalten, nicht mit th, sondern mit td auszeichnen. Damit diese Zellen trotzdem wie Überschriften funktionieren, wenn der Nutzer zwischen Zeilen der Tabelle wechselt, sollen sie mit dem scope-Attribut ausgezeichnet werden.
Die Praxis folgt nicht den Empfehlungen zur Spezifikation, einfache Zeilenüberschriften werden überwiegend nicht über das scope-Attribut, sondern mit th als Überschriften ausgezeichnet. Für die Nutzbarkeit von einfachen Datentabellen ist dies zweckmäßig.
Daher werden beide Varianten akzeptiert:
scope-Attribut ist korrekt.Die visuelle Hervorhebung ist ein Erkennungsmerkmal für Überschriften. Wenn die erste Spalte einer Datentabelle visuell hervorgehoben ist, dann kann man davon ausgehen, dass die Inhalte dieser Spalte als Überschriften dienen sollen.
Dieser Zusammenhang lässt sich aber nicht umkehren, die visuelle Hervorhebung ist als Kriterium nicht immer ausreichend. Denn auf die Hervorhebung der Zeilenüberschriften wird manchmal aus Gestaltungsgründen verzichtet. Sehende Benutzer brauchen sie nicht unbedingt. Wenn der Inhalt einer Datenzelle nicht für sich aussagekräftig ist, beziehen sie die Zellen am linken Rand der Tabelle ein, die Position reicht ihnen als Hervorhebung.
Es ist manchmal schwierig, den Fall, dass auf die visuelle Hervorhebung aus gestalterischen Gründen verzichtet worden ist, abzugrenzen von dem Fall, dass die Inhalte der ersten Spalte tatsächlich als Überschriften nicht geeignet sind. Selbst wenn in der ersten Spalte zum Beispiel Namen von Herstellern oder Produkten stehen, ist das noch kein sicherer Anhaltspunkt für die Eignung als Überschrift. Denn Überschriften sollten eindeutig und geläufig sein, Herstellernamen sind nicht immer eindeutig, Produktnamen oft nicht geläufig.
Entwickler oder Redakteure sollten also überlegen, ob die Inhalte der ersten Spalte als Überschriften tauglich sind, ob es Sinn macht, dass ein Screenreader bei Zeilenwechseln immer den jeweiligen Inhalt der ersten Spalte zusammen mit der gerade angesteuerten Datenzelle vorliest. Wenn das der Fall ist, sollten die Zellen der ersten Spalte unbedingt als Überschriften ausgezeichnet werden.
Für die Prüfung gilt:
Auch bei Spaltenüberschriften kann auf die visuelle Hervorhebung verzichtet werden. Die vorstehenden Regeln sind dann in der gleichen Weise auf sie anzuwenden.
Überschriften sind überflüssig, wenn in den Zellen neben den Einzelwerten auch deren Bedeutung angegeben ist oder wenn die Bedeutung der Einzelwerte sich von selbst versteht. Ein typisches Beispiel dafür sind Preislisten: in der linken Spalte stehen die meist selbsterklärenden Produktbezeichnungen, in der rechten Spalte steht nicht nur die Betrag, sondern auch das Währungszeichen.
Für blinde und sehbehinderte Benutzer kann der Umgang mit solchen Tabellen schwierig sein. Denn mangels Überschriften müssen sie auf den Wertebereich zugreifen, um zu verstehen, was die Tabelle anbietet. Für normal sehende Benutzer ist das leicht, für Benutzer, die sich immer nur einen kleinen Ausschnitt der Tabelle vorlesen oder anzeigen lassen können, aber nicht.
Unproblematisch ist der Verzicht auf Überschriften, wenn zwei Bedingungen erfüllt sind:
Tabellen mit eingesparten Überschriften erfüllen also den Prüfschritt, wenn sie richtig aufgebaut und linear nutzbar sind.
In Tabellen, die tabellarische Daten darstellen, sind die Zeilen- und Spaltenüberschriften mittels der vorgesehenen Elemente der verwendeten Markup-Sprache zu kennzeichnen.
http://www.bik-online.info/info/gesetze/bitv/anlage_1.php#5-1
Kennzeichnen Sie bei Datentabellen Zeilen- und Spaltenüberschriften.
Verwenden Sie zum Beispiel in HTML TD, um Datenzellen, und TH, um Überschriften zu kennzeichnen.
http://www.w3c.de/Trans/WAI/webinhalt.html#tech-table-headers
Die folgenden Checkpunkte kommen unmittelbar Benutzern zugute, die auf eine Tabelle über das Gehör zugreifen (z. B. einen Screenreader oder einen Bordcomputer im Auto) oder die zu einem Zeitpunkt nur einen Teil einer Seite sehen können (z. B. blinde oder sehbehinderte Benutzer mit Sprachausgabe oder einem Blindenschrift-Display, oder andere Benutzer von Geräten mit kleinen Displays, o. Ä.)
Quelle: http://www.w3.org/Consortium/Offices/Germany/Trans/WAI/webinhalt.html
TH is for headers, TD for data, but for cells acting as both use TD
...
Note that it's not always possible to make a clean division of cells into headers or data. You should use the TD element for such cells together with the id or scope attributes as appropriate.
Und bezogen auf eine bestimmte Beispieltabelle:
Note the use of the scope attribute with the "row" value. Although the first cell in each row contains data, not header information, the scope attribute makes the data cell behave like a row header cell. This allows speech synthesizers to provide the relevant course name upon request or to state it immediately before each cell's content.
http://www.w3.org/TR/html4/struct/tables.html#h-11.2.1.1
Zwei Fälle sind da zu unterscheiden:
Der Aufbau der Tabelle gehört zum Inhalt. Das Dokument ist ist zum Beispiel historisch, es zeigt, wie die alten Ägypter ihre Erntedaten tabellarisch geordnet haben.
In diesem Fall muss geklärt werden, ob die Tabelle nur betrachtet oder auch genutzt werden soll. Wenn sie nur betrachtet werden soll, ist der lineare Zugriff ausreichend. Wenn sie auch genutzt werden soll, wenn sie also zum Beispiel auch über fette und magere Erntejahre Auskunft geben soll, ist die historische Form ungeeignet. Ein anderes Dokument muss dafür erstellt werden.
Der häufigere und wichtigere Fall: eine andere Abteilung liefert die mangelhaft aufgebauten Tabellen, in der EDV sollen sie durch unsichtbare Zusätze nachträglich barrierefrei gemacht werden.
In diesem Fall muss der Ablauf geändert werden, denn die mangelhafte Struktur kann nicht durch Auszeichnungen repariert werden, die Aufgabe ist nicht erfüllbar. Die Verantwortlichen müssen dafür sorgen, dass die Anforderungen der Barrierefreiheit an der richtigen Stelle, also schon bei der Erstellung der Tabellen beachtet werden.
(30.05.2007)
Beides ist richtig: Screenreader brauchen die Auszeichnung nicht zwingend, um Spalten- und Zeilenüberschriften vorzulesen - und gängige Screenreader verhalten sich auch genau so: Wenn der Benutzer in eine andere Spalte wechselt, liest zum Beispiel der Screenreader Jaws den Text vor, der in der obersten Zelle dieser Spalte steht, auch wenn diese Zelle nicht als th-Element ausgezeichnet ist. Ebenso beim Wechsel in eine andere Zeile: Der Inhalt der ersten Zelle wird unabhängig von der Auszeichnung immer vorgelesen (zumindest dann, wenn Datenzellen nicht ausdrücklich via headers und id mit bestimmten Überschriftenzellen verknüpft sind).
Warum ist das so?
Das beschriebene Verhalten der Screenreader ist bei einfachen Tabellen meistens richtig. Und es gibt natürlich im Web sehr viele Tabellen, bei denen die Überschriften nicht ausgezeichnet sind. Insgesamt wird der Benutzer daher am besten bedient, wenn der Screenreader die Zellen der ersten Zeile und der ersten Spalte grundsätzlich wie Überschriftenzellen behandelt.
Was folgt daraus? Kann man sich bei einfachen Tabellen den Aufwand für die Auszeichnung von Tabellenüberschriften dann nicht sparen?
Zunächst mal: Der Aufwand für die Auszeichnung der Zellen ist in der Regel nicht erheblich. Jedenfalls bei einfachen Tabellen: Es gibt entsprechende Vorlagen oder das CMS kümmert sich darum. Die eigentliche Herausforderung liegt woanders: Man muss dafür zu sorgen, dass die Tabellen einfach sind, dass die Inhalte der ersten Zeile und Spalte tatsächlich als Überschriften funktionieren und dass alle strukturierenden Inhalte dort untergebracht sind.
Und klar ist: nicht jedes Hilfsmittel muß in der beschriebenen Art und Weise mit Tabellen umgehen. Der IBM Homepagereader liest nur ausgezeichnete Überschriften vor, wie künftige Jaws-Versionen funktionieren, kann auch niemand sagen.
Oder allgemein gesagt: Die praktische Nutzbarkeit mit gängigen Screenreadern oder Browsern kann nicht der alleinige Maßstab für Barrierefreiheit und BITV-Konformität sein. Denn dann würde es immer bei dem unbefriedigenden Zustand bleiben, dass Screenreader versuchen müssen, aus barrierebehafteten Webangeboten irgend etwas brauchbares herauszuholen. Auf längere Sicht ist es auch wichtig, dass sich Webanbieter und Entwickler von Screenreadern oder Browsern an gemeinsame Standards halten.
(30.05.2007)