WCAG 2.4.6: Überschriften und Beschriftungen

WCAG 2.4.6 verlangt, dass Überschriften und Beschriftungen, sofern vorhanden, aussagekräftig sind und das Thema oder den Zweck des Inhalts, den sie einführen oder kennzeichnen, korrekt wiedergeben. Dieses Kriterium hilft Nutzerinnen und Nutzern – insbesondere solchen, die unterstützende Technologien verwenden – Inhalte effizient zu navigieren und die Struktur und den Zweck von Seitenbereichen und Formularfeldern zu verstehen.

Was diese Regel bedeutet

WCAG 2.4.6 besagt: „Überschriften und Beschriftungen beschreiben Thema oder Zweck.“ Im Kern verlangt dieses Kriterium, dass jede Überschrift (<h1> bis <h6>) oder Beschriftung (<label>, aria-label, aria-labelledby), die auf einer Seite erscheint, ausreichend beschreibend ist, um das Thema des Inhalts, den sie einführt, oder den Zweck des Steuerelements, das sie kennzeichnet, zu vermitteln.

Dieses Kriterium verlangt nicht, dass Überschriften oder Beschriftungen vorhanden sind – diese Verpflichtung wird durch andere Erfolgskriterien wie 1.3.1 (Info and Relationships) und 2.4.2 (Page Titled) abgedeckt. 2.4.6 regelt die Qualität der Überschriften und Beschriftungen, die bereits existieren: Wenn sie vorhanden sind, müssen sie aussagekräftig sein. Eine Überschrift mit der Aufschrift „Section 1“ oder eine Beschriftung mit der Aufschrift „Field“ sagt den Nutzern nichts Nützliches über den folgenden Inhalt oder die Eingabe, die sie beschreibt. Im Gegensatz dazu orientieren „Your Shipping Address“ oder „Monthly Budget Summary“ die Nutzer sofort.

Beschriftungen in diesem Kontext umfassen nicht nur das HTML-Element <label>, das mit Formularelementen verknüpft ist, sondern auch jeden programmatischen Beschriftungsmechanismus: aria-label, aria-labelledby, das title-Attribut, wenn es als zugänglicher Name verwendet wird, und das legend-Element für Fieldsets. Alle diese, die für unterstützende Technologien verfügbar sind, müssen den Zweck des zugehörigen Steuerelements klar beschreiben.

Ein Fehler liegt vor, wenn eine Überschrift oder Beschriftung so generisch, mehrdeutig oder nichtssagend ist, dass ein Nutzer nicht erkennen kann, worum es in dem Abschnitt oder Steuerelement geht, ohne den umgebenden Kontext zu lesen. Beispielsweise verstößt ein Formular mit drei Eingabefeldern, die alle mit „Enter here“ beschriftet sind, gegen dieses Kriterium, ebenso wie eine Seite, die wiederholte Überschriften wie „More Info“ für jeden Unterabschnitt verwendet. Ebenso ist eine Überschrift, die technisch im DOM vorhanden ist, den Nutzer aber völlig in die Irre führt – etwa wenn ein Kontaktformularbereich mit einer Überschrift „News and Updates“ versehen ist – ebenfalls ein Fehler.

Es gibt eine wichtige offizielle Ausnahme: WCAG 2.4.6 gilt nur, wenn Überschriften und Beschriftungen verwendet werden. Wenn eine Seite legitimerweise keine Überschriften hat (zum Beispiel ein sehr kurzes Dokument mit einem einzigen Thema) oder ein Formularelement keine sichtbare oder programmatische Beschriftung hat (was stattdessen von 1.3.1 erfasst würde), gilt 2.4.6 selbst nicht. Der Anwendungsbereich des Kriteriums betrifft ausschließlich die Beschreibungsqualität, nicht die Existenz.

Warum es wichtig ist

Beschreibende Überschriften und Beschriftungen kommen einer bemerkenswert breiten Zielgruppe zugute, aber die Auswirkungen sind am stärksten für Menschen mit Behinderungen, die auf Struktur zur Navigation angewiesen sind.

