Vorschau · WordPress-freie Version von ReguKit
← Alle SOPs · Phase 3 · Inhalte barrierefrei machen
SOP 17

Tabellen

ProjektleitungGeschäftsführungITRecht
Was du hier machstDu lernst, wie du Tabellen barrierefrei erstellst und strukturierst, damit sie für alle Nutzer:innen verständlich und zugänglich sind.
VoraussetzungDu arbeitest mit tabellarischen Daten in Webinhalten, bist Entwickler:in, Content-Verantwortliche:r, QM oder CMS-Administrator:in.
Dauer / AufwandJe nach Komplexität der Tabelle, ca. 30 Minuten bis 2 Stunden für Erstellung und Prüfung.
Gesetzlich verpflichtend✅ Ja – Barrierefreiheit ist durch BFSG, EAA und WCAG 2.1 gefordert, besonders für maschinenlesbare und semantisch strukturierte Tabellen.
Nächster Schritt→ SOP 18: Alternativtexte für Bilder
0 von 5 Schritten erledigt0 %

Warum machst du das überhaupt?

Weil Tabellen nicht visuell, sondern strukturell verstanden werden müssen.

Für Screenreader-Nutzer:innen oder Menschen mit kognitiven Einschränkungen sind unsauber erstellte Tabellen unlesbar, da der Zusammenhang zwischen einer Zelle und ihrer Spalten- oder Zeilenüberschrift verloren geht.

Diese SOP hilft dir, Tabellen so aufzubauen, dass sie auch ohne Maus, ohne Sehen und ohne Layoutverständnis für alle Menschen funktionieren.

Am Ende hast du einen klaren Prozess, um Datentabellen technisch korrekt und verständlich zu strukturieren und auszuzeichnen.

So stellst du sicher, dass die Beziehungen zwischen den Daten für alle Nutzer:innen nachvollziehbar sind und auch von Screenreadern korrekt interpretiert werden können.

In deinem Text-Dokument mit einem Titel wie „“Dokumentation des Barrierefreiheit-Feedback-System“ .

Wenn du mit dieser SOP fertig bist, legst du dieses Dokument an und trägst die Ergebnisse dieser SOP dort ein.

  • Initialaufwand: 2–3 Stunden (für Einrichtung des Kanals, Erstellung der Tracking-Liste, Formulierung von Textbausteinen).
  • Laufend: 15–30 Minuten pro eingegangener Meldung.
  • Content: Plant und schreibt die Inhalte der Tabelle.
  • Dev / CMS: Sorgt für die korrekte technische Umsetzung der HTML-Struktur.
  • QM (Qualitätsmanagement): Testet die Tabelle mit Screenreadern und per Tastatur.

Wann musst du das machen?

Immer, wenn du echte Datentabellen erstellst, zum Beispiel:

  • Preislisten, Vergleichstabellen und Zeitpläne
  • Zuständigkeiten oder Matrix-Darstellungen
  • Tabellen in Produktbeschreibungen oder FAQs

Welches Gesetz verlangt das?

  • Barrierefreiheitsstärkungsgesetz (BFSG) / European Accessibility Act (EAA) : Fordern Maschinenlesbarkeit und eine semantische Struktur.
  • WCAG 2.1: Insbesondere die Erfolgskriterien:
  • 1.3.1 Info and Relationships
  • 1.3.2 Meaningful Sequence
  • 4.1.2 Name, Role, Value

Der Prozess im Detail

Schritt für Schritt – zum Aufklappen und Abhaken.

1Entscheide – Ist eine Tabelle wirklich notwendig?

Nicht alles, was in Spalten steht, ist eine Tabelle. Prüfe zuerst den Zweck.

Der Grundsatz lautet: Nur Daten gehören in Tabellen. Layouts gehören in CSS. Für einfache Aufzählungen von Vorteilen oder Merkmalen ist eine Liste oft die bessere und zugänglichere Wahl.

Oder anders gesagt: Wenn du Daten hast, die sinnvolle Kopfzeilen für Spalten und Zeilen erfordern, ist es wahrscheinlich eine Tabelle.

Wenn es sich um eine Aneinanderreihung von Informationen handelt, die auch untereinander stehen könnten, ist eine Liste besser.

2Strukturiere deine Tabelle so, dass sie barrierefrei ist

Hast du eine echte Datentabelle, musst du diese nun in das richtige Fundament gießen – und also in eine korrekte HTML-Struktur bringen. Sie sagt dem Screenreader, wie die Daten zusammenhängen.

  • Titel : Zeichnest du mit „<caption>“ aus: Gib der Tabelle eine Überschrift, die ihren Inhalt beschreibt.
  • Kopf und Körper (<thead>, <tbody>): Trenne den Kopfbereich vom Inhaltsbereich der Tabelle.
  • Überschriftenzellen (<th>): Markiere alle Spalten- und Zeilenüberschriften als <th>. Verwende das scope-Attribut, um ihre Zuständigkeit festzulegen (scope=“col“ für Spalten, scope=“row“ für Zeilen).
  • Datenzellen (<td>): Normale Zellen werden mit <td> ausgezeichnet.

