WCAG 1.3.1: Informationen und Beziehungen

WCAG 1.3.1 verlangt, dass Informationen, Struktur und Beziehungen, die durch visuelle Darstellung vermittelt werden, auch programmatisch ermittelt werden können oder in Textform verfügbar sind, sodass Nutzer von unterstützenden Technologien denselben strukturellen Kontext erhalten wie sehende Nutzer.

Was diese Regel bedeutet

WCAG 1.3.1 — Info and Relationships ist ein Kriterium der Stufe A unter dem Prinzip „Wahrnehmbar“. Die Kernanforderung ist einfach, aber weitreichend: Jede Information oder Beziehung, die visuell vermittelt wird, muss auch so ausgedrückt werden, dass unterstützende Technologien sie erkennen und an Nutzer weitergeben können. Wenn Ihr Design visuelle Hinweise verwendet – Einrückung, um eine Liste anzudeuten, Fettschrift, um ein Pflichtfeld zu kennzeichnen, Farbe, um einen Fehler anzuzeigen, oder Größe, um eine Überschrift zu markieren – müssen dieselben Semantiken im zugrunde liegenden Code vorhanden sein.

Das Kriterium gilt für drei Bedeutungskategorien, die Webinhalte regelmäßig durch Präsentation vermitteln:

Information — Fakten oder Daten, die auf der Seite kommuniziert werden, etwa welche Formularfelder erforderlich sind oder welche Tabellenzellen in Beziehung zueinander stehen.
Struktur — das organisatorische Schema des Inhalts, etwa Überschriftenhierarchien, geordnete oder ungeordnete Listen und Datentabellen.
Beziehungen — Verknüpfungen zwischen Elementen, etwa zwischen einer Beschriftung und ihrem Eingabefeld, einem Tabellenkopf und seinen Datenzellen oder einem Begriff und seiner Definition.

Eine Seite besteht 1.3.1, wenn jede strukturelle oder relationale Information, die einem sehenden Nutzer zur Verfügung steht, entweder in gültigem, semantischem HTML kodiert ist oder über eine korrekte ARIA-Rolle, -Eigenschaft oder -Zustand offengelegt wird, die unterstützende Technologien interpretieren können. Eine Seite fällt durch, wenn visuelle Struktur nur in CSS oder Bildern existiert oder wenn ARIA-Markup der präsentierten DOM-Struktur widerspricht oder darin fehlt.

Offizielle Ausnahmen sind minimal. Das Kriterium verlangt nicht, dass jede visuelle Dekoration semantische Bedeutung trägt – rein ästhetische Formatierungen wie ein dekorativer Rahmen oder eine Hintergrundfarbe benötigen kein programmatisches Äquivalent. Jede Formatierung jedoch, die ein Nutzer vernünftigerweise als bedeutungstragend interpretieren würde (Pflichtsternchen, fett gesetzte Begriffe in einem Glossar, nummerierte Schritte), muss einen entsprechenden programmatischen Ausdruck haben.

Warum das wichtig ist

Informationen und Beziehungen liegen nahezu jeder Interaktion zugrunde, die ein Nutzer mit einer Webseite hat. Wenn diese Struktur ausschließlich in der visuellen Präsentation eingeschlossen ist, wird ein erheblicher Teil der Bevölkerung faktisch davon ausgeschlossen, den Inhalt überhaupt zu verstehen.

Screenreader-Nutzer – typischerweise blinde oder sehbehinderte Personen – navigieren Seiten, indem sie den Accessibility Tree abfragen, der aus semantischem HTML und ARIA aufgebaut wird. Wenn ein Entwickler ein <div> verwendet, das wie eine Überschrift gestylt ist, statt ein echtes <h2>, wird ein Screenreader-Nutzer, der mit der Taste H zwischen Überschriften springt, dieses Element vollständig überspringen. Er findet den Abschnitt, den es einleitet, möglicherweise nie. Laut Weltgesundheitsorganisation leben weltweit etwa 2,2 Milliarden Menschen mit einer Form von Sehbeeinträchtigung, und Dutzende Millionen sind täglich auf Screenreader angewiesen.

