Was sind häufige WCAG-Fehler bei Tabellen auf Websites?

Häufige WCAG-Fehler bei Tabellen auf Websites entstehen vor allem durch fehlende oder falsch eingesetzte Kopfzellen, das Fehlen einer Tabellenbeschriftung sowie eine unklare Struktur, die Screenreader nicht korrekt interpretieren können. Diese Fehler betreffen sowohl einfache Datentabellen als auch komplexe mehrstufige Strukturen. Der folgende Artikel beantwortet die wichtigsten Fragen rund um barrierefreie Tabellen, typische WCAG-Verstöße und deren Prüfung.

Welche Elemente machen eine Tabelle barrierefrei zugänglich?

Eine barrierefreie Tabelle benötigt mindestens eine Beschriftung (<caption>), klar ausgezeichnete Kopfzellen (<th>) mit korrektem scope-Attribut sowie eine semantisch sinnvolle Trennung von Tabellenkopf (<thead>), Tabellenkörper (<tbody>) und gegebenenfalls Tabellenfuß (<tfoot>). Nur so können assistive Technologien die Daten in ihrem Zusammenhang vorlesen.

Im Einzelnen sind folgende Elemente entscheidend:

• Caption: Die Tabellenüberschrift beschreibt den Inhalt der Tabelle und wird von Screenreadern als Erstes vorgelesen. Ohne sie fehlt Nutzenden mit Sehbehinderung der entscheidende Kontext.
• Kopfzellen mit scope: Das Attribut scope="col" oder scope="row" legt fest, ob eine Kopfzelle eine Spalte oder eine Zeile beschreibt. Fehlt es, kann ein Screenreader nicht zuverlässig zuordnen, welcher Wert zu welcher Kategorie gehört.
• Semantische Struktur: Die Verwendung von <thead>, <tbody> und <tfoot> gliedert die Tabelle logisch und unterstützt die Navigation mit Tastatur und Screenreader.
• Keine Layouttabellen: Tabellen dürfen ausschließlich für tabellarische Daten eingesetzt werden, nicht zur visuellen Anordnung von Seitenelementen. Layouttabellen verwirren assistive Technologien erheblich.
• Korrekte Zellzuordnung bei verbundenen Zellen: Werden Zellen mit colspan oder rowspan zusammengeführt, müssen die Kopfzuordnungen über id– und headers-Attribute explizit definiert werden.

Diese Anforderungen sind in den WCAG-Erfolgskriterien 1.3.1 (Info und Beziehungen) und 4.1.1 (Syntaxanalyse) verankert und gelten für alle Konformitätsstufen ab Level A.

Warum scheitern Screenreader an schlecht strukturierten Tabellen?

Screenreader navigieren Tabellen, indem sie zellen- und zeilenweise durch die Struktur wandern und dabei auf maschinenlesbare Metadaten angewiesen sind. Fehlen Kopfzellen oder scope-Attribute, liest der Screenreader lediglich rohe Zahlenwerte oder Texte vor, ohne den Zusammenhang herzustellen. Nutzende hören dann beispielsweise „42″ ohne zu wissen, ob es sich um einen Preis, eine Menge oder ein Datum handelt.

Das Problem verschärft sich in folgenden Situationen:

• Fehlende Kopfzellen-Auszeichnung: Wenn <td> statt <th> für Überschriften verwendet wird, erkennt der Screenreader keine Kopfzeile. Jede Zelle wird gleichwertig behandelt, was die Orientierung unmöglich macht.
• Verschachtelte Tabellen: Tabellen innerhalb von Tabellen sind für Screenreader schwer zu verarbeiten und führen häufig zu Navigationsfehlern oder unverständlichen Ausgaben.
• Fehlende Zusammenfassung bei komplexen Tabellen: Ohne eine erklärende Beschriftung oder ein summary-Attribut (bei WCAG 2.0) müssen Nutzende die gesamte Tabelle erkunden, bevor sie deren Zweck verstehen.
• Leere Kopfzellen: Eine leere <th>-Zelle am Anfang einer Tabelle, die optisch als Eckelement dient, sollte mit aria-label="" oder einem unsichtbaren Textinhalt versehen werden, damit Screenreader sie nicht als inhaltsloses Element überspringen.

Kurz gesagt: Ein Screenreader ist auf korrekte HTML-Semantik angewiesen. Optische Gestaltung allein, etwa fettgedruckte Zellen als visuelle Überschriften, wird von assistiven Technologien nicht interpretiert.

Was sind die häufigsten WCAG-Verstöße bei Datentabellen?

Die häufigsten WCAG-Verstöße bei Datentabellen sind das Fehlen von <th>-Elementen, das Weglassen des scope-Attributs, eine fehlende <caption> sowie der Einsatz von Tabellen für Layoutzwecke. Diese Fehler treten in der Praxis besonders häufig auf, weil sie für sehende Nutzende unsichtbar bleiben und deshalb bei visuellen Tests nicht auffallen.

Eine Übersicht der verbreitetsten Fehlertypen:

