WCAG & BFSG · WCAG-Referenz: Wahrnehmbar

WCAG 1.3.1: Info und Beziehungen

Q: Muss jede visuelle Hervorhebung im Markup stehen?

Nein – gemeint sind Hervorhebungen, die Bedeutung tragen. Ein farbiger Akzent aus Designgründen braucht kein Markup. Sobald die Hervorhebung aber sagt „das hier ist wichtig“ oder „das hier ist eine Überschrift“, muss sie programmatisch ermittelbar sein – über , oder ein echtes Überschriftenelement.

Von Jakob Sommer Zuletzt geändert am 20. Juli 2026

WCAG 1.3.1 verlangt, dass jede Struktur, die man optisch erkennt – Überschriften, Listen, Tabellen, Feldgruppen, Hervorhebungen –, auch programmatisch im Markup steht und nicht nur im Stylesheet. Was für Sehende eine Beziehung ist, muss für Maschinen auslesbar sein.

(Englisch: Info and Relationships.)

Stufe	Prinzip	Teil der WCAG seit	Rechtlich verbindlich?
A	Wahrnehmbar	2.0 (2008)	Ja – über EN 301 549 in BFSG & BITV

Das Wichtigste in Kürze

1.3.1 ist das am häufigsten verletzte Kriterium – dabei behebt sauberes HTML die meisten Fälle fast von selbst.
Die Faustregel: Wenn eine Beziehung nur durch Schriftgröße, Fettung, Einrückung, Farbe oder Position entsteht, ist sie für assistive Technologien nicht vorhanden.
Der BITV-Test zerlegt 1.3.1 in acht Prüfschritte (1.3.1a bis 1.3.1h): Überschriften, Listen, Zitate, Inhaltsgliederung, Datentabellen, Zuordnung von Tabellenzellen, Layouttabellen und Formularbeschriftungen (Stand Juli 2026).
Ein fettes <div> ist keine Überschrift, drei Absätze mit Bindestrich sind keine Liste, und ein Text neben einem Feld ist kein Label.
Das Kriterium wird in beide Richtungen geprüft: Was wie eine Überschrift aussieht, muss eine sein – und was als Überschrift ausgezeichnet ist, muss inhaltlich eine sein.
Der schnellste Selbsttest ist die Überschriftenliste im Screenreader: Was dort fehlt, existiert für die Struktur nicht.

Warum reicht fett formatierter Text nicht als Überschrift?

Der Normtext verlangt, dass Informationen, Struktur und Beziehungen, die durch die Darstellung vermittelt werden, programmatisch ermittelbar sind – oder in Text verfügbar. Übersetzt in Alltagssprache: Wenn Sehende eine Beziehung erkennen, müssen Maschinen sie auslesen können.

Das betrifft sechs Bereiche, und in etwa dieser Reihenfolge fallen sie in Audits auch auf:

Überschriften: Eine Überschrift ist ein <h1> bis <h6> – und umgekehrt darf kein <h2> gesetzt werden, nur weil ein Text groß aussehen soll.
Listen: Aufzählungen sind <ul> oder <ol>, damit der Screenreader „Liste mit 6 Einträgen“ ansagen kann. Diese Zahl ist die eigentliche Information.
Datentabellen: Kopfzellen sind <th> mit scope, damit zu jeder Zelle der passende Spalten- und Zeilenkopf gemeldet wird.
Formulare: Jedes Feld hat ein verknüpftes <label for>, zusammengehörige Felder stehen in <fieldset> mit <legend>.
Hinweise und Fehler: Was zu einem Feld gehört, wird per aria-describedby verbunden – nicht nur danebengestellt.
Gliederung der Seite: Bereiche liegen in Landmarks (header, nav, main, footer), nicht in nummerierten <div>-Schachteln.

