Barrierefreie Datentabellen und komplexe Inhalte umsetzen

Eine Tabelle ist für sehende Nutzer ein zweidimensionales Raster: Das Auge springt zwischen Spaltenüberschrift, Zeilenüberschrift und Datenzelle hin und her und stellt den Zusammenhang ganz nebenbei her. Ein Screenreader hat diese räumliche Übersicht nicht. Er liest Zelle für Zelle und muss bei jeder Datenzelle wissen, zu welcher Spalten- und Zeilenüberschrift sie gehört. Genau diese Beziehung verlangt WCAG 1.3.1 Info und Beziehungen: Informationen, Struktur und Beziehungen, die visuell vermittelt werden, müssen programmatisch bestimmbar sein (W3C/WAI). Fehlt die Auszeichnung, hört der Nutzer eine Folge zusammenhangloser Werte, ohne zu erfahren, ob es um einen Preis, ein Datum oder eine Menge geht. Damit wird eine an sich übersichtliche Information unbrauchbar - obwohl die Inhalte alle vorhanden sind und nur die Beziehung zwischen ihnen technisch fehlt.

Die Praxis zeigt, wie gross die Lücke ist. Im WebAIM Million Report hatten 2024 95,9% (WebAIM Million, 2024) aller untersuchten Startseiten erkennbare WCAG-Verstöße, im Schnitt 56,8 (WebAIM Million, 2024) pro Seite - ein Anstieg von 13,6% (WebAIM Million, 2024) gegenüber dem Vorjahr. Tabellen sind dabei ein eigener Problemfall: Wenn nur 16,8% (WebAIM Million, 2024) der Tabellen überhaupt gültig ausgezeichnet sind, bleibt die Mehrheit für assistive Technologien unverständlich. In Deutschland betrifft das viele Menschen unmittelbar: Ende 2023 lebten hier rund 7,9 Mio. (Statistisches Bundesamt, 2024) schwerbehinderte Menschen, weltweit haben rund 2,2 Mrd. (WHO, 2023) Menschen eine Sehbeeinträchtigung.

Eine zugängliche Datentabelle entsteht aus dem Zusammenspiel weniger, klar definierter Bausteine. Die folgende Übersicht fasst zusammen, was das Tables Tutorial der Web Accessibility Initiative und WCAG 1.3.1 verlangen (W3C/WAI). Diese Punkte prüfen wir im Rahmen unserer Leistungen systematisch ab.

Für die meisten Tabellen reicht die Kombination aus th, scope und caption vollständig aus. Erst wenn Kopfzellen über mehrere Spalten oder Zeilen reichen oder mehrere Überschriftsebenen ineinandergreifen, kommen headers und id hinzu. Entscheidend ist dabei die Reihenfolge der Arbeit: Zuerst klären Sie, ob es sich überhaupt um echte Daten handelt, dann legen Sie Kopf- und Datenzellen fest, und erst danach ergänzen Sie die feinere Zuordnung. Wer diese Schritte überspringt und gleich mit ARIA-Attributen nachbessert, erzeugt häufig mehr Probleme als er löst - native HTML-Semantik ist hier meist die robustere Grundlage. Diese semantische Auszeichnung baut auf denselben Grundlagen auf, die wir im Beitrag zur Screenreader-Optimierung der Website ausführlich behandeln.

Die häufigste Tabellenart hat genau eine Reihe Spaltenüberschriften, oft ergänzt um eine Spalte Zeilenüberschriften. Hier genügt es, die Kopfzellen mit th auszuzeichnen und mit scope die Richtung anzugeben: scope=col für Spaltenüberschriften, scope=row für Zeilenüberschriften. Der Screenreader liest dann zu jeder Datenzelle die passenden Überschriften vor - etwa Spalte Monatlich, Zeile Pro, Wert 19 Euro. Die caption gibt der gesamten Tabelle einen Titel, den assistive Technologien als Einstieg anbieten.

Sobald Kopfzellen über mehrere Spalten oder Zeilen reichen (colspan, rowspan) oder mehrere Überschriftsebenen vorhanden sind, reicht scope nicht mehr aus. Dann ist die Zuordnung nicht mehr streng horizontal oder vertikal möglich, und die Beziehung muss explizit hergestellt werden (W3C/WAI). Dafür erhält jede Kopfzelle eine eindeutige id, und jede Datenzelle listet im headers-Attribut die id-Werte aller für sie geltenden Überschriften auf - bei mehreren durch Leerzeichen getrennt. Der Screenreader liest dann zu jeder Zelle genau die zugeordneten Überschriften vor und verliert den Kontext nicht.

