WCAG 3.2.4: Konsistente Identifizierung

Was diese Regel bedeutet

Das WCAG-Erfolgskriterium 3.2.4 – Konsistente Identifizierung – besagt, dass Komponenten mit derselben Funktionalität innerhalb eines Satzes von Webseiten konsistent identifiziert werden müssen. Das bedeutet, dass jedes Mal, wenn ein interaktives Element oder ein Bild dieselbe Funktion erfüllt, es jedes Mal, wenn es auf der Website erscheint, denselben zugänglichen Namen oder dasselbe Label tragen sollte.

Der Begriff „identifiziert“ bezieht sich in diesem Zusammenhang darauf, wie eine Komponente gegenüber unterstützenden Technologien und Nutzerinnen und Nutzern präsentiert wird. Dazu gehören der sichtbare Beschriftungstext, das Attribut aria-label oder aria-labelledby, der alt-Text eines Bildes, das Attribut title oder der zugängliche Name, der vom Accessibility-Tree des Browsers berechnet wird. Wenn eine Suchschaltfläche auf jeder Seite einer Website erscheint, muss sie immer „Search“ heißen – nicht „Search“ auf der Startseite, „Find“ auf der Produktlistenseite und „Go“ auf der Checkout-Seite.

Dieses Kriterium gilt für einen Satz von Webseiten, den WCAG als eine Sammlung von Seiten definiert, die einen gemeinsamen Zweck haben und vom selben Autor erstellt wurden. Dies umfasst eine gesamte Website, eine Webanwendung oder ein mehrstufiges Formular, das sich über mehrere URLs erstreckt. Komponenten, die lediglich visuell ähnlich sind, aber unterschiedliche Funktionen erfüllen, müssen nicht denselben Namen tragen – die Anforderung bezieht sich ausdrücklich auf identische Funktionalität.

Was als erfüllt gilt: Ein Navigationssymbol, das ein Hamburger-Menü öffnet, ist auf allen Seiten konsistent mit „Open navigation menu“ (oder einem gleichwertigen Text) beschriftet. Ein Einkaufswagensymbol hat immer den alt-Text oder den zugänglichen Namen „Shopping cart“. Eine Logout-Schaltfläche ist immer mit „Log out“ beschriftet. Abweichungen in der Wortwahl für dieselbe Funktion stellen einen Verstoß dar.

Was als nicht erfüllt gilt: Eine Absenden-Schaltfläche, die im Registrierungsformular mit „Submit“ beschriftet ist, im Kontaktformular jedoch mit „Send“, obwohl beide Schaltflächen denselben funktionalen Zweck erfüllen, nämlich das Übermitteln von vom Nutzer eingegebenen Daten. Eine Symbolschaltfläche mit einem Lupen-Icon, die auf den meisten Seiten mit „Search“ beschriftet ist, aber auf einer einzelnen übersetzten Unterseite mit „Ara“, ohne dass eine konsistente Sprachstrategie vorhanden ist.

Offizielle Ausnahme: WCAG weist ausdrücklich darauf hin, dass es zulässig ist, zwei Komponenten mit demselben zugänglichen Namen zu haben, wenn sie unterschiedliche Funktionen erfüllen – in diesem Fall sorgt die unterschiedliche Funktion selbst für die Unterscheidung. Das Kriterium greift nur, wenn die Funktion identisch ist, die Benennung jedoch inkonsistent.

Warum das wichtig ist

Inkonsistente Identifizierung erzeugt eine unverhältnismäßige Belastung für Nutzerinnen und Nutzer, die auf nicht-visuelle oder musterbasierte Navigationsstrategien angewiesen sind. Am stärksten betroffen sind Screenreader-Nutzende, Menschen mit kognitiven Beeinträchtigungen und Menschen mit motorischen Einschränkungen, die Sprachsteuerungssoftware verwenden.