Zwei Karten nebeneinander mit identischer optischer Darstellung. Links, rot markiert: Struktur nur im CSS. Man sieht die Überschrift Lieferadresse, einen Absatz und zwei Zeilen mit Gedankenstrich. Der Quelltext darunter zeigt drei div-Elemente, eines davon mit der Klasse h2-look. Die Überschriftenliste im Screenreader meldet in roter Schrift: Keine Überschriften gefunden, keine Listen gefunden. Rechts, grün markiert: Struktur im Markup. Optisch dasselbe Bild, der Quelltext zeigt aber ein h2-Element und eine ul-Liste mit zwei li-Einträgen. Die Überschriftenliste meldet H2 Lieferadresse und Liste mit zwei Einträgen. — Identisch auf dem Bildschirm, grundverschieden im Screenreader – genau diese Lücke meint 1.3.1.

Ein Punkt, der oft für Streit sorgt: Visuelle Hervorhebung allein genügt nicht, aber sie ist auch nicht verboten. Ein <strong> transportiert Wichtigkeit programmatisch, ein <span class="bold"> nicht. In der deutschen Prüfpraxis wird Fettung im Fließtext trotzdem selten bemängelt – kritisch wird es dort, wo die Hervorhebung eine Struktur ersetzt, etwa als Pseudo-Überschrift über einem Abschnitt. Den vollen Wortlaut samt aller ausreichenden Techniken führt das Understanding-Dokument des W3C zu 1.3.1 auf.

Wen betrifft es besonders?

Alle, die eine Seite nicht flächig sehen. Screenreader-Nutzer navigieren in Sprüngen: von Überschrift zu Überschrift, von Landmark zu Landmark, von Tabelle zu Tabelle. Ohne echte Strukturelemente gibt es nichts zu springen, und aus einer zweiminütigen Orientierung wird ein zehnminütiges Durchhören von oben.

Auf einer Braillezeile ist die Semantik zusätzlich die einzige Quelle für Betonung und Ebene – Schriftgröße gibt es dort nicht. Menschen mit kognitiven Einschränkungen profitieren von Reader-Modi und Vorlesefunktionen, die ebenfalls auf Struktur angewiesen sind. Und Suchmaschinen und KI-Systeme lesen exakt dieselben Signale: Eine Seite ohne Überschriftenstruktur ist auch für sie ein Textklumpen.

Richtig & falsch im Code

<!-- Falsch: Struktur lebt nur im Stylesheet -->
<div class="heading-2">Lieferadresse</div>
<div>– Straße und Hausnummer</div>
<div>– Postleitzahl und Ort</div>

<!-- Richtig: dieselbe Optik, echte Struktur -->
<h2>Lieferadresse</h2>
<ul>
  <li>Straße und Hausnummer</li>
  <li>Postleitzahl und Ort</li>
</ul>

<!-- Falsch: Label steht nur daneben, Fehler nur darunter -->
<span>Postleitzahl</span>
<input name="plz" />
<p class="error">Bitte fünf Ziffern eingeben.</p>

<!-- Richtig: Feld, Beschriftung und Fehlermeldung sind verbunden -->
<label for="plz">Postleitzahl</label>
<input id="plz" name="plz" autocomplete="postal-code"
       aria-describedby="plz-fehler" aria-invalid="true" />
<p id="plz-fehler">Die Postleitzahl muss aus fünf Ziffern bestehen.</p>

<!-- Richtig: Datentabelle mit zugeordneten Kopfzellen -->
<table>
  <caption>Öffnungszeiten der Filialen</caption>
  <tr><td></td><th scope="col">Mo–Fr</th><th scope="col">Sa</th></tr>
  <tr><th scope="row">Hauptstraße</th><td>9–18 Uhr</td><td>9–14 Uhr</td></tr>
</table>

Ohne scope sagt der Screenreader in der letzten Zelle nur „9 bis 14 Uhr“. Mit scope sagt er „Hauptstraße, Samstag, 9 bis 14 Uhr“ – und erst das ist die Information. Für mehrstufige Kopfzeilen gibt es komplexe Datentabellen mit headers und id.

So testest du es