Beispiel:

Eine Tabelle, die so aussieht:

Paket

Monatspreis

Leistungen

Basic

29 €

E-Mail-Support

Würdest du in Html wie folgt darstellen:

HTML

<table>

<caption [cite: 576]>Preise für Support-Pakete</caption>

<thead [cite: 576]>

<tr>

<th scope=“col“ [cite: 576]>Paket</th>

<th scope=“col“ [cite: 576]>Monatspreis</th>

<th scope=“col“ [cite: 576]>Leistungen</th>

</tr>

</thead>

<tbody [cite: 576]>

<tr>

<th scope=“row“ [cite: 576]>Basic</th>

<td [cite: 576]>29 €</td>

<td [cite: 576]>E-Mail-Support</td>

</tr>

</tbody>

</table>

Aber Achtung: in den meisten Fällen musst du das natürlich nicht in HTML machen – Tabellen erstellst du in einem graphischen Editor in deinem CMS. Was du aber machen musst, ist dir in der HTML-Ansicht anzuschauen, ob wirklich alle Elemente durch deinen graphischen Editor auch korrekt ausgezeichnet werden. Ansonsten kann ein Screenreader das nicht verstehen.

3Verbessere die Verständlichkeit weiterhin

Und nicht nur technisch kannst du die Verständlichkeit deiner Tabelle für unterstützende Technologien verbessern, sondern auch inhaltlich und sprachlich. Insbesondere, indem du folgende Techniken einsetzt (auch für Tabellen gilt natürlich das, was wir bereits in anderen SOPs über den Text gesagt haben):

  • Eindeutige Beschriftungen: Formuliere Spalten- und Zeilenbeschriftungen so, dass sie klar verständlich sind.
  • Keine Abkürzungen: Vermeide Abkürzungen oder erkläre sie.
  • Keine leeren Zellen: Leere Zellen können Screenreader-Nutzer:innen irritieren und bieten auch sonst keinen Mehrwert.
  • Keine verschachtelten Tabellen: Vermeide Tabellen innerhalb von Tabellen, da sie schwer zu interpretieren sind.
4Teste die Tabelle

Du bist fertig? Dann musst du wie üblich am Ende noch einmal die Funktionalität checken. Überprüfe das Ergebnis mit verschiedenen Methoden.

Mache einen Screenreader-Test: Navigiere durch die Tabelle und beantworte dir selbst folgende Fragen:

  • Kannst du erfassen, wo du dich befindest?
  • Werden die richtigen Überschriften vorgelesen?
  • Tastatur-Test: Kannst du Zelle für Zelle mit den Pfeiltasten navigieren?
  • Responsivität: Ist die Tabelle auf dem Smartphone noch lesbar und benutzbar?
5Wenn du willst: Biete eine alternative Darstellung an (bei Bedarf)

Das hier ist ein Schritt, den du nur in ausgewählten Fällen gehen musst.

Wenn eine Tabelle sehr komplex wird (z. B. mehr als 10 Spalten), kann sie selbst mit korrekter Struktur unübersichtlich werden.

Biete in solchen Fällen eine Alternative an. Das kann eine barrierefreie PDF- oder Textversion sein oder eine mobilfreundliche Accordion-Ansicht, bei der jede Zeile als eigener, aufklappbarer Block dargestellt wird.

Ergebnis

Am Ende dieser SOP hast du:

  • Tabellen, die auch mit Screenreader und Tastatur einwandfrei funktionieren.
  • Eine klare Struktur und eindeutige Bezeichnungen, die Zusammenhänge klar machen.
  • Inhalte, die wirklich zur Orientierung beitragen, statt zu verwirren.
  • Optional eine alternative Darstellung für besonders komplexe Fälle.

Copy-Paste-Baustein

Checkliste für barrierefreie Tabellen

Du hast die SOP gelesen und möchtest jetzt sicherstellen, dass deine Tabellen wirklich für alle nutzbar sind? Dann nutze diese schnelle Checkliste als Gedächtnisstütze bei der Erstellung oder Überprüfung deiner Tabellen. So vergisst du keine wichtigen Schritte und lieferst Top-Qualität!

Kopiere diese Checkliste in ein Word-Dokument und speichere sie in deinem Ordner ab!

Bevor du startest – die Grundsatzfrage:

  • Ist eine Tabelle überhaupt notwendig?
  • Ja: Es handelt sich um echte Daten , die sinnvolle Spalten- und Zeilenüberschriften benötigen.
  • Nein: Es sind eher Aufzählungen oder Layout-Elemente . Dann ist eine Liste wahrscheinlich besser geeignet.