Screenreader-Nutzer – hauptsächlich Menschen, die blind sind oder eine starke Sehbehinderung haben – navigieren routinemäßig durch Seiten, indem sie mit Tastenkürzeln von Überschrift zu Überschrift springen (H in NVDA/JAWS, der Rotor in VoiceOver). Wenn Überschriften vage oder irreführend sind, bricht diese Navigationsstrategie vollständig zusammen. Eine blinde Person, die auf einem Portal für staatliche Dienstleistungen landet, das „Section A“, „Section B“ und „Section C“ als Überschriften verwendet, muss jedes Wort jedes Abschnitts der Reihe nach lesen, um zu finden, was sie braucht – der Effizienzvorteil, den Überschriften bieten sollen, geht verloren. Laut Weltgesundheitsorganisation haben weltweit etwa 2,2 Milliarden Menschen eine Form von Sehbeeinträchtigung, was eine beträchtliche globale Bevölkerungsgruppe darstellt.

Menschen mit kognitiven Beeinträchtigungen, einschließlich Personen mit Aufmerksamkeitsstörungen, Gedächtnisbeeinträchtigungen oder Lernschwierigkeiten, sind stark auf klare, vorhersehbare Beschriftungen und Überschriften angewiesen, um die kognitive Belastung zu reduzieren. Wenn ein Formularfeld nur mit „Name“ beschriftet ist, auf einer Seite, die sowohl einen Firmennamen als auch den Namen einer Kontaktperson erfasst, kann ein kognitiv beeinträchtigter Nutzer die Mehrdeutigkeit möglicherweise nicht allein aus dem Kontext auflösen, was zu Fehlern und Frustration führt.

Nutzer mit motorischen Beeinträchtigungen, die auf Schaltersteuerung, Eye-Tracking-Software oder Sprachsteuerung (wie Dragon NaturallySpeaking) angewiesen sind, profitieren von beschreibenden Beschriftungen, weil sie ein bestimmtes Formularfeld aktivieren können, indem sie seinen Beschriftungsnamen aussprechen. Wenn mehrere Felder denselben Beschriftungstext haben, kann Sprachsteuerungssoftware nicht zwischen ihnen unterscheiden, was den Nutzer zu zusätzlichen, körperlich anstrengenden Schritten zwingt.

Betrachten wir ein Szenario aus der Praxis: Eine Person, die einen Screenreader verwendet, besucht eine Checkout-Seite eines E-Commerce-Angebots. Die Seite enthält drei Adressbereiche – Rechnungsadresse, Lieferadresse und eine Adresse für den Geschenkempfänger – aber jeder Bereich verwendet dieselbe generische Überschrift „Address“ und jede Gruppe von Eingabefeldern verwendet dieselben Beschriftungen: „Street“, „City“, „Postal Code“. Ohne eindeutige, beschreibende Überschriften und Beschriftungen kann der Screenreader-Nutzer nicht erkennen, welche Gruppe von Feldern er gerade ausfüllt, was das Risiko von Bestellfehlern drastisch erhöht und die Wahrscheinlichkeit, den Kauf ganz abzubrechen, deutlich steigert.

Über die Barrierefreiheit hinaus bieten beschreibende Überschriften einen erheblichen SEO-Nutzen. Suchmaschinen verwenden die Überschriftenstruktur als starkes Signal, um Seiteninhalte zu verstehen und sie mit Suchanfragen abzugleichen. Aussagekräftige Überschriften helfen Suchmaschinen, Seiten genauer zu indexieren, und können die Klickraten in Suchergebnissen verbessern, in denen Überschriften häufig als Vorschautext angezeigt werden. Dies bringt geschäftliche Anreize direkt mit Barrierefreiheitsanforderungen in Einklang.

Wie man testet