1. Fehlende oder falsch platzierte Kopfzellen: Kopfzeilen werden mit <td> statt <th> ausgezeichnet, oder <th>-Elemente werden ohne scope-Attribut eingesetzt.
2. Keine Tabellenbeschriftung: Das <caption>-Element fehlt vollständig, sodass der Zweck der Tabelle nicht programmatisch vermittelt wird.
3. Falsche Verwendung von colspan und rowspan: Verbundene Zellen ohne explizite headers-Referenzen machen die Zuordnung für Screenreader unklar.
4. Layouttabellen ohne ARIA-Kennzeichnung: Tabellen, die nur zur optischen Anordnung dienen, fehlt das Attribut role="presentation", das Screenreader anweist, die Tabellenstruktur zu ignorieren.
5. Fehlende Zeilenzusammenfassungen bei komplexen Strukturen: Bei Tabellen mit mehreren Kopfebenen fehlen die id– und headers-Verknüpfungen, die eine eindeutige Zellzuordnung ermöglichen.
6. Unzureichender Farbkontrast in Tabellenzellen: Auch innerhalb von Tabellen gilt das WCAG-Erfolgskriterium 1.4.3, das ein Kontrastverhältnis von mindestens 4,5:1 für normalen Text vorschreibt.

Wer eine Barrierefreiheits-Prüfung für Websites durchführt, wird feststellen, dass Tabellenfehler zu den am häufigsten automatisiert erkennbaren Problemen gehören und gleichzeitig zu den am leichtesten behebbaren.

Wie unterscheiden sich Anforderungen für einfache und komplexe Tabellen?

Einfache Tabellen haben eine einzige Kopfzeile und eine einzige Kopfspalte; hier genügt die Verwendung von <th scope="col"> und <th scope="row">. Komplexe Tabellen mit mehreren Kopfebenen, verbundenen Zellen oder mehrdimensionalen Strukturen erfordern zusätzlich explizite id– und headers-Attribute, um jede Datenzelle eindeutig ihren Überschriften zuzuordnen.

Anforderungen an einfache Tabellen

Eine einfache Tabelle besteht aus einer klar definierten Kopfzeile und gegebenenfalls einer Kopfspalte. Die Anforderungen sind überschaubar:

• Kopfzellen mit <th> auszeichnen
• scope="col" für Spaltenüberschriften, scope="row" für Zeilenüberschriften vergeben
• <caption> als Tabellenbeschriftung einfügen
• <thead> und <tbody> zur strukturellen Gliederung verwenden

Anforderungen an komplexe Tabellen

Komplexe Tabellen entstehen, wenn Zellen mehrere Kopfebenen haben, etwa bei Tabellen mit gruppierten Spalten oder verschachtelten Kategorien. Hier reicht scope allein nicht mehr aus:

• Jede Kopfzelle erhält ein eindeutiges id-Attribut.
• Jede Datenzelle verweist über das headers-Attribut auf alle zugehörigen Kopfzellen.
• Verbundene Zellen (colspan, rowspan) müssen so eingesetzt werden, dass die Zuordnung logisch und maschinenlesbar bleibt.
• Eine erklärende <caption> ist besonders wichtig, da die Struktur für Nutzende ohne visuelle Übersicht schwer erfassbar ist.

Die WCAG empfehlen generell, komplexe Tabellen, wenn möglich, in mehrere einfachere Tabellen aufzuteilen, da dies die Barrierefreiheit erheblich verbessert und gleichzeitig die Wartbarkeit des Codes erleichtert.

Wie lassen sich WCAG-Fehler in Tabellen automatisiert erkennen?

WCAG-Fehler in Tabellen lassen sich automatisiert erkennen, indem spezialisierte Barrierefreiheits-Testwerkzeuge den HTML-Quellcode auf fehlende <th>-Elemente, ein abwesendes scope-Attribut, fehlende <caption>-Elemente und Layouttabellen ohne ARIA-Kennzeichnung prüfen. Automatisierte Tests decken typischerweise die technisch prüfbaren Aspekte ab, während inhaltliche Fragen wie die Sinnhaftigkeit einer Beschriftung manueller Beurteilung bedürfen.

Automatisierte Barrierefreiheits-Scans analysieren den DOM einer Seite und wenden regelbasierte Prüfungen an. Für Tabellen bedeutet das konkret:

• Prüfung, ob <th>-Elemente vorhanden und korrekt positioniert sind
• Überprüfung des scope-Attributs auf zulässige Werte (col, row, colgroup, rowgroup)
• Erkennung von Tabellen ohne <caption> oder aria-label
• Identifikation von Layouttabellen, denen role="presentation" fehlt
• Prüfung auf leere Kopfzellen und fehlende headers-Verknüpfungen bei komplexen Strukturen

Wichtig ist zu verstehen, dass automatisierte Tests nach Schätzungen aus der Forschung, unter anderem einer Übersicht der Universität Bielefeld, etwa 30 bis 50 Prozent aller Barrierefreiheitsprobleme abdecken. Ob eine Tabellenbeschriftung inhaltlich sinnvoll ist oder ob die sichtbare Reihenfolge der Zellen der HTML-Struktur entspricht, lässt sich nur durch manuelle Prüfung beurteilen. Ein gutes Ergebnis im automatisierten Scan ist daher eine notwendige, aber keine hinreichende Bedingung für vollständige Barrierefreiheit.