Screenreader-Nutzende bauen sich ein mentales Modell einer Website auf, indem sie den Elementnamen zuhören, während sie per Tab navigieren oder nach Landmarken browsen. Wenn eine Schaltfläche, die auf der vorherigen Seite dieselbe Funktion hatte, nun einen anderen Namen trägt, muss die Person anhalten, nachforschen und sich neu orientieren – ein zeitaufwändiger und frustrierender Prozess. Laut Weltgesundheitsorganisation haben weltweit etwa 2,2 Milliarden Menschen irgendeine Form von Sehbeeinträchtigung. Selbst ein Bruchteil dieser Bevölkerung wird bei der Interaktion mit einer inkonsistent beschrifteten Website auf erhebliche Barrieren stoßen.

Menschen mit kognitiven Beeinträchtigungen, einschließlich Personen mit Dyslexie, Aufmerksamkeitsstörungen oder Gedächtnisbeeinträchtigungen, sind in hohem Maße auf vorhersehbare Benennungen angewiesen, um die kognitive Belastung zu reduzieren. Wenn ein vertrautes Symbol oder Steuerelement unter einem anderen Namen erscheint, zwingt dies zum erneuten Lernen und verursacht Angst. Konsistente Beschriftungen verringern den Aufwand, der nötig ist, um prozedurales Gedächtnis beim regelmäßigen Nutzen einer Website aufzubauen.

Sprachsteuerungs-Nutzende (mit Tools wie Dragon NaturallySpeaking oder Apples Voice Control) sprechen den Namen eines Steuerelements aus, um es zu aktivieren. Wenn der zugängliche Name einer Schaltfläche von dem abweicht, was sie aufgrund früherer Erfahrungen mit der Website erwarten, schlägt ihr gesprochener Befehl stillschweigend fehl – die Software findet einfach keine Übereinstimmung. In diesem Moment ist die Schnittstelle faktisch unbenutzbar.

Ein konkretes Szenario aus der Praxis: Betrachten wir eine türkische E-Commerce-Plattform, die Kleidung verkauft. Auf der Produktgitter-Seite hat jedes Produkt eine Schaltfläche mit einem Herzsymbol, deren zugänglicher Name „Add to favourites“ ist. Auf der Produktdetailseite lautet der zugängliche Name desselben Herzsymbols „Kaydet“ (Türkisch für „Speichern“). Eine Screenreader-Nutzerin, die gelernt hat, die Herzschaltfläche auf der Gitterseite über ihren Namen zu aktivieren, kann das entsprechende Steuerelement auf der Detailseite nun nicht mehr finden, ohne die Seite umfassend zu erkunden. Sie könnte die Website vollständig verlassen.

Über die Barrierefreiheit hinaus profitieren auch SEO-Aspekte von konsistenter Beschriftung. Suchmaschinen werten zugängliche Namen und Linktexte aus, um Seiteninhalte zu verstehen. Inkonsistente Beschriftungen für funktional identische Links (z. B. „Read more“, „Continue reading“, „Learn more“, die alle auf Artikeldetailseiten verweisen) verwässern Keyword-Signale und erschweren es Crawlern, die Seitenstruktur zu verstehen.

Verwandte Axe-core-Regeln

WCAG 3.2.4 erfordert manuelle Tests, da automatisierte Tools weder die semantische Absicht über mehrere Seiten hinweg bestimmen noch erkennen können, dass zwei unterschiedlich benannte Komponenten dieselbe Funktion erfüllen. Es gibt keine axe-core-Regel, die direkt diesem Kriterium entspricht. Hier ist der Grund, warum Automatisierung an ihre Grenzen stößt und was Testerinnen und Tester stattdessen tun müssen:

• Manuelle Tests erforderlich – Konsistenz über Seiten hinweg: Axe-core bewertet jeweils nur eine einzelne Seite. Es gibt keinen Mechanismus, um den zugänglichen Namen einer „Search“-Schaltfläche auf der Startseite mit einer „Find“-Schaltfläche auf einer Produktseite zu vergleichen, da kein seitenübergreifendes Inventar von Komponentennamen geführt wird. Eine menschliche Testperson muss wiederkehrende funktionale Elemente katalogisieren und überprüfen, ob ihre Benennung auf allen Seiten, auf denen sie erscheinen, einheitlich ist.
• Manuelle Tests erforderlich – Konsistenz von Symbol- und Bild-alt-Texten: Automatisierte Tools können fehlenden alt-Text erkennen (über die Regel image-alt), aber nicht feststellen, ob zwei Bilder, die denselben Zweck erfüllen, auf verschiedenen Seiten denselben alt-Text tragen. Ein Druckersymbol auf einer Belegseite und dasselbe Druckersymbol auf einer Rechnungsseite können beide alt-Text haben – aber wenn der eine „Print“ und der andere „Print this page“ lautet, muss eine Person beurteilen, ob dies nach 3.2.4 eine Inkonsistenz darstellt.
• Manuelle Tests erforderlich – Konsistenz von ARIA-Labels: Axe-core prüft, ob ARIA-Labels vorhanden und nicht leer sind, aber es überprüft nicht, ob aria-label-Werte für denselben Komponententyp über den gesamten Seitensatz hinweg konsistent sind. Eine Testperson muss den Accessibility-Tree auf mehreren Seiten inspizieren und die Namen funktional identischer Steuerelemente vergleichen.
• Manuelle Tests erforderlich – Formularfeld-Beschriftungen: Automatisierte Regeln wie label prüfen, ob Eingabefelder mit Labels verknüpft sind, aber sie kontrollieren nicht, ob ein „Username“-Feld auf der Login-Seite auch auf der Kontowiederherstellungsseite mit „Username“ (statt „Email“ oder „User ID“) beschriftet ist, wenn beide Felder denselben Eingabetyp akzeptieren und dieselbe funktionale Rolle erfüllen.

Wie man testet

1. Automatischer Vorab-Scan: Führen Sie axe DevTools oder Lighthouse auf jeder Seite aus, um verwandte Verstöße wie fehlende zugängliche Namen (image-alt, button-name, link-name) aufzudecken. Beheben Sie diese zuerst – Sie können die Namenskonsistenz nicht bewerten, wenn Namen fehlen. Notieren Sie die gemeldeten zugänglichen Namen für wiederkehrende Komponenten in Ihren Scan-Ergebnissen.
2. Komponenten-Inventar erstellen: Listen Sie manuell alle funktionalen Komponenten auf, die sich über mehrere Seiten wiederholen – Navigationsmenüs, Suchfelder, Absenden-Schaltflächen, Symbolschaltflächen, Breadcrumb-Links, Social-Media-Links, Druck-/Teilen-Schaltflächen und Paginierungselemente. Protokollieren Sie den zugänglichen Namen jeder Instanz mithilfe des Accessibility-Panels Ihres Browsers (Chrome DevTools > Elements > Accessibility oder Firefox Accessibility Inspector).
3. Namen seitenübergreifend vergleichen: Überprüfen Sie für jeden Komponententyp in Ihrem Inventar, ob jede Instanz denselben zugänglichen Namen trägt. Markieren Sie jede Abweichung. Achten Sie besonders auf Komponenten, die in Kopfzeilen, Fußzeilen und Seitenleisten erscheinen, da diese am ehesten über Templates hinweg inkonsistent beschriftet sind.
4. Screenreader-Tests mit NVDA + Firefox: Navigieren Sie zur Startseite und öffnen Sie dann mit der Elementliste von NVDA (Einfügen + F7) die Liste der Schaltflächen und Links. Notieren Sie die Namen wiederkehrender Steuerelemente. Navigieren Sie anschließend zu drei oder vier weiteren repräsentativen Seiten und wiederholen Sie den Vorgang. Achten Sie auf Namensvariationen bei funktional identischen Steuerelementen.
5. Screenreader-Tests mit VoiceOver + Safari (macOS/iOS): Verwenden Sie den Rotor (VO + U), um auf jeder Seite die Liste der Schaltflächen oder Links aufzurufen. Vergleichen Sie die Namen wiederkehrender Elemente. Streichen Sie auf iOS über interaktive Elemente auf vergleichbaren Seiten und notieren Sie etwaige Unterschiede in der Benennung.
6. Screenreader-Tests mit JAWS + Chrome: Verwenden Sie den virtuellen Cursor von JAWS sowie die Liste der Formularfelder (Einfügen + F5) und Links (Einfügen + F7) auf mehreren Seiten. Bestätigen Sie, dass identische Steuerelemente auf der gesamten Website identische Namen tragen.
7. Sprachsteuerungs-Test: Verwenden Sie Windows Voice Access oder Dragon NaturallySpeaking und sprechen Sie den Namen eines wiederkehrenden Steuerelements auf einer Seite aus (z. B. „Click Search“). Navigieren Sie zu einer anderen Seite und sprechen Sie denselben Befehl. Wenn er fehlschlägt, sind die Namen aus funktionaler Sicht inkonsistent.