Führen Sie zuerst einen automatisierten Scan durch: Verwenden Sie axe DevTools (Browser-Erweiterung) oder Lighthouse in den Chrome DevTools, um strukturelle Probleme mit Überschriften oder Beschriftungen zu identifizieren, die automatisierte Tools erkennen können, wie fehlende Beschriftungen, ausgelassene Überschriftenebenen oder leere Überschriftselemente. Auch wenn dies keine direkten Verstöße gegen 2.4.6 sind, weisen sie auf Bereiche hin, die bei der manuellen Überprüfung genauer untersucht werden sollten. Notieren Sie jede Überschrift und jedes beschriftete Steuerelement, das im Bericht markiert oder identifiziert wird.
Extrahieren Sie die Überschriftenliste: Verwenden Sie eine Browser-Erweiterung wie die HeadingsMap-Erweiterung (verfügbar für Firefox und Chrome) oder das WAVE-Tool, um eine flache Liste aller Überschriften auf der Seite zu erzeugen, bereinigt von ihrem umgebenden Inhalt. Lesen Sie diese Liste, als wäre sie ein Inhaltsverzeichnis. Fragen Sie sich: Könnte ein Nutzer die Struktur und die Hauptthemen dieser Seite allein anhand der Überschriften verstehen, ohne den Fließtext zu lesen? Wenn eine Überschrift isoliert betrachtet mehrdeutig oder nichtssagend ist, liegt ein Verstoß gegen 2.4.6 vor.
Testen Sie mit NVDA und Firefox: Öffnen Sie die Seite und drücken Sie H, um von Überschrift zu Überschrift zu navigieren. Hören Sie sich jede Überschriftenansage an und beurteilen Sie, ob sie den folgenden Inhalt beschreibt. Drücken Sie dann F, um durch Formularfelder zu wechseln, und hören Sie sich die für jede Eingabe angesagte Beschriftung an. Notieren Sie jede Überschrift oder Beschriftung, die ihr Thema oder ihren Zweck nicht klar beschreibt.
Testen Sie mit VoiceOver und Safari (macOS/iOS): Verwenden Sie den Web Rotor (VO+U), um die Überschriftenliste und die Liste der Formularelemente zu öffnen. Navigieren Sie durch jede Liste und bewerten Sie die Beschreibungsqualität jedes Eintrags unabhängig vom Seitenkontext. Verwenden Sie auf iOS eine Drei-Finger-Wischgeste, um im Rotor nach Überschriften zu navigieren.
Testen Sie mit JAWS und Chrome: Drücken Sie H, um durch Überschriften zu navigieren, und verwenden Sie den Forms Mode (F), um zwischen Formularelementen zu wechseln. Verwenden Sie den Dialog „List of Headings“ von JAWS (Insert+F6), um alle Überschriften in einer flachen Liste anzuzeigen, was die Art und Weise nachbildet, wie ein Screenreader-Nutzer die Seitenstruktur überfliegen würde.
Bewerten Sie Formularbeschriftungen isoliert: Blenden Sie für jedes Formularelement den gesamten umgebenden Kontext aus oder ignorieren Sie ihn und lesen Sie nur die programmatische Beschriftung (sichtbarer Beschriftungstext, aria-label oder aria-labelledby-Ziel). Bestätigen Sie, dass die Beschriftung allein ausreicht, um zu verstehen, welche Information eingegeben werden soll oder welche Aktion das Steuerelement ausführt.
Prüfen Sie auf doppelte Überschriften- oder Beschriftungstexte: Durchsuchen Sie die Seite nach wiederholten Überschriftentexten (z. B. mehrere „Read More“-Überschriften oder mehrere „Learn More“-Abschnitte). Wenn derselbe Text für Überschriften oder Beschriftungen verwendet wird, die sich auf unterschiedliche Themen oder Steuerelemente beziehen, liegt ein Verstoß gegen 2.4.6 vor.

Wie man es behebt

Generische Abschnittsüberschriften – Falsch

<section>
  <h2>Section 1</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Section 2</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

Generische Abschnittsüberschriften – Richtig

<!-- Each heading now describes the actual topic of its section,
     enabling screen reader users to jump directly to what they need -->
<section>
  <h2>Enterprise Logistics Software Solutions</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Flexible User-Based Pricing</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

Mehrdeutige Formularbeschriftungen – Falsch

<!-- A checkout form with two address blocks, both using identical labels -->
<fieldset>
  <legend>Address</legend>
  <label for='street1'>Street</label>
  <input type='text' id='street1'>
  <label for='city1'>City</label>
  <input type='text' id='city1'>
</fieldset>
<fieldset>
  <legend>Address</legend>
  <label for='street2'>Street</label>
  <input type='text' id='street2'>
  <label for='city2'>City</label>
  <input type='text' id='city2'>
</fieldset>

Mehrdeutige Formularbeschriftungen – Richtig

<!-- Legends now distinguish the two fieldsets; labels remain short because
     the legend provides the distinguishing context programmatically -->
