Teil 2: Komplexe Datentabellen
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.
Autor: tc
Wenn Ihre Tabellen über mehr als eine Zeile oder Spalte von Überschriftenzellen verfügen, dann haben Sie damit bereits komplexe Datentabellen. Neben den in Teil 1 der Serie angesprochenen Elementen und Attributen sollten nun weitere Techniken zum Einsatz kommen, die eine barrierefreie Nutzung solcher Tabellen erst ermöglichen. Dabei geht es nicht um zusätzlichen Komfort für Menschen mit Behinderungen, sondern um den zwingenden Einsatz von Techniken, ohne die sich die Inhalte einer Tabelle in nicht-visuellen Medien nicht erschließen lassen.
Elemente und Attribute für komplexe Datentabellen
Das summary-Attribut
HTML bietet eine ganze Reihe Elemente und Attribute, um zusätzliche Informationen zu Tabellen sichtbar oder unsichtbar zu hinterlegen; ihr Einsatz wird in den WCAG bzw. der BITV-Bedingung 5.5 gefordert. Problematisch bei der Erfüllung dieser Bedingung ist, dass unsichtbare Informationen mit dem dafür vorgesehenen summary-Attribut von TABLE nur für ganz bestimmte Zugangsformen zugänglich sind. In Screenreadern werden sie zwar üblicherweise vorgelesen, in grafischen Browsern wie z.B. Firefox muss man jedoch schon die rechte Maustaste (→Eigenschaften-Dialog) bemühen, um an die Inhalte der Summary (engl.: Zusammenfassung) zu gelangen. Da dies vielen Nutzern nicht klar sein dürfte, müssen diese Inhalte doppelt hinterlegt werden, damit alle sie wahrnehmen können. Aber: dann kann man auf die unsichtbaren Informationen auch gleich verzichten – ein generelles Problem unsichtbarer oder nur umständlich zugänglicher Metadaten.
In begründeten Ausnahmefällen kann es sinnvoll sein (aber wirklich nur dann), in summary zusätzliche Hinweise für Screenreader-Nutzer zu hinterlegen - aber nur wenn diese Hinweise im jeweiligen Nutzungskontext tatsächlich auch benötigt werden, weil sich z.B. ansonsten die Tabelle in der Sprachausgabe nicht erschließen lässt.
Tipp: Auch im BIENE-Prüfverfahren wird dieser Punkt seit dem Jahr 2006 nicht mehr strikt gehandhabt. Es wird lediglich bewertet, ob irgendeine angemessene Form der Beschriftung im Sinne einer Zusammenfassung oder Überschrift gewählt wurde. Dies kann CAPTION, summary oder Hn sein. In der amerikanischen Section 508, dem dortigen Äquivalent zur BITV, wird der Gebrauch von caption übrigens nicht vorgeschrieben.
Tabellenüberschriften mit CAPTION
Mit dem CAPTION-Element lässt sich eine (sichtbare) Tabellenüberschrift definieren. Das Element folgt unmittelbar nach dem eröffnenden <table> und darf weitere HTML-Inline-Elemente, jedoch keine Block-Elemente (hn, P etc.) enthalten. In der Transitional-Variante von HTML können Sie zwar die Position der Tabellenüberschrift über das align-Attribut angeben, allerdings sollten Sie hierauf zu Gunsten von CSS verzichten. Die Angabe von table {caption-side: bottom} macht hier, analog zu dem veralteten <caption align="bottom"> aus der Tabellenüber- eine Tabellenunterschrift.
Wenn Ihre Tabellen in herkömmlichen Content-Seiten stehen können Sie davon ausgehen, dass sich Screenreader-Nutzer dort in der Regel über die Überschriftenstruktur orientieren. In Fällen, wo Tabellen nicht der wesentliche Inhalt einer Seite sind, kann es sinnvoll sein, auf den Einsatz von CAPTION zu verzichten. Sie sollten dann die Tabellen mit tatsächlichen Überschriften (hn) versehen. Wenn die Tabellen jedoch der wesentliche oder sogar der alleinige Inhalt sind, dann bietet sich CAPTION an. Für die Nutzung solcher Seiten stehen dem Screenreader-Nutzer eine ganze Reihe von spezialisierten Tastaturbefehlen zur Verfügung – so springt der verbreitete Screenreader JAWS duch das Drücken der Taste T automatisch zur ersten Tabelle einer Seite und würde eventuell davor stehende Überschriften überspringen, sodass unter Umständen wesentliche Informationen verpasst würden.
Innere Struktur mit THEAD, TBODY & TFOOT
Die Elemente THEAD (=Kopfzeile), TFOOT (=Fußzeile) und TBODY (=Tabellenkörper) sind die idealen Mittel, um Ihrer Tabelle mehr Struktur zu geben. Übrigens: diese dürfen auch mehrfach in einer Tabelle enthalten sein. Zudem lassen sie sich hervorragend per CSS formatieren: neben einem eigenen Aussehen für die einzelnen Tabellenbereiche können sie zum Beispiel überlange oder sehr breite Tabellen per overflow:auto; in schmalere Inhaltsspalten einpassen.
Dabei darf TFOOT, anders als sein Name vermuten lässt, nicht erst am Ende der Tabelle notiert werden, sondern muss vor TBODY erscheinen. Da dies unter Web-Entwicklern oftmals für Verwirrung sorgt verraten wir Ihnen hier den Grund dafür: für Medien wie zum Beispiel dem Ausdruck kann man im CSS angeben, ob die <thead>- und <tfoot>-Tags zu Beginn bzw. zum Ende jeder Seite wiederholt werden sollen. Um die Tabelle in einem Durchgang rendern zu können braucht der Browser also bereits zu Beginn der Tabelle die Information, ob neben dem <thead> auch ein <tfoot> enthalten ist.
Tabellen können durchaus mehrere <tbody>-Tags enthalten. Im folgenden Beispiel einer Bundesliga-Tabelle haben wir uns diese Möglichkeit zu Nutze gemacht und hiermit die Tabelle in die verschiedenen Bereiche (UEFA-Cup, Abstiegszone etc.) unterteilt. Jeder dieser Bereiche steht in einem eigenen tbody-Tag, die über eigene Klassen oder IDs identifiziert und dann unterschiedlich präsentiert werden können (Farben, Trennstriche per border etc.):
Zur genaueren Analyse finden Sie den Quelltext in einer separaten Datei: tabelle-3.html
Spalten gruppieren mit COLGROUP
Während THEAD, TFOOT und TBODY für die horizontale Unterteilung einer Tabelle in größere Bereiche zuständig sind, gibt es mit COLGROUP (Spaltengruppe) ebenfalls ein Element für die Unterteilung in vertikale Bereichen und mit COL ein Element, um gezielt einzelne Spalten in diesen Bereichen anzusprechen.
Diese Methode haben wir uns im folgenden Beispiel zu Nutze gemacht, um die Tabelle in die für den konkreten Anwendungsfall üblichen Spalten und Spaltengruppen zu unterteilen. Diese können in Folge per CSS so formatiert werden, dass die Platzierung immer rechtsbündig steht, der Verein hingegen linksbündig, sowie die weiteren Daten (Spiele, Siege, Unentschieden, Niederlagen, Tore, Tordifferenz und Punkte) wieder rechtsbündig.
Erreicht wird dies über den folgenden Code, der unmittelbar zu Beginn der Tabelle, d.h. nach dem eröffnenden <table>-Tag und einer eventuell vorhandenen <caption>, aber noch vor dem <thead> stehen sollte:
<colgroup><col class="platz"><col class="verein"></colgroup><colgroup><col class="bewegung"></colgroup><colgroup span="4" class="spiele"></colgroup><colgroup span="3" class="ergebnisse"></colgroup>
Hier sehen Sie schon die unterschiedlichen Varianten der Einteilung in Spaltengruppen: innerhalb des zwingend notwendigen COLGROUP (COL darf nicht für sich alleine stehen) können Sie entweder die betreffenden Spalten ausdrücklich angeben – in diesem Fall werden diese als einzelne <col> aufgelistet. Oder Sie geben an, für wie viele Spalten die Spaltengruppe gelten soll – in diesem Fall erhält <colgroup> ein SPAN-Attribut (<colgroup span="3">).
Eine Beschränkung hat das HTML-Tabellenmodell an dieser Stelle: Sie können COLGROUP nicht verschachteln, d.h. eine Spaltengruppe darf keine weiteren Spaltengruppen enthalten, sondern nur Spalten (COL). In der Praxis ist diese Beschränkung jedoch nicht so gravierend, da es kaum Datentabellen mit mehr als zwei Ebenen von Spaltenüberschriften gibt. Falls Sie tatsächlich Tabellen mit drei oder mehr Ebenen von Überschriftenzellen auszeichnen müssen, bleibt Ihnen nur noch der Rückgriff auf die Zuordnung per headers/id bei gleichzeitigen Verzicht auf COLGROUP.
Zeilen gruppieren mit ROWGROUP
Neben der Unterteilung in Bereiche per THEAD, TFOOT und TBODY sieht die HTML-Spezifikation noch eine zweite Variante vor: komischerweise ist dies kein der Logik von COLGROUP entsprechendes ROWGROUP-Element zur Identifizierung von Zeilengruppen – sondern rowgroup als möglichen Wert des scope-Attributs von TH oder TD. Nicht nur um Verwirrung zu vermeiden, sondern auch weil sich rowgroup und rowspan nicht über mehrere tbody hinweg erstrecken dürfen, sollten sie die Kombination beider Methoden vermeiden und sich im Einzelfall für das eine oder das andere entscheiden.
Im folgenden Screenshot sehen Sie eine zusätzliche Zelle (TH) vor der Tabelle, mit der die Abstiegszone markiert ist. Diese Zelle erstreckt sich über 3 Zeilen (der rein technische Part mit rowspan="3") und weist sich selbst als Überschrift für diese drei Zeilen aus (der inhaltliche Part mit scope="rowgroup"). Beachten Sie, dass auch hier die Vergabe von rowspan nicht mit der automatischen Zuweisung als Überschrift für bestimmte Zellen gleichzusetzen ist – dieses Attribut bestimmt nur die Position der Zelle im Tabellenraster. Wie bei colspan und COLGROUP wird hier die zusätzliche Angabe der rowgroup benötigt, um die Abstiegszone eindeutig zu definieren.
<table>[…]<tr><th rowspan="3" scope="rowgroup">Abstieg</th><th scope="row">16.</th><td scope="row">TSV 1860 München</td><td class="up">↑</td><td>34</td><td>7</td><td>8</td><td>19</td><td>41:60</td><td>−19</td><td>22</td></tr><tr><th>17.</th><td scope="row">1. FC Saarbrücken</td><td class="down">↓</td><td>34</td><td>6</td><td>10</td><td>18</td><td>39:70</td><td>−31</td><td>22</td></tr><tr><th>18.</th><td scope="row">FC St. Pauli</td><td></td><td>34</td><td>6</td><td>6</td><td>22</td><td>44:86</td><td>−42</td><td>18</td></tr></tbody><tfoot>[…]
Ausrichtung mit scope
In Teil 1 dieser Serie hatten wir bereits das scope-Attribut als einfache Alternative zu headers/id vorgestellt. Auch in komplexen Datentabellen hat dieses Attribut durchaus seine Berechtigung, wie wir im vorhergehenden Beispiel gesehen haben. Neben dem dort vorgestellten Wert "rowgroup" gibt es noch row (für einzelne Zeilen), col (für einzelne Spalten) und colgroup (für Gruppen von Spalten).
Eine Besonderheit des scope-Attributs ist, dass es nicht nur für Überschriftenzellen (TH), sondern auch für ganz normale Datenzellen (TD) vergeben werden kann. Wenn eine Datenzelle mit einem scope-Attribut ausgestattet ist, dann wird sie damit automatisch zur Überschriftenzelle für alle anderen Datenzellen, die innerhalb des angegebenen Bereichs (Zeile, Zeilengruppe, Spalte oder Spaltengruppe) liegen. Im folgenden Beispiel stehen die Platzierungen (1., 2., …) in <th scope="row"> und die Namen der Vereine in einer Datenzelle, die jedoch mit <td scope="row"> ausgezeichnet ist. Diese Methode hat den Vorteil, dass es zwar eine eindeutige Hierarchie gibt, aber ein Screenreader trotzdem den Platz und den Verein vorliest, wenn der Benutzer wissen möchte, wer am Ende der Saison vorne lag.
<table>[…]<tbody title="Deutscher Meister" class="meister"><tr><th scope="row">1.</th><td scope="row">1. FC Köln</td><td></td>[…]
Kategorisieren mit axis
Ein ganz anders Konzept als die bisher vorgestellten Elemente und Attribute verfolgt axis: bei diesem Attribut geht es nicht darum, Überschriftenzellen mit Datenzellen zu verknüpfen, sondern um das Filtern von Inhalten nach bestimmten Vorgaben. Im HTML 4.01-Standard steht dazu:
»Dieses Attribut kann dazu verwendet werden, eine Zelle in konzeptionelle Kategorien einzuordnen, die als Achsen in einem n-dimensionalen Raum betrachtet werden können. Benutzerprogramme können Benutzern Zugang zu diesen Kategorien gewähren (z.B. könnte der Benutzer nach allen Zellen fragen, die zu bestimmten Kategorien gehören, das Benutzerprogramm könnte eine Tabelle in Form eines Inhaltsverzeichnisses darstellen usw.).«
In der einschlägigen Literatur finden sich Hinweise, dass dieses Attribut rein hypothetisch und nicht implementiert sei. Der Grund dafür ist wahrscheinlich, dass dieses Attribut in den HTML-Spezifikationen und auch in den WCAG 1.0 als Methode beschrieben ist, mit der User Agents in ferner Zukunft mal etwas anfangen können:
»Label table elements with the ›scope‹, ›headers‹, and ›axis‹ attributes so that future browsers and assistive technologies will be able to select data from a table by filtering on categories.«
Allerdings sind seit der Veröffentlichung über zehn Jahre vergangen und axis wird in der Tat mittlerweile von aktuellen Screenreadern unterstützt. Was allerdings die Unterstützung des axis-Attributs mit der Barrierefreiheit zu tun hat will uns aber auch nach zehn Jahren nicht einleuchten. Der Vollständigkeit halber hier noch ein Beispiel, dass es dem Nutzer (oder auch einer Software) ermöglicht, Ergebnisse nach Spieltagen zu filtern:
<table>[…]<tr><th scope="row" class="r">1.</th><th scope="row">1. <abbr>FC</abbr> Köln</th><td class="gehtnicht">—</td><td axis="27. Spieltag">1:1</td><td axis="11. Spieltag">3:1</td><td axis="33. Spieltag">2:1</td><td axis="18. Spieltag">1:0</td><td axis="29. Spieltag">5:2</td><td axis="31. Spieltag">0:1</td><td axis="15. Spieltag">4:1</td><td axis="7. Spieltag">2:4</td><td axis="25. Spieltag">6:1</td><td axis="9. Spieltag">4:1</td><td axis="21. Spieltag">2:0</td><td axis="5. Spieltag">6:0</td><td axis="2. Spieltag">2:1</td><td axis="3. Spieltag">7:2</td><td axis="13. Spieltag">6:2</td><td axis="23. Spieltag">3:1</td><td axis="17. Spieltag">4:1</td><td>86:41</td><td>+45</td><td>48</td></tr>[…]
Abkürzungen und Zusatzinfos
Definitiv zum Thema ›Barrierefreiheit‹ gehört hingegen das abbr-Attribut (nicht zu verwechseln mit dem ABBR-Element!):
»Dieses Attribut sollte verwendet werden, um eine abgekürzte Form des Zellinhalts zur Verfügung zu stellen und könnte von Benutzerprogrammen dargestellt werden, wenn es anstelle des Zellinhalts sinnvoll ist. Abgekürzte Namen sollten kurz sein, weil Benutzerprogramme sie wiederholt darstellen könnten. Zum Beispiel könnten Sprachsythesizer den abgekürzten Kopf wiedergeben, der zu einer bestimmten Zelle gehört, bevor dieser Zellinhalt selbst wiedergegeben wird.«
Genau dies machen Screenreader auch, und in der folgenden Tabelle sehen Sie auch den Grund, warum Sie dieses Attribut bei Bedarf einsetzen sollten. In der Kopfzeile (Anm.: für sehende Nutzer ist dies die zweite Zeile, die erste Zeile ist ein <caption>-Tag) befinden sich fast ausschließlich Abkürzungen der Vereinsnamen, da die ausgeschriebenen Namen die Tabelle sprengen würden. Für Nutzer, die sich optisch orientieren ist dies auch kein Problem, denn bei der Tabelle handelt sich es um eine Kreuztabelle, die alle Spielpaarungen der Bundesligasaison auflistet; die Vereinsnamen können also bei Bedarf in der zweiten Spalte von links nachgelesen werden:
Beispielcode: kreuztabelle-2.html
In alternativen Ausgabeformen wie zum Beispiel einem Screenreader fehlt naturgemäß diese Möglichkeit der schnellen Orientierung. Wenn diese Tabelle nicht entsprechend aufbereitet wäre, dann würde eine Sprachausgabe in der Kopfzeile folgendes vorlesen:
Pl Verein Köl Bmg Her Vfb Düs Msv Fra Fck S04 Hsv Bvb Fcb Bsg Boc Svw 1860 Saa Stp Tore Diff Pkt
Problematisch werden diese Abkürzungen besonders dann, wenn der Nutzer sich innerhalb der Datenzellen orientiert und Zusatzinformationen benötigt, zu welcher Paarung das jeweilige Spielergebnis gehört. In einer Sprachausgabe würden hier zusätzlich die Inhalte der Überschriftenzellen vorgelesen, da diese mit scope oder mit headers & id zugeordnet sind (im Falle der Kreuztabelle sind dies immer zwei Überschriftenzellen, die sich auf eine Zelle beziehen).
In diesem Fall ist also der Einsatz des abbr-Attributs angezeigt, mit dem sich die Abkürzungen auflösen lassen. Sprachausgaben lesen dann statt der unverständlichen Abkürzung den im Wert des Attributs angegebenen Text vor. Wie dieses Attribut eingesetzt wird sehen Sie im folgenden Codelisting:
<thead><tr><th scope="col" abbr="Platz">Pl.</th><th scope="col">Verein</th><th scope="col" abbr="Erster Fußball-Club Köln">Köl</th><th scope="col" abbr="Borussia Mönchengladbach">BMg</th><th scope="col" abbr="Hertha BSC Berlin">Her</th><th scope="col" abbr="VfB Stuttgart">VfB</th><th scope="col" abbr="Fortuna Düsseldorf">Düs</th><th scope="col" abbr="MSV Duisburg">MSV</th><th scope="col" abbr="Eintracht Frankfurt">Fra</th><th scope="col" abbr="1. FC Kaiserslautern">FCK</th><th scope="col" abbr="Schalke 04">S04</th><th scope="col" abbr="Hamburger SV">HSV</th><th scope="col" abbr="Borussia Dortmund">BVB</th><th scope="col" abbr="FC Bayern München">FCB</th><th scope="col" abbr="Eintracht Brauschweig">Bsg</th><th scope="col" abbr="VfL Bochum">Boc</th><th scope="col" abbr="SV Werder Bremen">SVW</th><th scope="col" abbr="TSV 1860 München">1860</th><th scope="col" abbr="1. FC Saarbrücken">Saa</th><th scope="col" abbr="FC St. Pauli">StP</th><th scope="col">Tore</th><th scope="col" abbr="Tordifferenz">Diff.</th><th scope="col" abbr="Punkte">Pkt.</th></tr></thead>
Auch der umgekehrte Fall ist möglich. Im folgenden Codelisting sehen Sie die Vereinsnamen in ausgeschriebener Form. Ohne die Hinterlegung der Kurzform im abbr-Attribut würden Sprachausgaben immer den gesamten Text der zugeordneten Überschriftenzellen zusammen mit den Ergebnissen der jeweiligen Paarungen vorlesen – was auf Dauer sicher sehr ermüdend wäre. Da im konkreten Anwendungsfall die Kurzform genügt (»FC BVB 4:1« ist auch für Nicht-Fachleute ausreichend), werden die branchenüblichen Kurzformen der Vereinsnamen im abbr-Attribut hinterlegt und entsprechend vorgelesen:
<thead><tr><th scope="col" abbr="FC">1. FC Köln</th><th scope="col" abbr="Gladbach">Borussia Mönchengladbach</th><th scope="col" abbr="Hertha">Hertha BSC Berlin</th><th scope="col" abbr="Stuttgart">VfB Stuttgart</th><th scope="col" abbr="Düsseldorf">Fortuna Düsseldorf</th><th scope="col" abbr="MSV">MSV Duisburg</th><th scope="col" abbr="Eintracht">Eintracht Frankfurt</th><th scope="col" abbr="Lautern">1. FC Kaiserslautern</th><th scope="col" abbr="Schalke">Schalke 04</th><th scope="col" abbr="HSV">Hamburger SV</th><th scope="col" abbr="BVB">Borussia Dortmund</th><th scope="col" abbr="Bayern">FC Bayern München</th><th scope="col" abbr="Brauschweig">Eintracht Brauschweig</th><th scope="col" abbr="Bochum">VfL Bochum</th><th scope="col" abbr="Werder">SV Werder Bremen</th><th scope="col" abbr="60er">TSV 1860 München</th><th scope="col" abbr="Saarbrücken">1. FC Saarbrücken</th><th scope="col" abbr="Pauli">FC St. Pauli</th></tr></thead>
Was tun mit leeren Zellen?
Besondere Beachtung verdienen leere Zellen. Diese sind durchaus nötig und angebracht, z.B. weil es keine sinnvollen Daten für die betreffende Zelle gibt, sie aber aus technischen Gründen für den Aufbau des Tabellenrasters benötigt werden. Leere Zellen können sich aber auch aus der Struktur der Tabelle und ihrer Inhalte ergeben, wie am vorherigen Beispiel der Kreuztabelle zu sehen ist. Zerlegt man diese Tabelle in die Bereiche Hin- und Rückrunde, so erhält man zwei rechtwinklige Dreiecke mit den Vereinsnamen an den kurzen Seiten (Katheten). Entlang der langen Seite (Hypothenuse) entstehen zwangsläufig leere Zellen, da diese Paarungen nicht möglich sind (ein Verein kann nicht gegen sich selbst spielen):
Die Suche nach einem sinnvollen Indikator, der eine unmögliche Kombination anzeigt ohne selbst Inhalt zu sein, gestaltet sich einigermaßen spannend: 0 (Null) als Inhalt dieser Zelle scheidet aus, da diese Zahl als ein Wert an einer Stelle interpretiert werden könnte, wo kein Wert hingehört. Die Verwendung von geschützten Leerschritten ( ) scheint hier besser zu sein, weil sie sozusagen ein semantisches Vakuum darstellen. Allerdings werden solche Zellen im Screenreader als »Leere Zelle« angesagt, was keine Informationen transportiert, dass es sich bei Tasmania Berlin gegen Tasmania Berlin um eine unmögliche Kombination handelt.
Im konkreten Beispiel haben wir uns für den Einsatz eines — entschieden, aber wie bei vielen inhaltlichen Fragen der Barrierefreiheit können Sie in anderen Szenarien zu anderen Ergebnissen kommen – das wichtigste ist, sich überhaupt Gedanken über das Thema zu machen.
Der heilige Gral: Tabellen in PDF
Einfache Datentabellen sind auch in PDF-Dateien mit den gängigen Hilfsmitteln barrierefrei nutzbar, sofern sie getaggt sind. Das PDF-Format kennt, wie HTML, Tags zur Auszeichnung von Tabellenzeilen (<TR>), Überschriftenzellen (<TH>) und Datenzellen (<TD>). Moderne Screenreader sind zudem in der Lage, solche Tabellen in der gleichen Art und Weise zu verarbeiten wie entsprechend ausgezeichnete HTML-Tabellen.
Da man also ein gewisses Maß an Barrierefreiheit auch mit PDF erreichen kann, und weil viele Webinhalte in Form von PDFs zum Download angeboten werden, müssen auch an dieses Format die gleichen Maßstäbe angelegt werden wie an herkömmliche HTML-Inhalte. Dabei gilt es auch hier die gleichen Grenzen zu beachten, wie sie auch für allgemeine PDF-Dateien gelten:
- wenn Ihre PDF-Dateien ausschließlich zum Ausdruck gedacht sind und es eine zugängliche Alternative mit den identischen Inhalten gibt, dann müssen die PDF-Dateien selbstverständlich nicht barrierefrei sein.
- wenn Ihre (unzugänglichen) PDF nur archivierte Kopien von Dokumenten sind, bei denen Sie keinen Zugriff auf die originalen Ursprungsdokumente haben, ist der Aufwand für die nachträgliche Ausrüstung mit Tags oftmals durch nichts zu rechtfertigen.
Weitere Gründe für oder gegen PDF finden Sie in unserem Artikel Fakten und Meinungen zur Barrierefreiheit von PDF.
Wie generell bei PDF-Dokumenten gilt auch bei Tabellen in PDFs, dass das Ausgangsmaterial schon sauber angelegt und strukturiert sein muss. Aus Layout-Programmen wie QuarkXPress lässt sich in der Regel kein brauchbares PDF generieren, also bleibt nur der übliche Weg über InDesign oder Office-Pakete wie MS Office oder OpenOffice. Wie Sie mit diesen barrierefreie PDFs erstellen können wird in den folgenden Artikeln erklärt:
Fazit
Wie wir in dieser Serie aufgezeigt haben gibt es eine ganze Reihe teils konkurrierender Techniken, um barrierefreie Datentabellen zu erstellen. Für welche der vorgestellten Methoden Sie sich entscheiden ist stark vom konkreten Anwendungsfall und teilweise sogar von der Art der vorhandenen Daten abhängig.
Generell lassen sich aber die folgenden Regeln aufstellen:
- Kompaktes Markup ist besser als unnötig aufgeblähter Code.
- Der HTML-Code muss den etablierten Techniken für barrierefreie Datentabellen entsprechen, um eine reibungslose Nutzung in nicht-visuellen Medien zu ermöglichen. Dabei sollte der Code eigentlich nicht nach dem bewertet werden, was in einer bestimmten Version eines bestimmten Screenreaders funktioniert – dem Äquivalent von »Diese Seite ist für Browser XYZ optimiert«.
- Der HTML-Code muss eine akzeptable visuelle Präsentation ermöglichen. Techniken, die zwar in Hilfsmitteln nutzbar sind, jedoch für Nutzer ohne Hilfsmittel verborgen bleiben sind streng genommen keine barrierefreien Techniken.
- Für die Ersteller solcher Inhalte muss sich der Aufwand in vertretbaren Grenzen halten. Viele Tabellen werden zwar automatisch generiert, aber die manuelle Pflege der Daten oder die händische Erstellung der Tabellen bzw. der Templates sollte für den durchschnittlichen Redakteur oder Web-Entwickler keinen Aufwand verursachen der dazu führt, dass Accessibility-Kriterien nicht mehr beachtet werden.
Im letzten Teil der Serie finden Sie die gesammelten Codelistings und Hörproben mit dem Screenreader JAWS.