Wie man es behebt

Suchschaltfläche mit inkonsistenten Labels – Falsch

<!-- Homepage -->
<button type='submit' aria-label='Search'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Product listing page -->
<button type='submit' aria-label='Find products'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Blog page -->
<button type='submit' aria-label='Go'>
  <svg aria-hidden='true'>...</svg>
</button>

Suchschaltfläche mit inkonsistenten Labels – Richtig

<!-- Homepage, product listing page, and blog page all use the same label -->
<!-- Consistent aria-label across all pages ensures assistive technologies
     always announce the same name for this functionally identical button -->
<button type='submit' aria-label='Search'>
  <svg aria-hidden='true'>...</svg>
</button>

Symbolbild für dieselbe Aktion mit unterschiedlichem alt-Text – Falsch

<!-- Order history page -->
<a href='/print/order/123'>
  <img src='/icons/print.svg' alt='Print order' />
</a>

<!-- Invoice page -->
<a href='/print/invoice/456'>
  <img src='/icons/print.svg' alt='Print this document' />
</a>

<!-- Receipt page -->
<a href='/print/receipt/789'>
  <img src='/icons/print.svg' alt='Yazdir' />
</a>

Symbolbild für dieselbe Aktion mit unterschiedlichem alt-Text – Richtig

<!-- All print links across the site share the same alt text.
     The destination URL differentiates which document is printed;
     the control's accessible name remains consistent. -->
<a href='/print/order/123'>
  <img src='/icons/print.svg' alt='Print' />
</a>

<a href='/print/invoice/456'>
  <img src='/icons/print.svg' alt='Print' />
</a>

<a href='/print/receipt/789'>
  <img src='/icons/print.svg' alt='Print' />
</a>

Navigation-Schließen-Schaltfläche inkonsistent benannt – Falsch

<!-- Mobile menu on homepage -->
<button aria-label='Close menu' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Mobile menu on product page (different developer implemented it) -->
<button aria-label='Dismiss navigation' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

Navigation-Schließen-Schaltfläche inkonsistent benannt – Richtig

<!-- A shared component/template ensures the label is identical everywhere.
     Using a single reusable component or design token for the label
     eliminates the risk of developer-introduced inconsistencies. -->
<button aria-label='Close navigation menu' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

Social-Sharing-Links mit unterschiedlichen Namen – Falsch

<!-- Article page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
  <svg aria-hidden='true'>...</svg>
</a>

<!-- Video page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Tweet this'>
  <svg aria-hidden='true'>...</svg>
</a>

Social-Sharing-Links mit unterschiedlichen Namen – Richtig

<!-- Both pages use the same accessible name for the functionally
     identical sharing action. The URL parameter carries the context;
     the control name stays uniform. -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
  <svg aria-hidden='true'>...</svg>
</a>

Häufige Fehler