<fieldset>
  <legend>Billing Address</legend>
  <label for='billing-street'>Street</label>
  <input type='text' id='billing-street'>
  <label for='billing-city'>City</label>
  <input type='text' id='billing-city'>
</fieldset>
<fieldset>
  <legend>Shipping Address</legend>
  <label for='shipping-street'>Street</label>
  <input type='text' id='shipping-street'>
  <label for='shipping-city'>City</label>
  <input type='text' id='shipping-city'>
</fieldset>

Nicht-beschreibendes ARIA-Label auf Icon-Button – Falsch

<!-- aria-label provides a label but it does not describe the button's purpose -->
<button aria-label='button'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

Nicht-beschreibendes ARIA-Label auf Icon-Button – Richtig

<!-- aria-label now clearly communicates what activating the button will do -->
<button aria-label='Search products'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

Wiederholte „Read More“-Überschriften oder -Links – Falsch

<article>
  <h3>Latest News</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>Latest News</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

Wiederholte „Read More“-Überschriften oder -Links – Richtig

<!-- Each article has a unique, descriptive heading that identifies its topic -->
<article>
  <h3>Istanbul Metro Expands to Three New Districts</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>New Regulations Affect E-Commerce Platforms</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

Häufige Fehler

Verwendung von positions- oder ordnungsbezogenen Überschriften wie „Step 1“, „Step 2“, „Section A“ ohne beschreibenden Text: Diese Überschriften sagen dem Nutzer nur, wo er sich in einer Abfolge befindet, nicht, worum es in dem Abschnitt geht. Kombinieren Sie Sequenzangaben immer mit einer beschreibenden Nominalphrase, z. B. „Step 2: Verify Your Email Address“.
Allen Karten- oder Artikelkomponenten auf einer Listing-Seite denselben Überschriftentext geben (z. B. jede Produktkarte hat ein <h3>, das nur „Product“ sagt): Jede Kartenüberschrift muss dieses spezifische Produkt, den Blogbeitrag oder Eintrag eindeutig identifizieren.
Platzhaltertext als zugängliche Beschriftung für eine Formulareingabe verwenden (Verlassen auf das placeholder-Attribut statt auf ein <label>-Element oder aria-label): Platzhalter verschwinden bei Eingabe und werden von Screenreadern nicht zuverlässig als zugängliche Namen angesagt. Selbst wenn ein Platzhalter vorhanden ist, ist eine separate beschreibende Beschriftung erforderlich.
Ein aria-label schreiben, das lediglich den Elementtyp wiederholt statt seinen Zweck, etwa aria-label='input' für ein Textfeld oder aria-label='button' für einen Button: Die Beschriftung muss beschreiben, was das Steuerelement tut oder welchen Wert es erfasst, nicht, um welche Art von Element es sich handelt.
Tooltip-Text oder title-Attribute als einzige Beschriftung für ein Formularelement verwenden und annehmen, dies erfülle 2.4.6: Auf title basierende Beschriftungen sind für reine Tastaturnutzer oft unzugänglich und werden von Screenreadern nicht konsistent angesagt. Verwenden Sie stattdessen sichtbare <label>-Elemente oder aria-label.
Suchfelder nur mit „Search“ beschriften auf einer Seite, auf der mehrere Suchbereiche existieren (z. B. eine Seitensuche und eine Suche innerhalb einer Datentabelle): Wenn zwei Steuerelemente unterschiedliche Suchen ausführen, muss jede Beschriftung den Suchbereich angeben, etwa „Search all products“ und „Search within order history“.
Dieselbe Überschrift für den Titel eines modalen Dialogs und die Hauptüberschrift der Seite verwenden: Modale Überschriften sollten die spezifische Aufgabe oder den Inhalt des Dialogs beschreiben (z. B. „Confirm Your Cancellation“) statt den Seitentitel zu übernehmen, was für Screenreader-Nutzer, die innerhalb des Dialogs navigieren, verwirrend wäre.
Eine beschreibende <legend> für Gruppen von Optionsfeldern oder Kontrollkästchen weglassen, während einzelne Optionsbeschriftungen bereitgestellt werden: Die <legend> liefert den wesentlichen Kontext, der jede einzelne Beschriftung aussagekräftig macht. „Yes“ und „No“ sind als alleinstehende Optionsbeschriftungen ohne eine Legende wie „Do you agree to the terms and conditions?“ nicht informativ.
Überschriftentext im DOM aus Designgründen kürzen (z. B. eine Überschrift, die nur ein Icon oder ein einzelnes Wort enthält, weil der vollständige Text in angrenzenden visuellen Elementen steht): Die programmatische Überschrift muss vollständig beschreibend sein, da Screenreader-Nutzer sie hören, ohne das umgebende visuelle Layout zu sehen.
Annehmen, dass eine Beschriftung, die für sehende Nutzer sichtbar ist, daher für alle Nutzer ausreichend beschreibend ist: Eine Beschriftung, die auf räumlicher Position beruht (z. B. eine Spaltenüberschrift in einem benutzerdefinierten Grid, deren Bedeutung davon abhängt, dass man ihre Beziehung zu umgebenden Zellen sieht), kann visuell klar sein, aber dieselben Informationen programmatisch nicht vermitteln. Stellen Sie immer sicher, dass der zugängliche Name allein ausreicht.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die türkische Präsidialverfügung 2025/10, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Verpflichtungen zur digitalen Barrierefreiheit für eine breite Palette öffentlicher und privater Einrichtungen fest, die in der Türkei tätig sind. Die Verfügung verweist ausdrücklich auf WCAG 2.1 Level AA als technischen Standard für die Konformität, und Anforderungen auf Level AA nach WCAG 2.2 – das auf Level-AA-Ebene abwärtskompatibel mit WCAG 2.1 ist – werden nachdrücklich empfohlen und sind für Einrichtungen erforderlich, die das offizielle Accessibility Logo (Erişilebilirlik Logosu) des Ministeriums für Familie und Soziale Dienste (Aile ve Sosyal Hizmetler Bakanlığı) anstreben.