Nutzer mit kognitiven Beeinträchtigungen profitieren ebenso von klarer Struktur. Korrekt verschachtelte Überschriften, sinnvolles Listen-Markup und beschriftete Formularelemente verringern die kognitive Belastung, indem sie vorhersehbare Muster bieten. Ein Screenreader, der „Überschrift Ebene 2, Produkte“ gefolgt von „Überschrift Ebene 3, Laptops“ ankündigt, vermittelt eine kognitive Karte der Seite. Eine flache Wand aus gestyltem Text ohne strukturelle Anker ist für alle desorientierend, insbesondere aber für Nutzer mit Aufmerksamkeits- oder Gedächtnisproblemen.

Motorisch beeinträchtigte Nutzer, die auf Tastaturnavigation, Schaltersteuerung oder Spracherkennungssoftware angewiesen sind, sind ebenfalls auf programmatische Struktur angewiesen. Spracherkennungssoftware wie Dragon NaturallySpeaking erzeugt anklickbare Ziele aus zugänglichen Namen, die aus Labels und Rollen abgeleitet werden – Formulareingaben ohne zugeordnete Labels können per Sprachbefehl schlicht nicht zuverlässig angesprochen werden.

Betrachten Sie ein konkretes Szenario: Ein Patientenportal eines Krankenhauses zeigt eine Tabelle mit anstehenden Terminen. Die Tabelle verwendet visuelle Ausrichtung und Hintergrundfarbe, um Daten mit Ärzten zu verknüpfen, aber die <th>-Elemente haben keine scope-Attribute und die Datenzellen verweisen nicht auf Header. Ein blinder Nutzer mit Screenreader hört isolierte Zellwerte – „9:00 AM“, „Dr. Ayşe Kaya“, „Kardiologie“ – ohne zu wissen, welcher Wert zu welcher Spalte gehört. Er könnte seine Terminzeit falsch verstehen oder in der falschen Abteilung erscheinen. Die korrekte Verwendung von scope='col' bei Headern und headers-Attributen bei Zellen hätte die Beziehungen hörbar gemacht.

Über die Barrierefreiheit hinaus hat strukturelles HTML erheblichen SEO-Wert. Suchmaschinen-Crawler nutzen Überschriftenhierarchien, um Seitenthemen zu verstehen, Listen-Markup, um aufgezählte Inhalte zu erkennen, und Label-Zuordnungen, um den Zweck von Formularen zu erfassen. Eine Seite, die 1.3.1 besteht, ist fast immer eine Seite, die Suchmaschinen genauer parsen und einstufen können.

Wie man testet