Wichtig ist, komplexe Tabellen wo möglich zu vermeiden: Oft lassen sich verschachtelte Überschriften in mehrere einfache Tabellen aufteilen, die jeweils mit scope auskommen. Eine einfache, klar gegliederte Tabelle ist nicht nur leichter auszuzeichnen, sondern auch für alle Nutzer verständlicher. Die korrekte Verknüpfung mehrerer Beziehungen über id und headers ist eng verwandt mit der sauberen Vergabe von Rollen und Zuständen, wie sie der Beitrag zu ARIA-Rollen, Zuständen und Live-Regions beschreibt.

Historisch wurden Tabellen oft missbraucht, um Seiten zu layouten - mit Zeilen und Spalten als Gestaltungsraster statt als Datenstruktur. Das ist heute ein anerkannter Fehler: Eine Tabelle, die nur dem Layout dient, aber th-Elemente, eine caption oder ein nicht leeres summary-Attribut enthält, verstösst gegen WCAG 1.3.1, weil sie semantische Auszeichnung rein zur Präsentation nutzt (W3C/WAI, F46). Screenreader kündigen eine solche Tabelle als Datentabelle an und verwirren den Nutzer mit Zeilen- und Spaltenansagen, wo es gar keine Daten gibt.

Die Regel ist einfach: Tabellen-Markup nur für echte tabellarische Daten verwenden. Für reines Layout sind CSS-Grid und Flexbox die richtige Wahl, weil sie die Präsentation von der Struktur trennen und die semantische Bedeutung der HTML-Tabellenelemente erhalten (W3C/WAI). Wenn ausnahmsweise doch eine Layout-Tabelle nötig ist, darf sie weder th noch caption noch summary enthalten und sollte mit role=presentation neutralisiert werden, damit assistive Technologien sie gar nicht erst als Datentabelle ankündigen. In der Praxis stammen viele dieser Altlasten aus älteren Vorlagen und Newsletter-Templates, die ursprünglich für E-Mail-Layouts gedacht waren und unverändert in Webseiten übernommen wurden. Die saubere Trennung von Inhalt und Darstellung ist auch ein zentrales Thema in unserem Beitrag zu barrierefreien Formularen und Validierung.

Breite Datentabellen sind auf kleinen Bildschirmen eine Herausforderung. Die häufigste, aber problematische Lösung blendet auf Mobilgeräten Spalten aus oder bricht die Tabelle in Karten um - und verliert dabei oft die Beziehung zwischen Überschrift und Wert. Genau das warnt das Tables Tutorial der Web Accessibility Initiative an: Spalten zu stapeln oder zu verstecken darf die programmatischen Beziehungen nicht zerstören (W3C/WAI). Wenn ein responsives Layout aus einer Tabelle ein Stapel-Layout macht, müssen die Überschriften für jeden Wert weiterhin verfügbar sein.

Bewährt haben sich zwei Wege: Erstens, die Tabelle in einem horizontal scrollbaren Container zu belassen, sodass ihre Struktur unangetastet bleibt - der Container sollte tastaturfokussierbar und mit einem zugänglichen Namen versehen sein. Zweitens, bei einem Karten-Layout die Überschrift visuell pro Wert zu wiederholen, etwa über data-Attribute und CSS, sodass weiterhin klar ist, welcher Wert wozu gehört. Aus der Begleitung von 50+ (Projekterfahrung) Projekten wissen wir, dass die meisten Tabellenprobleme nicht auf dem Desktop, sondern in der mobilen Umsetzung entstehen - dort, wo Spalten unter Zeitdruck einfach ausgeblendet werden.

Datentabellen berühren vor allem WCAG 1.3.1 Info und Beziehungen, weil hier die gesamte Spalten- und Zeilenlogik programmatisch verfügbar sein muss (W3C/WAI). Da automatische Prüfwerkzeuge nur etwa ein Drittel bis die Hälfte der WCAG-Anforderungen überhaupt testen können (W3C/WAI), zeigt sich erst im manuellen Test mit dem Screenreader, ob eine Tabelle ihre Beziehungen wirklich vermittelt. Wer Tabellen von Anfang an mit th, scope, caption und bei Bedarf headers und id baut, vermeidet eine ganze Klasse wiederkehrender Fehler - und schafft eine verlässliche Grundlage für das WCAG-Audit. Verwandte Muster für dynamische und überlagernde Inhalte behandeln wir in den Beiträgen zu barrierefreien Modals und Overlays und barrierefreien Fehlermeldungen und Statusmeldungen.