Beim Erstellen deiner Tabelle – die technische Struktur:

  • Titel ( <caption> ): Hat deine Tabelle eine kurze, prägnante Überschrift, die den Inhalt beschreibt?
  • Kopf und Körper ( <thead> , <tbody> ): Sind Kopf- und Inhaltsbereich der Tabelle voneinander getrennt?
  • Überschriftenzellen ( <th> ): Sind alle Spalten- und Zeilenüberschriften als <th> markiert?
  • Scope-Attribut: Hast du scope="col" für Spaltenüberschriften und scope="row" für Zeilenüberschriften verwendet?
  • Datenzellen ( <td> ): Sind alle normalen Datenzellen korrekt als <td> ausgezeichnet?
  • HTML-Ansicht gecheckt? Hast du in deinem CMS die HTML-Ansicht geprüft, ob der grafische Editor alles korrekt umgesetzt hat?

Während des Befüllens – die sprachliche und inhaltliche Klarheit:

  • Eindeutige Beschriftungen: Sind alle Spalten- und Zeilenbeschriftungen klar und unmissverständlich formuliert?
  • Keine Abkürzungen: Hast du Abkürzungen vermieden oder sie direkt erklärt?
  • Keine leeren Zellen: Sind alle Zellen mit sinnvollen Informationen gefüllt (oder ggf. mit einem „N/A“ oder „keine Angabe“)?
  • Keine verschachtelten Tabellen: Hast du Tabellen innerhalb von Tabellen vermieden?

Nach der Fertigstellung – der abschließende Test:

  • Screenreader-Test: Kannst du mit einem Screenreader (oder einer Simulation) die Tabelle erfassen, die Position verstehen und werden die richtigen Überschriften vorgelesen?
  • Tastatur-Test: Kannst du Zelle für Zelle mit den Pfeiltasten navigieren?
  • Responsivität: Ist die Tabelle auch auf kleineren Bildschirmen (z.B. Smartphone) noch gut lesbar und bedienbar?

Optional – für sehr komplexe Fälle:

  • Alternative Darstellung vorhanden? Wenn die Tabelle sehr komplex ist (z.B. über 10 Spalten), hast du eine barrierefreie Alternative (z.B. PDF, Textversion, Accordion-Ansicht) angeboten?

Fragen & Antworten

Meine Tabelle hat zwei Spaltenüberschriftenreihen (z.B. Jahr und darunter Quartale). Wie gehe ich damit um, damit der Screenreader das versteht?

Das ist eine sehr gute Frage, die über die grundlegende Struktur hinausgeht! In solchen Fällen, wo du mehrere Hierarchieebenen bei den Spaltenüberschriften hast, benötigst du das headers -Attribut.

Du gibst jeder <th> -Zelle eine eindeutige id . Dann referenzierst du diese id s in den <td> -Zellen mit dem headers -Attribut, um die korrekte Zuordnung zu gewährleisten. Das ist komplexer als scope , aber für verschachtelte Überschriften unerlässlich. Ein Beispiel könnte so aussehen:

<table>

<caption>Umsatz nach Quartal und Jahr</caption>

<thead>

<tr>

<th rowspan=“2″>Region</th>

<th colspan=“2″>2023</th>

<th colspan=“2″>2024</th>

</tr>

<tr>

<th id=“q1-23″>Q1</th>

<th id=“q2-23″>Q2</th>

<th id=“q1-24″>Q1</th>

<th id=“q2-24″>Q2</th>

</tr>

</thead>

<tbody>

<tr>

<th>Nord</th>

<td headers=“q1-23″>100</td>

<td headers=“q2-23″>120</td>

<td headers=“q1-24″>130</td>

<td headers=“q2-24″>150</td>

</tr>

</tbody>

</table>

Am Ende sollte das Ganze etwa so aussehen:

Umsatz nach Quartal und Jahr

Region

2023

2024

Q1

Q2

Q1

Q2

Nord

100

120

130

150

Was mache ich, wenn mein CMS die scope-Attribute oder komplexere Strukturen wie headers nicht direkt unterstützt?