Automatischer Scan mit axe DevTools oder Lighthouse: Installieren Sie die Browser-Erweiterung axe DevTools (Chrome oder Firefox). Öffnen Sie die zu testende Seite, öffnen Sie die DevTools, navigieren Sie zum axe-Tab und führen Sie einen Scan der gesamten Seite aus. Filtern Sie die Ergebnisse nach dem Tag wcag131 oder prüfen Sie alle Probleme, die unter „Info and Relationships“ gekennzeichnet sind. Achten Sie speziell auf Verstöße gegen die elf oben aufgeführten axe-Regeln. Führen Sie in Lighthouse (Chrome DevTools Audits-Panel) einen Accessibility-Audit durch und prüfen Sie die Kategorie „Accessibility“ auf Fehler in Bezug auf Überschriftenreihenfolge, Labels und Listen. Notieren Sie alle markierten Elemente und ihre DOM-Selektoren zur Behebung.
Manuelle Überprüfung der Überschriftenstruktur: Verwenden Sie die Browser-Erweiterung HeadingsMap oder das „Headings“-Panel in axe DevTools, um die vollständige Überschriften-Gliederung der Seite anzuzeigen. Vergewissern Sie sich, dass die Gliederung logisch und hierarchisch ist – sie sollte sich wie ein gut strukturiertes Inhaltsverzeichnis lesen. Bestätigen Sie, dass keine Überschriftenebenen übersprungen werden und dass der Überschriftentext aussagekräftig ist und nicht nur visuelles Styling auf Nicht-Überschrift-Elementen darstellt.
Überprüfung von Formularlabels: Navigieren Sie per Tab durch jedes interaktive Formularelement auf der Seite. Stellen Sie für jedes Input-, Select- und Textarea-Element sicher, dass ein sichtbares Label vorhanden und programmatisch zugeordnet ist (prüfen Sie das Element in den DevTools und suchen Sie nach einem passenden for/id-Paar oder einem aria-label/aria-labelledby). Verwenden Sie den Accessibility Tree in den Chrome DevTools (Elements-Panel → Accessibility-Tab), um den berechneten zugänglichen Namen für jedes Steuerelement zu überprüfen.
Screenreader-Tests mit NVDA + Firefox: Starten Sie NVDA und öffnen Sie die Seite in Firefox. Drücken Sie H, um durch Überschriften zu springen, und prüfen Sie, ob die angekündigten Überschriftenebenen der visuellen Hierarchie entsprechen. Drücken Sie F, um zwischen Formularfeldern zu wechseln, und bestätigen Sie, dass das Label jedes Feldes angekündigt wird. Drücken Sie T, um Tabellen zu navigieren, und bewegen Sie sich mit den Pfeiltasten durch die Zellen, während Sie auf die Ankündigung der Header achten. Drücken Sie L, um durch Listen zu springen, und bestätigen Sie, dass die Anzahl der Elemente angekündigt wird.
Screenreader-Tests mit VoiceOver + Safari (macOS/iOS): Aktivieren Sie VoiceOver (Cmd+F5 auf macOS). Öffnen Sie den Rotor (Ctrl+Option+U) und prüfen Sie Überschriften, Links, Formularsteuerelemente und Tabellen. Bestätigen Sie, dass alle Strukturelemente im Rotor erscheinen und dass ihre angekündigten Namen aussagekräftig und korrekt sind.
Screenreader-Tests mit JAWS + Chrome: Öffnen Sie JAWS und die Seite in Chrome. Verwenden Sie die JAWS-Liste der Überschriften (Insert+F6), um die Überschriftenstruktur zu prüfen. Verwenden Sie Insert+F5 für Formularfelder, um Label-Zuordnungen zu überprüfen. Navigieren Sie Tabellen mit den Pfeiltasten und bestätigen Sie, dass JAWS für jede Datenzelle Spalten- und Zeilenheader ankündigt.
Überprüfung der Tabellenkopf-Beziehungen: Identifizieren Sie alle Datentabellen auf der Seite. Überprüfen Sie bei einfachen Tabellen, ob <th>-Elemente geeignete scope-Attribute haben. Überprüfen Sie bei komplexen Tabellen mit mehrstufigen Headern, ob Datenzellen das headers-Attribut verwenden, das auf die richtigen id-Werte verweist. Verfolgen Sie jede Zelle visuell zu ihren logischen Zeilen- und Spaltenheadern und bestätigen Sie dann, dass derselbe Pfad im Code dargestellt ist.

Wie man es behebt

Visuelle Überschriften als gestylte divs implementiert — Falsch

<!-- Heading conveyed only through CSS font-size and font-weight -->
<div class='section-title'>Our Services</div>
<div class='subsection-title'>Web Development</div>
<p>We build fast, accessible websites.</p>

Visuelle Überschriften als gestylte divs implementiert — Richtig

<!-- Semantic heading elements expose hierarchy to assistive technologies -->
<h2>Our Services</h2>
<h3>Web Development</h3>
<p>We build fast, accessible websites.</p>

Formulareingabe ohne zugeordnetes Label — Falsch

<!-- The placeholder is not a substitute for a label; it disappears on input -->
<p>Email Address *</p>
<input type='email' placeholder='Enter your email' />

Formulareingabe ohne zugeordnetes Label — Richtig

<!-- The for attribute ties the label to the input by matching id -->
<label for='email'>Email Address <span aria-hidden='true'>*</span><span class='sr-only'>(required)</span></label>
<input type='email' id='email' aria-required='true' />