Überschriftenliste ziehen: In NVDA mit NVDA + F7, im Browser alternativ mit der Erweiterung HeadingsMap. Bildet die Liste den Inhalt ab – ohne Lücken, ohne Ebenensprünge, ohne Mogel-Ebenen?
CSS abschalten: Im Browser das Stylesheet deaktivieren (in Firefox unter Ansicht › Webseiten-Stil › Kein Stil). Bleibt eine lesbare, gegliederte Dokumentstruktur übrig, stimmt das Markup.
Formulare mit dem Screenreader durchgehen: Wird zu jedem Feld die Beschriftung angesagt? Werden Hinweise und Fehlermeldungen mit vorgelesen?
Tabellen zellenweise prüfen: Mit Strg + Alt + Pfeiltasten durch eine Datentabelle navigieren – kommen zu jeder Zelle die Kopfzellen mit?
Automatisch gegenprüfen: axe findet fehlende Labels, kaputte Tabellenzuordnungen und Listen-Imitate. Was es nicht findet: eine Überschriftenstruktur, die zwar valide ist, aber am Inhalt vorbeigeht.

Den maschinell prüfbaren Teil – eine h1, keine Ebenensprünge, genau ein main – nimmt dir der Struktur-Check ab.

Häufiger Fehler in der Praxis

Der häufigste Befund in deutschen Audits ist die Pseudo-Überschrift: ein <p> oder <div> in 22 Pixeln, fett, mit Abstand darüber. Für das Auge eine Überschrift, im Screenreader ein Absatz wie jeder andere. Meist entsteht das nicht aus Nachlässigkeit, sondern aus dem Redaktionssystem heraus – irgendwann hat jemand festgestellt, dass die H2-Formatierung im Editor „zu groß“ aussieht, und seitdem wird von Hand fett formatiert. Das kriegt man nur weg, wenn die Überschriftenstile im Editor genauso aussehen wie später auf der Seite.

Der zweite Klassiker läuft andersherum: Überschriften als Design-Werkzeug. Ein <h3> im Footer, weil die Schriftgröße passt. Ein <h1> pro Karte in einer Kachelübersicht. Das erzeugt eine Gliederung, die es inhaltlich nicht gibt – und im Screenreader eine Landkarte, die in die Irre führt. Genau deshalb prüft der BITV-Test in Schritt 1.3.1a beide Richtungen.

Dritter Punkt, und den seh ich in fast jedem React- oder Vue-Projekt: Listen, die aus <div>s gerendert werden, weil ein Grid-Layout mit <ul> als umständlich empfunden wurde. display: grid funktioniert auf einer <ul> genauso gut, sobald list-style: none gesetzt ist. Die Ansage „Liste mit 12 Einträgen“ ist den kurzen Umweg wert.

Häufige Fragen

Muss jede visuelle Hervorhebung im Markup stehen?

Nein – gemeint sind Hervorhebungen, die Bedeutung tragen. Ein farbiger Akzent aus Designgründen braucht kein Markup. Sobald die Hervorhebung aber sagt „das hier ist wichtig“ oder „das hier ist eine Überschrift“, muss sie programmatisch ermittelbar sein – über <strong>, <em> oder ein echtes Überschriftenelement.

Sind Layouttabellen erlaubt?

Sie sind nicht verboten, dürfen aber kein Strukturmarkup verwenden. Eine Tabelle, die nur Spalten nebeneinanderstellt, darf kein <th>, kein <caption> und keine scope-Attribute enthalten – sonst meldet der Screenreader eine Datenstruktur, die es gar nicht gibt. Der BITV-Test führt das als eigenen Prüfschritt 1.3.1g. Besser ist heute ohnehin CSS Grid oder Flexbox.

Was ist der Unterschied zwischen 1.3.1 und 1.3.2?

1.3.1 regelt, dass Beziehungen im Markup stehen. 1.3.2 Bedeutungstragende Reihenfolge regelt, dass die Reihenfolge im Quelltext dem Sinn folgt. Eine Seite kann perfekt ausgezeichnet sein und trotzdem an 1.3.2 scheitern – etwa wenn CSS-Spalten die Lesereihenfolge gegenüber dem DOM vertauschen.

Reicht ARIA, wenn natives HTML nicht passt?

ARIA erfüllt 1.3.1 grundsätzlich, ist aber die zweite Wahl. role="heading" mit aria-level="2" funktioniert – bringt aber keine Browser-Standardformatierung mit, wird bei jedem Refactoring vergessen und ist in älteren Screenreader-Versionen weniger zuverlässig. Die erste Regel von ARIA gilt hier ausdrücklich: erst natives HTML, dann ARIA.