Das ist ein häufiges Problem in der Praxis! Wenn dein CMS diese Attribute nicht über die grafische Oberfläche anbietet, hast du meist folgende Möglichkeiten:

  • HTML-Ansicht nutzen: Gehe in die Quelltext-Ansicht (HTML-Ansicht) des Editors und füge die Attribute manuell ein. Das erfordert etwas HTML-Kenntnisse, ist aber der direkteste Weg, um Konformität zu erreichen.
  • Plug-ins/Erweiterungen: Prüfe, ob es für dein CMS Plug-ins oder Erweiterungen gibt, die die Barrierefreiheit von Tabellen verbessern und diese Attribute nachträglich hinzufügen können.
  • Entwickler-Support: Wenn die Tabelle sehr wichtig ist, kontaktiere eure Entwickler. Eventuell können sie eine angepasste Komponente oder ein spezielles Template bereitstellen, das diese HTML-Struktur automatisch erzeugt.
  • Alternative Darstellungsform: Wenn alle Stricke reißen und du die Tabelle nicht barrierefrei im CMS umsetzen kannst, ziehe ernsthaft in Betracht, eine barrierefreie Alternative anzubieten (wie in Schritt 5 deiner SOP beschrieben), zum Beispiel eine gut strukturierte Textversion oder eine zugängliche PDF-Datei.
Im Text heißt es %22leeren Zellen vermeiden%22. Was soll ich stattdessen eintragen, wenn wirklich keine Daten vorhanden sind?

Das ist wichtig, weil leere Zellen für Screenreader verwirrend sind und Nutzer im Unklaren lassen. Statt die Zelle leer zu lassen, solltest du einen Platzhalter verwenden, der den Zustand klar kommuniziert:

  • „N/A“ (Not Applicable / Nicht zutreffend)
  • „k.A.“ (keine Angabe)
  • „–“ (Gedankenstrich, wenn die Abwesenheit eines Wertes selbsterklärend ist und keine Verwechslungsgefahr besteht)
  • „entfällt“
  • „nicht verfügbar“

Wähle den Platzhalter, der am besten zum Kontext deiner Tabelle passt. Wichtig ist, dass er immer den gleichen Platzhalter für den gleichen Zustand verwendest, um Konsistenz zu gewährleisten.

Meine Tabelle wird auf dem Smartphone unübersichtlich. Gibt es über die Responsivität hinaus Tipps, wie ich sie mobilfreundlicher gestalten kann?

Absolut! Responsivität ist der erste Schritt, aber bei komplexen Tabellen reicht sie oft nicht aus. Hier sind weitere Ideen für mobile Ansichten:

  • Einzelne Zeilen als „Karten“: Eine gängige Methode ist, jede Tabellenzeile auf mobilen Geräten als eine Art „Karte“ oder Block darzustellen. Dabei werden die Spaltenüberschriften der Desktop-Ansicht zu Labels vor den jeweiligen Daten innerhalb dieses Blocks.
  • Beispiel: Statt | Paket | Preis | Leistung | , wird auf dem Handy:
  • Paket: Basic
  • Preis: 29 €
  • Leistungen: E-Mail-Support
  • Accordion-Ansicht: Ähnlich wie bei Karten, aber die Details jeder Zeile sind einklappbar, sodass der Nutzer nur die relevanten Informationen auf den ersten Blick sieht und bei Bedarf aufklappen kann.
  • Horizontales Scrollen: Wenn die Tabelle nicht anders darstellbar ist, kannst du sie in einen Container packen, der horizontales Scrollen erlaubt. Stelle sicher, dass die erste Spalte (oft die Zeilenüberschrift) fixiert bleibt, damit der Kontext beim Scrollen erhalten bleibt.
  • Wichtige Spalten zuerst: Ordne die Spalten so an, dass die wichtigsten Informationen zuerst kommen, da diese auf kleineren Bildschirmen oft am besten sichtbar sind.
Wann sollte ich eine Datentabelle überhaupt nicht verwenden, selbst wenn es sich um Daten handelt?

Es gibt tatsächlich Fälle, in denen eine Tabelle zwar Daten enthält, aber dennoch nicht die beste Wahl für die Darstellung ist:

  • Sehr kleine Datenmengen: Wenn du nur zwei oder drei Datenpunkte hast, die du einfach in einem Satz oder einer kurzen Liste zusammenfassen könntest (z.B. „Die Studie ergab X für Gruppe A und Y für Gruppe B.“), ist eine Tabelle oft überflüssig und macht den Text unnötig fragmentiert.
  • Narrative Daten: Wenn die Daten primär dazu dienen, eine Geschichte zu erzählen oder eine Entwicklung zu beschreiben, kann ein Fließtext mit integrierten Zahlen oder eine Infografik/Diagramm oft wirkungsvoller sein, als eine reine Datentabelle. Tabellen sind gut für Vergleiche und detaillierte Ansichten, aber nicht immer für die Übermittlung einer Botschaft.
  • Komplexe Beziehungen ohne klare Zeilen-/Spaltenzuordnung: Wenn die Daten keine klare, hierarchische Beziehung zueinander haben, die sich in Zeilen- und Spaltenüberschriften abbilden lässt, könnte eine Liste von Definitionen , ein Glossar oder eine Mindmap besser geeignet sein.