Für eine umfassende Prüfung der Website auf Barrierefreiheit empfiehlt sich deshalb immer eine Kombination aus automatisierten Scans und gezielten manuellen Tests, beispielsweise der Navigation durch Tabellen ausschließlich mit der Tastatur.

Wann gilt eine Tabelle als BFSG-konform?

Eine Tabelle gilt im Sinne des Barrierefreiheitsstärkungsgesetzes (BFSG) als konform, wenn sie die Anforderungen der WCAG 2.1 auf Konformitätsstufe AA erfüllt. Das bedeutet: korrekte semantische Auszeichnung, programmatisch vermittelbare Struktur und ausreichende Farbkontraste. Das Bestehen eines automatisierten Scans allein stellt keine rechtliche Konformität sicher, da manuelle Prüfaspekte hinzukommen.

Das BFSG, das seit Juni 2025 für viele Produkte und Dienstleistungen gilt, verweist auf die europäische Norm EN 301 549, die ihrerseits auf den WCAG 2.1 Level AA aufbaut. Für Tabellen auf Websites bedeutet das konkret, dass folgende WCAG-Erfolgskriterien eingehalten sein müssen:

• 1.3.1 Info und Beziehungen (Level A): Strukturelle Informationen, also welche Zelle zu welcher Überschrift gehört, müssen programmatisch bestimmbar sein.
• 1.3.2 Bedeutungsvolle Reihenfolge (Level A): Die Lesereihenfolge der Zellen muss der inhaltlichen Logik entsprechen.
• 1.4.3 Kontrast (Minimum) (Level AA): Text in Tabellenzellen muss das Mindestkontrastverhältnis einhalten.
• 4.1.1 Syntaxanalyse (Level A): Der HTML-Code muss valide sein, damit Screenreader die Struktur korrekt interpretieren können.

Organisationen, die eine offizielle Bestätigung der Konformität benötigen, können eine Prüfung nach dem BITV-Prüfverfahren durch Mitglieder des BITV-Test-Prüfverbunds beauftragen. Ein eigener automatisierter Test im Vorfeld ist dennoch sinnvoll: Grobe Fehler sollten vor einem kostenpflichtigen Audit behoben sein, und während der Umsetzung von Maßnahmen muss kontinuierlich geprüft werden können, ob Änderungen den gewünschten Effekt haben.

Wie decareto bei der Erkennung von WCAG-Fehlern in Tabellen hilft

Unsere Plattform decareto unterstützt Agenturen, Compliance-Teams und Datenschutzbeauftragte dabei, Tabellenfehler und andere Barrierefreiheitsprobleme effizient zu identifizieren und zu dokumentieren. Konkret bieten wir:

• Automatisierte Barrierefreiheits-Scans: Wir prüfen Websites inklusive Unterseiten auf WCAG-Verstöße, darunter fehlende Kopfzellen, ein abwesendes scope-Attribut und Layouttabellen ohne ARIA-Kennzeichnung. Scans laufen in Minuten statt Stunden.
• Priorisierung nach Schweregrad: Jedes gefundene Problem wird nach Schweregrad eingestuft (kritisch, schwerwiegend, mittel, geringfügig), damit Entwicklungsteams wissen, was zuerst behoben werden muss.
• Konkrete Handlungsempfehlungen: Zu jedem Tabellenfehler liefern wir verständliche Hinweise zur Behebung, inklusive CSS-Selektor und HTML des problematischen Elements sowie, wo möglich, einen Screenshot des Problembereichs.
• Manuelle Tests integrierbar: Da automatisierte Scans nicht alle Barrierefreiheitsprobleme erkennen können, ermöglicht decareto die Erfassung manuell gefundener Probleme direkt im Report.
• Kontinuierliche Überwachung: Hunderte Websites lassen sich dauerhaft beobachten; bei Änderungen werden automatische Benachrichtigungen ausgelöst, sodass neue Barrieren sofort erkannt werden.
• Whitelabel-Reports: Externe Dienstleister können Reports unter eigenem Logo an Kunden weitergeben.

Möchten Sie Ihre Website auf WCAG-Fehler in Tabellen und weitere Barrierefreiheitsprobleme prüfen? Jetzt kostenlos testen und in wenigen Minuten einen ersten Überblick über den Barrierefreiheitsstatus Ihrer Website erhalten.

Dieser Text wurde mit Hilfe von KI erstellt und könnte Fehler beinhalten.

Ähnliche Artikel

• Welche Datenschutzlücken entstehen durch unsichere Cookie-Einbindungen?
• Welche Rechtsgrundlage muss meine Website für die Verarbeitung personenbezogener Daten nachweisen können?
• Welche Barrierefreiheitsprobleme entstehen durch fehlende Skip-Links?
• Wie erkennt man Barrierefreiheitsprobleme bei Dropdown-Menüs?
• Was sind typische Barrierefreiheitsprobleme bei Suchfunktionen?