WCAG 2.4.6 ist ein Kriterium auf Level AA, was bedeutet, dass es eindeutig in den Anwendungsbereich dessen fällt, was betroffene Einrichtungen adressieren müssen, um vollständige Konformität zu erreichen. Die folgenden Einrichtungstypen werden von der Präsidialverfügung erfasst: öffentliche Institutionen und Regierungsbehörden; E-Commerce-Plattformen; Banken und Finanzinstitute; Krankenhäuser und Gesundheitsdienstleister; Telekommunikationsanbieter mit 200,000 oder mehr Abonnenten; Reisebüros; private Transportunternehmen; und Privatschulen, die vom Ministerium für Nationale Bildung (Millî Eğitim Bakanlığı) autorisiert sind.

Für diese Einrichtungen birgt das Versäumnis, beschreibende Überschriften und Beschriftungen bereitzustellen, ein konkretes regulatorisches Risiko. Ein Regierungsportal mit vagen Abschnittsüberschriften behindert Bürger mit Behinderungen beim Zugang zu öffentlichen Dienstleistungen, was direkt dem erklärten Ziel der Verfügung widerspricht, gleichberechtigten Zugang sicherzustellen. Eine E-Commerce-Website mit mehrdeutigen Formularbeschriftungen im Checkout-Prozess kann Nutzer mit Seh- oder kognitiven Beeinträchtigungen daran hindern, Einkäufe abzuschließen, und stellt damit ein Hindernis für die wirtschaftliche Teilhabe dar, das die Verfügung zu beseitigen versucht.

Einrichtungen, die das Erişilebilirlik Logosu anstreben, müssen die Konformität durch ein Barrierefreiheitsaudit nachweisen, und 2.4.6 gehört zu den Kriterien, die Auditoren manuell bewerten werden. Da dieses Kriterium menschliches Urteil erfordert – automatisierte Tools können die Beschreibungsqualität nicht beurteilen – sollten Organisationen eine strukturierte manuelle Überprüfung aller Überschriften und Formularbeschriftungen als festen Bestandteil ihres Barrierefreiheitsaudit-Prozesses vorsehen. Diese Überprüfung in Content-Management-Workflows und Designsysteme zu integrieren, statt sie als einmalige Audit-Aufgabe zu behandeln, ist die effektivste Strategie, um eine fortlaufende Konformität sicherzustellen, während sich Inhalte im Laufe der Zeit ändern.