• Unterschiedliche aria-label-Werte in verschiedenen Templates für dieselbe Komponente verwenden: Wenn verschiedene Entwicklerinnen und Entwickler Seitentemplates unabhängig voneinander ohne gemeinsame Komponentenbibliothek erstellen, erhalten Symbolschaltflächen wie Schließen, Suche und Warenkorb häufig ad-hoc-Labels. Etablieren Sie für jedes wiederkehrende interaktive Element ein Designsystem-Token oder eine gemeinsame Komponente, sodass der zugängliche Name einmal definiert und überall wiederverwendet wird.
• Zugängliche Namen auf mehrsprachigen Seiten inkonsistent übersetzen: Eine Website kann eine Suchschaltfläche im Englischen korrekt mit „Search“ beschriften, dann aber eine inkonsistente türkische Entsprechung verwenden – manchmal „Ara“, manchmal „Arama Yap“ –, je nachdem, welches Seitentemplate zuerst lokalisiert wurde. Pflegen Sie pro Komponentenlabel einen einzigen Übersetzungsschlüssel und setzen Sie ihn in allen Sprachdateien durch.
• Kontextspezifische Suffixe an ansonsten identische Steuerelemente anhängen: Schaltflächen mit „Add to cart — Blue T-Shirt“, „Add to cart — Red Dress“ usw. zu beschriften, wenn die Kernfunktion (in den Warenkorb legen) dieselbe ist, ist nicht automatisch ein Verstoß gegen 3.2.4 – WCAG erlaubt zur Unterscheidung zusätzliche Informationen –, aber dies inkonsistent zu tun (manchmal mit Suffix, manchmal ohne) führt zu Verwirrung. Wählen Sie ein Muster und wenden Sie es einheitlich an.
• Sich auf den sichtbaren Text als Träger der Konsistenz verlassen, während sich aria-label-Overrides unterscheiden: Wenn eine Schaltfläche visuell „Search“ anzeigt, ein Template jedoch aria-label='Search the site' hinzufügt und ein anderes kein aria-label hat (sodass der zugängliche Name allein aus dem sichtbaren Text abgeleitet wird), werden Screenreader unterschiedliche Namen ansagen, obwohl die Schaltfläche gleich aussieht. Prüfen Sie die vollständige Berechnung des zugänglichen Namens, nicht nur das sichtbare Label.
• CMS-Redakteurinnen und -Redakteuren erlauben, Schaltflächentexte ohne Accessibility-Governance frei zu ändern: Content-Management-Systeme, die Schaltflächenlabels als editierbare Felder bereitstellen, ermöglichen es Redakteuren, „Submit“ nach persönlicher Vorliebe in „Send“ oder „Gönder“ umzubenennen. Beschränken Sie die Bearbeitung von Labels für funktionale UI-Komponenten oder fügen Sie eine Validierung hinzu, die Redakteure warnt, wenn ein vorgeschlagenes Label vom etablierten Standard abweicht.
• Drittanbieter-Widgets oder eingebettete Komponenten nicht zu prüfen: Chat-Widgets, Cookie-Banner und Zahlungs-Iframes von Drittanbietern enthalten häufig Schaltflächen, die anders beschriftet sind als die Konventionen der Host-Website. Überprüfen Sie die zugänglichen Namen von Drittanbieter-Komponenten und passen Sie sie, wo möglich, an Ihre Benennungskonventionen an, oder dokumentieren Sie die Abweichung als bekannte Ausnahme.
• Tooltip-Text (title-Attribut) als einzigen zugänglichen Namen in einigen Instanzen, aber aria-label in anderen zu verwenden: Das title-Attribut wird nicht von allen unterstützenden Technologien zuverlässig angesagt und gilt als schwache Quelle für zugängliche Namen. Wenn einige Instanzen einer wiederkehrenden Komponente title und andere aria-label verwenden, können sich die berechneten Namen aufgrund unterschiedlicher Handhabung durch Browser und Screenreader unterscheiden.
• Anzunehmen, dass Paginierungselemente wegen ihrer unterschiedlichen Nummern ausgenommen sind: „Next page“- und „Previous page“-Steuerelemente müssen, selbst wenn sie eine Seitenzahl im Label tragen (z. B. „Go to page 3“), ein konsistentes Muster verwenden. Die Mischung aus „Next“ auf einigen Seiten und „Next page“ oder „İleri“ auf anderen für dasselbe Paginierungselement verstößt gegen 3.2.4.
• Kopf- und Fußzeilenkomponenten nicht in jedem unterschiedlichen Seitentemplate zu testen: Websites haben häufig mehrere Seitentemplates (Startseite, Kategorieseite, Artikelseite, Checkout). Kopf- und Fußzeilenkomponenten können in den einzelnen Templates leicht unterschiedlich gerendert werden. Testende, die nur ein oder zwei Templates prüfen, können Inkonsistenzen übersehen, die durch template-spezifische Overrides eingeführt wurden.
• 3.2.4 mit 3.2.3 (Konsistente Navigation) verwechseln: Teams glauben manchmal, dass, wenn die Navigationsreihenfolge konsistent ist (3.2.3), auch die Benennung konsistent sein müsse – dabei handelt es sich um separate Anforderungen. Eine Navigationsleiste, die sich auf jeder Seite an derselben Stelle befindet (Konformität mit 3.2.3), kann dennoch 3.2.4 verletzen, wenn ihre Links auf verschiedenen Seiten unterschiedlich beschriftet sind. Gehen Sie beide Kriterien ausdrücklich in Ihrem QA-Prozess an.

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 Barrierefreiheitsanforderungen für eine breite Palette öffentlicher und privater digitaler Dienste fest. Die Verfügung schreibt die Einhaltung international anerkannter Barrierefreiheitsstandards vor – in der Praxis eine Angleichung an WCAG 2.2 Level AA – und verknüpft diese Konformität mit dem Barrierefreiheitslogo (Erişilebilirlik Logosu), das vom Ministerium für Familie und Sozialdienste (Aile ve Sosyal Hizmetler Bakanlığı) vergeben wird.