Datentabelle ohne scope-Attribute — Falsch

<!-- Headers have no scope; screen readers cannot associate columns with data -->
<table>
  <tr>
    <th>Tarih</th>
    <th>Doktor</th>
    <th>Klinik</th>
  </tr>
  <tr>
    <td>15 Temmuz 2025</td>
    <td>Dr. Ayşe Kaya</td>
    <td>Kardiyoloji</td>
  </tr>
</table>

Datentabelle ohne scope-Attribute — Richtig

<!-- scope='col' tells screen readers each th describes its entire column -->
<table>
  <caption>Yaklaşan Randevular</caption>
  <thead>
    <tr>
      <th scope='col'>Tarih</th>
      <th scope='col'>Doktor</th>
      <th scope='col'>Klinik</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>15 Temmuz 2025</td>
      <td>Dr. Ayşe Kaya</td>
      <td>Kardiyoloji</td>
    </tr>
  </tbody>
</table>

Listenelemente außerhalb eines Listencontainers verwendet — Falsch

<!-- li elements without a parent ul or ol have no semantic meaning -->
<div class='features'>
  <li>Fast performance</li>
  <li>WCAG compliant</li>
  <li>Mobile friendly</li>
</div>

Listenelemente außerhalb eines Listencontainers verwendet — Richtig

<!-- Wrapping ul gives screen readers item count and navigation context -->
<ul class='features'>
  <li>Fast performance</li>
  <li>WCAG compliant</li>
  <li>Mobile friendly</li>
</ul>

Häufige Fehler

Verwendung von font-size- und font-weight-CSS allein, um auf <div>- oder <span>-Elementen das visuelle Erscheinungsbild von Überschriften zu erzeugen, ohne jemals role='heading' und aria-level hinzuzufügen oder sie in echte <h1>–<h6>-Elemente umzuwandeln – Screenreader können diese nicht als navigierbare Überschriften erkennen.
Verwendung von placeholder-Text als einziges Label für Formulareingaben, wodurch das Label verschwindet, sobald der Nutzer zu tippen beginnt, und das Feld für die Dauer der Eingabe unbeschriftet bleibt – koppeln Sie Eingaben immer mit einem dauerhaften <label>-Element.
Markierung von Pflichtfeldern mit einem roten Sternchen (*), das nur in einer visuellen Legende am oberen Rand des Formulars erklärt wird, ohne aria-required='true' hinzuzufügen oder „required“ in das programmatische Label aufzunehmen, sodass Screenreader-Nutzer dieselbe Information erhalten.
Anwendung von list-style: none per CSS auf ein <ul>, ohne zu verstehen, dass einige Screenreader (insbesondere Safari + VoiceOver) dann möglicherweise aufhören, das Element als Liste anzukündigen – wenn die Listensemantik bedeutungsvoll ist, fügen Sie explizit role='list' hinzu, um sie zu erhalten.
Überspringen von Überschriftenebenen – zum Beispiel das Platzieren eines <h4> direkt nach einem <h2>, weil der Designer kleinere Schrift wollte – statt die korrekte Überschriftenebene zu verwenden und das visuelle Erscheinungsbild über CSS zu steuern.
Erstellung komplexer Datentabellen mit zusammengeführten Zellen (colspan/rowspan), ohne das headers-Attribut an Datenzellen hinzuzufügen, sodass Screenreader-Nutzer nicht bestimmen können, welcher Header eine mehrdeutige zusammengeführte Zelle beschreibt.
Verwendung von <table>-Elementen zu Layoutzwecken und anschließendes uneinheitliches Hinzufügen von role='presentation' – einige Zellen enthalten weiterhin Header, die aus dem Kontext gerissen angekündigt werden, was Nutzer verwirrt, die nicht sehen können, dass die Tabelle rein dekorativ ist.
Umschließen eines <dt>/<dd>-Paars in einem <p> oder <div>, das ein direktes Kindelement eines <dl> ist, ohne zu verstehen, dass in HTML5 nur <div>-Wrapper innerhalb von <dl> zulässig sind und dass das Mischen anderer Blockelemente die Definitionslistenstruktur zerstört.
Hinzufügen von aria-labelledby zu einer Eingabe, die auf eine ID verweist, die im DOM nicht existiert, oder auf die ID eines Nicht-Text-Elements – der berechnete zugängliche Name wird leer und die Eingabe ist für unterstützende Technologien faktisch unbeschriftet.
Die Annahme, dass eine Seite, die visuell korrekt aussieht und einen Lighthouse-Score über 90 erreicht, 1.3.1 erfüllt – automatisierte Tools können nicht jede strukturelle Verletzung erkennen, etwa visuelle Verschachtelungsbeziehungen, die in der ARIA-Rollenhierarchie nicht abgebildet sind, sodass zwingend manuelle und Screenreader-Überprüfungen erforderlich sind.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die Präsidialverfügung 2025/10 der Türkei, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Web-Barrierefreiheitspflichten fest, die an WCAG 2.2 ausgerichtet sind, und gilt für eine breite Palette von Akteuren, die in der Türkei tätig sind. WCAG 1.3.1 ist ein Kriterium der Stufe A, was bedeutet, dass es zur grundlegenden Konformitätsstufe gehört – dem minimal akzeptablen Barrierefreiheitsniveau – und daher für alle unter die Verfügung fallenden Akteure vollständig verbindlich ist.