WCAG 3.2.4 Konsistente Identifizierung ist ein Kriterium der Stufe AA, was bedeutet, dass es sich um eine verpflichtende Anforderung handelt – nicht um eine unverbindliche Empfehlung – für Organisationen, die das Erişilebilirlik Logosu erhalten oder behalten möchten. Die fehlende Umsetzung konsistenter Identifizierung in einem digitalen Dienst verhindert die vollständige AA-Konformität und damit die Berechtigung für das Logo.

Die Verfügung gilt ausdrücklich für die folgenden Entitätstypen, die alle WCAG 3.2.4 in ihren Web- und Mobiloberflächen berücksichtigen müssen: öffentliche Institutionen und Regierungsbehörden; Banken und Finanzdienstleister; Krankenhäuser und Gesundheitsplattformen; Telekommunikationsanbieter mit 200.000 oder mehr Abonnentinnen und Abonnenten; E-Commerce-Plattformen; Reisebüros und Buchungsdienste; private Transportunternehmen; sowie Privatschulen, die vom Ministerium für Nationale Bildung (Milli Eğitim Bakanlığı) autorisiert sind.

Für diese Organisationen ist die praktische Auswirkung erheblich. Große institutionelle Websites – etwa das Online-Banking-Portal einer Bank, das Terminbuchungssystem eines Krankenhauses oder das Studierendeninformationssystem einer Universität – umfassen typischerweise Hunderte von Seiten und werden über viele Jahre von mehreren Entwicklungsteams aufgebaut. Inkonsistente Beschriftungen wiederkehrender Steuerelemente (Schaltflächen für Kontoaktionen, Suchfelder, Navigationssymbole) über diese Seiten hinweg sind ein häufiges und leicht übersehenes Fehlermuster. Compliance-Programme müssen seitenübergreifende Konsistenzprüfungen als eigenen Testschritt vorsehen, nicht nur automatisierte Scans einzelner Seiten.

Türkische Organisationen, die das Erişilebilirlik Logosu anstreben, sollten WCAG-3.2.4-Prüfungen in ihre Designsystem-Governance, Content-Management-Workflows und QA-Pipelines integrieren. Insbesondere sollte jede wiederverwendbare UI-Komponente ihren zugänglichen Namen als nicht editierbare Konstante auf Designsystem-Ebene definiert haben, wobei Übersetzungsschlüssel zentral verwaltet werden, um sicherzustellen, dass türkische und andere Sprachvarianten auf allen Seiten und Templates, in denen die Komponente erscheint, konsistent bleiben.