Die Verfügung definiert zwei Umsetzungsfristen. Öffentliche Institutionen – einschließlich zentraler Regierungsstellen, Gemeinden, staatlicher Universitäten und öffentlicher Krankenhäuser – müssen innerhalb eines Jahres nach Inkrafttreten der Verfügung vollständige Konformität auf Stufe A erreichen. Private Sektorunternehmen, die unter die Regelung fallen, haben ein zweijähriges Zeitfenster zur Umsetzung. Die Verpflichtung ist jedoch für keine der beiden Gruppen optional: Nichteinhaltung setzt die betroffenen Akteure einer behördlichen Prüfung und möglichen Durchsetzungsmaßnahmen aus.

Die in der Verfügung ausdrücklich genannten privaten Sektorunternehmen umfassen E‑Commerce-Plattformen, Banken und Finanzinstitute, private Krankenhäuser und Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnenten, lizenzierte Reisebüros, private Transportunternehmen und Privatschulen, die unter Genehmigung des Ministeriums für Nationale Bildung (MoNE) tätig sind. Jedes dieser Unternehmen, das eine öffentlich zugängliche Website oder mobile Webanwendung betreibt, muss sicherstellen, dass 1.3.1 in all seinen digitalen Angeboten erfüllt ist.

Für die praktische Einhaltung ist 1.3.1 eines der wirkungsstärksten Kriterien der Stufe A, da es die grundlegende Seitenstruktur regelt. Eine türkische E‑Commerce-Website, deren Produktkategorieseiten gestylte <div>-Elemente als Überschriften verwenden, deren Eingabefelder im Checkout-Formular keine Label-Zuordnungen haben oder deren Bestellübersicht eine unstrukturierte Tabelle ohne scope-Attribute ist, würde 1.3.1 umfassend verfehlen. Die Behebung ist nicht nur eine rechtliche Verpflichtung – sie verbessert direkt die Erfahrung für die geschätzten 700.000 oder mehr blinden und sehbehinderten Menschen in der Türkei, die auf unterstützende Technologien angewiesen sind, um online einzukaufen, zu bankieren, Gesundheitsleistungen in Anspruch zu nehmen und mit Behörden zu interagieren.

Organisationen, die ihre Konformität nachweisen wollen, sollten sowohl automatisierte axe-core-Scans als auch manuelle Screenreader-Audits durchführen, die die gesamte Bandbreite ihrer digitalen Inhalte abdecken. Strukturelle Barrierefreiheit – das Fundament, das 1.3.1 durchsetzt – sollte in Designsysteme und Komponentenbibliotheken eingebaut werden, sodass die Konformität bei der Erstellung und Aktualisierung von Inhalten erhalten bleibt und nicht als einmalige Nachbesserungsmaßnahme behandelt wird.