WCAG 2.4.4: Zweck des Links (im Kontext)

Was diese Regel bedeutet

WCAG 2.4.4 — Linkzweck (im Kontext) — ist ein Erfolgskriterium der Stufe A unter dem Prinzip Bedienbarkeit. Es besagt, dass der Zweck jedes Links entweder allein aus dem Linktext oder aus dem Linktext in Kombination mit seinem programmatisch bestimmten Linkkontext ermittelbar sein muss. Wenn beides nicht ausreicht, erfüllt der Link dieses Kriterium nicht.

Der Ausdruck „programmatisch bestimmter Linkkontext“ ist in den WCAG sorgfältig definiert. Er bezieht sich auf Informationen, die aus demselben Satz, Absatz, Listenelement oder Tabellenfeld wie der Link oder aus der Überschrift abgeleitet werden können, die einem Abschnitt mit dem Link vorausgeht. Er umfasst außerdem Kontext, der über ARIA-Beziehungen wie aria-labelledby oder aria-describedby offengelegt wird. Entscheidend ist, dass dieser Kontext programmatisch verfügbar sein muss — das bedeutet, dass Hilfstechnologien ihn automatisch auslesen können — und nicht nur visuell für sehende Nutzer angedeutet wird.

Praktisch gesehen sind die folgenden HTML-Elemente und -Attribute direkt von diesem Kriterium betroffen: <a href>-Ankerelemente, <area>-Elemente in Image Maps, <button>-Elemente, die Navigation auslösen, Elemente, die mithilfe von ARIA-Rollen wie role='link' so gestaltet oder geskriptet sind, dass sie sich wie Links verhalten, sowie SVG-<a>-Elemente. Der zugängliche Name des Links — berechnet aus seinem inneren Text, aria-label, aria-labelledby oder einem alt-Attribut auf einem Kindelement-Bild — ist das primäre Mittel zur Vermittlung des Zwecks.

Was als bestanden gilt: Ein Link besteht, wenn ein Nutzer sein Ziel oder seine Funktion ohne zusätzlichen Kontext bestimmen kann (z. B. „Laden Sie den Jahresbericht 2024 als PDF herunter“), oder wenn der umgebende programmatische Kontext den Zweck klar macht (z. B. ein „Mehr lesen“-Link innerhalb eines <li>, das mit dem Artikeltitel beginnt). Der Linktext muss nicht auf der gesamten Seite global eindeutig sein; er muss nur in seinem Kontext eindeutig sein.

Was als nicht bestanden gilt: Generischer Linktext wie „hier klicken“, „mehr lesen“, „hier“, „mehr“ oder „Link“ fällt durch, wenn der umgebende programmatische Kontext das Ziel nicht eindeutig macht. Ein Bildlink mit einem fehlenden oder leeren alt-Attribut fällt ebenfalls durch, weil der zugängliche Name vollständig fehlt.

Offizielle Ausnahme: Die WCAG erkennt eine Ausnahme an. Wenn der Linkzweck absichtlich mehrdeutig ist — das heißt, dass die Offenlegung des Zwecks im Voraus seinen Nutzen oder den des umgebenden Inhalts zunichtemachen würde —, gilt das Kriterium nicht. Diese Ausnahme ist äußerst eng gefasst und in realen Szenarien selten anwendbar.

Warum es wichtig ist

Laut der Weltgesundheitsorganisation haben weltweit etwa 2,2 Milliarden Menschen eine Form von Sehbeeinträchtigung. Unter ihnen sind blinde Nutzer, die auf Screenreader angewiesen sind, am stärksten von mehrdeutigem Linktext betroffen. Screenreader-Software wie NVDA, JAWS und VoiceOver ermöglicht es Nutzern, eine Seite zu navigieren, indem eine Liste aller Links erzeugt wird, die aus ihrem Kontext extrahiert werden. Wenn diese Liste Dutzende Einträge enthält, die alle „mehr lesen“ oder „hier klicken“ lauten, können blinde Nutzer nicht bestimmen, welcher Link wohin führt, ohne zu jedem Link zurückzukehren und den umgebenden Inhalt zu lesen — ein zeitaufwendiger und desorientierender Prozess.

Motorisch beeinträchtigte Nutzer, die mit Tastaturbedienung, Schaltersteuerungen oder Blickverfolgungsgeräten navigieren, profitieren ebenfalls erheblich. Diese Nutzer springen häufig nacheinander durch interaktive Elemente und verlassen sich auf die Beschriftung des fokussierten Elements, um zu entscheiden, ob sie es aktivieren. Mehrdeutiger Linktext erzwingt zusätzliche Navigationsschritte, die Ermüdung und Fehlerraten erhöhen.

Nutzer mit kognitiven Beeinträchtigungen — einschließlich Personen mit Aufmerksamkeitsstörungen, Gedächtnisbeeinträchtigungen oder geringer Literalität — profitieren von klaren, beschreibenden Linktexten, weil sie die kognitive Belastung verringern, die zum Verständnis der Seitenstruktur erforderlich ist. Sie müssen keine Kontextinformationen im Arbeitsgedächtnis behalten, während sie Links überfliegen.

Ein konkretes Szenario aus der Praxis: Betrachten Sie eine E‑Commerce-Produktlistenseite, die zehn Produkte anzeigt, jedes mit einem „Jetzt kaufen“-Button und einem „Mehr erfahren“-Link, die identisch dargestellt sind. Ein blinder Nutzer, der die Linkliste nutzt, hört zehn aufeinanderfolgende „Mehr erfahren“-Einträge ohne Hinweis darauf, auf welches Produkt sich jeder Link bezieht. Um das richtige Produkt zu kaufen, muss er den gesamten umgebenden Kontext für jeden Link lesen — ein Vorgang, der Minuten statt Sekunden dauern kann. Mit beschreibendem Linktext wie „Mehr erfahren über die Sony WH-1000XM5 Kopfhörer“ ist dieselbe Aufgabe mit einer einzigen Navigationsgeste erledigt.

Über die Barrierefreiheit hinaus bietet beschreibender Linktext messbare SEO-Vorteile. Suchmaschinen-Crawler verwenden Ankertext als Signal, um den Inhalt der verlinkten Seite zu verstehen. Beschreibender, schlüsselwortreicher Linktext verbessert die Crawlability und Indexierbarkeit verlinkter Ressourcen und trägt positiv zu den Suchrankings bei. Außerdem senkt klarer Linktext Absprungraten und Supportanfragen, indem er die Erwartungen der Nutzer vor der Navigation präzise setzt.

Verwandte Axe-core-Regeln

• link-name: Diese Regel prüft, dass jedes <a>-Element mit einem href-Attribut, jedes Element mit role='link' und jedes <area>-Element einen nicht leeren zugänglichen Namen hat. Der zugängliche Name wird über die standardmäßige ARIA-Berechnung des zugänglichen Namens ermittelt: innerer Textinhalt, aria-label, aria-labelledby oder das alt-Attribut eines Kindelements <img>. Axe markiert einen Verstoß, wenn der berechnete zugängliche Name leer, nur aus Leerzeichen bestehend oder vollständig abwesend ist. Diese Regel erfasst die schwerwiegendste Form eines 2.4.4-Verstoßes — Links, die völlig unbenannt sind —, kann jedoch keine Links erkennen, deren Namen zwar technisch vorhanden, aber semantisch bedeutungslos sind (z. B. „hier klicken“ oder „mehr lesen“), da automatisierte Tools die Absicht hinter generischen Zeichenketten nicht bestimmen können.
• duplicate-id-aria: Diese Regel prüft, dass keine zwei Elemente auf der Seite denselben id-Wert teilen, wenn diese id von einem ARIA-Attribut wie aria-labelledby oder aria-describedby referenziert wird. Doppelte IDs, die in ARIA-Beziehungen verwendet werden, führen dazu, dass der Browser die Referenz unvorhersehbar auflöst — typischerweise auf das erste passende Element in der DOM-Reihenfolge —, was dazu führen kann, dass der zugängliche Name eines Links vollständig aus dem falschen Element berechnet wird. Wenn beispielsweise zwei Links jeweils aria-labelledby='product-title' verwenden und zwei Elemente diese ID teilen, können Screenreader für einen oder beide Links den falschen Produktnamen ansagen, was direkt gegen 2.4.4 verstößt. Axe markiert dies als kritisches Problem, weil der resultierende zugängliche Name unzuverlässig ist.

Es ist wichtig, die Grenzen automatisierter Tests für dieses Kriterium zu verstehen. Tools wie axe-core können überprüfen, ob ein Link einen zugänglichen Namen hat, aber sie können nicht überprüfen, ob der Name bedeutungsvoll ist. Ein Link mit dem Namen „hier“ besteht die link-name-Regel automatisch, weil die Zeichenkette nicht leer ist. Menschliches Urteil ist erforderlich, um zu beurteilen, ob generischer Linktext 2.4.4 verletzt. Dies macht manuelle Tests zu einer unverzichtbaren Ergänzung zu automatisierten Scans für dieses Kriterium.

Wie man testet

1. Automatischer Scan mit axe DevTools oder Lighthouse: Installieren Sie die axe DevTools-Browsererweiterung (Chrome oder Firefox) oder führen Sie ein Lighthouse-Accessibility-Audit in den Chrome DevTools aus. Starten Sie einen Scan der gesamten Seite und filtern Sie die Ergebnisse nach den Regeln link-name und duplicate-id-aria. Überprüfen Sie jedes markierte Element: Bestätigen Sie, dass der berechnete zugängliche Name bei link-name-Verstößen fehlt oder leer ist, und verifizieren Sie, dass doppelte IDs ARIA-Label-Referenzen bei duplicate-id-aria-Verstößen unterbrechen. Beachten Sie, dass das Bestehen dieser automatisierten Prüfungen keine vollständige 2.4.4-Konformität garantiert — fahren Sie mit den manuellen Schritten fort.
2. Manuelle Überprüfung der Linkliste: Drücken Sie in NVDA mit Firefox die Tastenkombination Einfügen+F7, um den Dialog „Elementliste“ zu öffnen, und wählen Sie „Links“. Überprüfen Sie jeden Eintrag in der Liste isoliert, ohne visuellen Kontext. Fragen Sie: Können Sie aus dem Text allein bestimmen, wohin jeder Link führt? Wiederholen Sie dies in JAWS mit Chrome, indem Sie Einfügen+F7 verwenden, um die Linkliste zu öffnen. In VoiceOver mit Safari unter macOS drücken Sie Control+Option+U, um den Web-Item-Rotor zu öffnen, und wählen Sie „Links“. Jeder Link, dessen Zweck isoliert betrachtet mehrdeutig ist, sollte im Hinblick auf seinen programmatischen Kontext untersucht werden.
3. Tastaturnavigationstest: Navigieren Sie nur mit der Tab-Taste durch alle interaktiven Elemente auf der Seite. Jedes Mal, wenn der Fokus auf einem Link landet, lesen Sie nur den angesagten Text (nicht den umgebenden visuellen Inhalt). Wenn Sie das Ziel des Links aus dem, was angesagt wird, nicht bestimmen können, verstößt der Link wahrscheinlich gegen 2.4.4. Achten Sie besonders auf reine Symbol-Links (Social-Media-Icons, Pfeiltasten) und Bildlinks.
4. Kontextüberprüfung: Für Links, die auf umgebenden Kontext angewiesen sind (z. B. „Mehr lesen“ innerhalb eines Listenelements), inspizieren Sie das DOM, um zu bestätigen, dass der Kontexttext sich im selben Satz, Absatz, Listenelement oder Tabellenfeld wie der Link befindet. Kontext, der nur visuell benachbart, aber nicht programmatisch verknüpft ist, erfüllt das Kriterium nicht. Verwenden Sie die DevTools des Browsers, um den berechneten Accessibility-Tree zu inspizieren und die Beziehung zu bestätigen.
5. ARIA-Label-Audit: Durchsuchen Sie den Seitenquelltext nach allen Verwendungen von aria-labelledby und aria-describedby bei Linkelementen. Verifizieren Sie, dass jede referenzierte ID genau einmal im Dokument existiert und dass das referenzierte Element den beabsichtigten beschreibenden Text enthält. Verwenden Sie das Accessibility-Tree-Panel des Browsers (in den Chrome DevTools unter dem Tab „Accessibility“ verfügbar), um den berechneten Namen für jeden Link zu bestätigen.

Wie man behebt

Nur-Icon-Link ohne zugänglichen Namen — Falsch

<!-- Ein Icon-Link ohne Text und ohne aria-label -->
<a href='https://twitter.com/accsible'>
  <svg viewBox='0 0 24 24' width='24' height='24'>
    <path d='M23 3a10.9 10.9...' />
  </svg>
</a>

Nur-Icon-Link ohne zugänglichen Namen — Richtig

<!-- aria-label stellt einen beschreibenden zugänglichen Namen für Screenreader bereit -->
<a href='https://twitter.com/accsible' aria-label='Accsible auf Twitter'>
  <svg viewBox='0 0 24 24' width='24' height='24' aria-hidden='true' focusable='false'>
    <path d='M23 3a10.9 10.9...' />
  </svg>
</a>

Generische „Mehr lesen“-Links in einer Kartenliste — Falsch

<!-- Mehrere identische Linktexte ohne unterscheidenden Kontext -->
<ul>
  <li>
    <h3>Istanbul Accessibility Summit 2024</h3>
    <p>Begleiten Sie uns zum jährlichen Gipfel zur digitalen Inklusion.</p>
    <a href='/events/istanbul-2024'>Read more</a>
  </li>
  <li>
    <h3>New WCAG 2.2 Guidelines Released</h3>
    <p>W3C hat die aktualisierten Richtlinien veröffentlicht.</p>
    <a href='/news/wcag-22'>Read more</a>
  </li>
</ul>

Generische „Mehr lesen“-Links in einer Kartenliste — Richtig

<!-- Option 1: Visuell versteckter Text, der an den Link angehängt wird -->
<ul>
  <li>
    <h3>Istanbul Accessibility Summit 2024</h3>
    <p>Begleiten Sie uns zum jährlichen Gipfel zur digitalen Inklusion.</p>
    <a href='/events/istanbul-2024'>
      Read more
      <span class='sr-only'>about the Istanbul Accessibility Summit 2024</span>
    </a>
  </li>
  <li>
    <h3>New WCAG 2.2 Guidelines Released</h3>
    <p>W3C hat die aktualisierten Richtlinien veröffentlicht.</p>
    <a href='/news/wcag-22'>
      Read more
      <span class='sr-only'>about the New WCAG 2.2 Guidelines</span>
    </a>
  </li>
</ul>

<!-- Option 2: aria-label verwenden, um den sichtbaren Text vollständig zu überschreiben -->
<a href='/events/istanbul-2024' aria-label='Read more about the Istanbul Accessibility Summit 2024'>
  Read more
</a>

Bildlink mit leerem alt-Attribut — Falsch

<!-- Das Bild hat ein leeres alt, wodurch der Link völlig unbenannt ist -->
<a href='/products/overlay-widget'>
  <img src='widget-logo.png' alt='' />
</a>

Bildlink mit leerem alt-Attribut — Richtig

<!-- Das alt-Attribut des Bildes stellt den zugänglichen Namen des Links bereit -->
<a href='/products/overlay-widget'>
  <img src='widget-logo.png' alt='Accsible Overlay Widget — Produktdetails' />
</a>

aria-labelledby verweist auf eine doppelte ID — Falsch

<!-- Zwei Elemente teilen dieselbe ID; der zweite Link wird der falschen Beschriftung zugeordnet -->
<div>
  <span id='card-title'>Accsible SDK Documentation</span>
  <a href='/docs' aria-labelledby='card-title'>View</a>
</div>
<div>
  <span id='card-title'>Accsible Pricing Plans</span>
  <a href='/pricing' aria-labelledby='card-title'>View</a>
</div>

aria-labelledby verweist auf eine doppelte ID — Richtig

<!-- Jede ID ist eindeutig; jeder Link wird der richtigen Beschriftung zugeordnet -->
<div>
  <span id='card-title-docs'>Accsible SDK Documentation</span>
  <a href='/docs' aria-labelledby='card-title-docs'>View</a>
</div>
<div>
  <span id='card-title-pricing'>Accsible Pricing Plans</span>
  <a href='/pricing' aria-labelledby='card-title-pricing'>View</a>
</div>

Häufige Fehler

• Verwendung von „hier klicken“, „hier“, „mehr“ oder „mehr lesen“ als Linktext ohne zusätzlichen zugänglichen Namen über aria-label, aria-labelledby oder visuell versteckte <span>-Elemente — diese Zeichenketten sind bedeutungslos, wenn sie von einem Screenreader aus dem visuellen Kontext herausgelöst werden.
• Hinzufügen eines aria-label zu einem Link, der einen anderen sichtbaren Text enthält, ohne sicherzustellen, dass das Label mit der sichtbaren Textzeichenkette beginnt — dies verstößt gegen WCAG 2.5.3 (Label im Namen) und führt zu Verwirrung bei Nutzern von Sprachsteuerung, die versuchen, den Link durch Aussprechen seines sichtbaren Namens zu aktivieren.
• Setzen von alt='' bei einem Bild, das der einzige Inhalt eines Links ist, wodurch der berechnete zugängliche Name des Links leer wird und ein link-name-Verstoß entsteht — leeres alt ist für dekorative Bilder korrekt, aber nicht, wenn das Bild der einzige Inhalt eines interaktiven Elements ist.
• Anwenden von aria-hidden='true' auf den einzigen Textknoten innerhalb eines Links, wodurch der zugängliche Name aus dem Accessibility-Tree entfernt wird und der Link für Screenreader-Nutzer unbenannt bleibt.
• Wiederverwendung desselben id-Werts über mehrere Elemente hinweg, die von aria-labelledby bei verschiedenen Links referenziert werden, was dazu führt, dass Screenreader aufgrund unvorhersehbarer ID-Auflösung für einen oder mehrere Links den falschen zugänglichen Namen berechnen.
• Einbetten einer gesamten Kartenkomponente (Überschrift, Bild, Absatz und Button) in ein einziges <a>-Tag, wodurch Screenreader den gesamten Karteninhalt als zugänglichen Namen des Links vorlesen — eine ausführliche und desorientierende Erfahrung —, anstatt ein kurzes, beschreibendes Label zu verwenden.
• Sich ausschließlich auf ein CSS-title-Attribut-Tooltip oder eine :hover-Pseudo-Klasse zu verlassen, um Linkkontext bereitzustellen — das title-Attribut wird von Screenreadern uneinheitlich exponiert und ist für reine Tastaturnutzer, die keine Hover-Zustände auslösen können, vollständig unzugänglich.
• Verwendung der URL selbst als Linktext (z. B. <a href='https://example.com/p?id=12345'>https://example.com/p?id=12345</a>), was für Screenreader unaussprechlich und für Nutzer mit kognitiven Beeinträchtigungen bedeutungslos ist.
• Dynamische Generierung von Link-IDs oder ARIA-Attributwerten mit JavaScript-Frameworks, ohne Eindeutigkeit sicherzustellen — React-, Vue- und Angular-Komponenten, die in Listen gerendert werden, erzeugen häufig doppelte IDs, sofern keine expliziten Keying-Strategien implementiert werden.
• Vergessen, focusable='false' zu Inline-SVG-Icons innerhalb von Links in Internet Explorer und älteren Edge-Versionen hinzuzufügen, was dazu führt, dass das SVG einen eigenen Tabstopp erhält und Screenreader das SVG getrennt vom Linktext ansagen, wodurch die Berechnung des zugänglichen Namens aufgespalten wird.

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 Anforderungen an die digitale Barrierefreiheit fest, die an WCAG 2.2 ausgerichtet sind. WCAG 2.4.4 Linkzweck (im Kontext) ist ein Kriterium der Stufe A, was bedeutet, dass es in die verbindliche Basisanforderung fällt, die alle erfassten Stellen erfüllen müssen.

Die Verfügung gilt für einen definierten Satz von Stellenarten im öffentlichen wie im privaten Sektor. Öffentliche Institutionen — einschließlich Ministerien, staatlicher Behörden, Kommunen und staatlicher Universitäten — müssen innerhalb eines Jahres nach Veröffentlichung der Verfügung vollständige Konformität mit Stufe A erreichen. Private Sektorunternehmen, die von der Verfügung erfasst sind, haben ein zweijähriges Compliance-Fenster. Der Geltungsbereich im privaten Sektor ist breit und umfasst ausdrücklich E‑Commerce-Plattformen, Banken und Finanzinstitute, private Krankenhäuser und Gesundheitsdienstleister, Telekommunikationsanbieter mit 200.000 oder mehr Abonnenten, Reisebüros, private Transportunternehmen und Privatschulen, die vom Ministerium für Nationale Bildung autorisiert sind.

Für all diese Stellen stellt nicht konformer Linktext einen direkten Verstoß gegen die Vorschriften dar. Betrachten Sie eine türkische E‑Commerce-Plattform, die Produktlistenseiten mit wiederholten „Satın Al“ (Jetzt kaufen) oder „Devamını Oku“ (Mehr lesen)-Links ohne programmatischen Kontext anzeigt. Ein blinder Nutzer, der sich auf TalkBack, NVDA oder VoiceOver verlässt, könnte nicht bestimmen, auf welches Produkt sich jeder Link bezieht, was einen Verstoß gegen 2.4.4 und eine Verletzung der Anforderungen der Verfügung darstellt. Ebenso würde ein Terminbuchungsportal eines öffentlichen Krankenhauses, das Navigationslinks nur mit Icons und ohne zugängliche Namen verwendet, sowohl gegen die link-name-Axe-Regel als auch gegen das Mandat der Verfügung verstoßen.

Die Einhaltung von 2.4.4 ist nicht nur ein technisches Kontrollkästchen. Die Verfügung signalisiert ein breiteres staatliches Bekenntnis zur digitalen Inklusion für die etwa 8,5 Millionen Bürgerinnen und Bürger der Türkei mit Behinderungen. Für erfasste Stellen ist die proaktive Behebung von Verstößen gegen den Linkzweck — durch Standards im Designsystem, Schulungen für Entwickler und automatisiertes CI/CD-Scanning — sowohl eine rechtliche Verpflichtung als auch eine sinnvolle Investition in Nutzbarkeit und Suchleistung. Die Nichteinhaltung innerhalb der vorgeschriebenen Fristen kann zu aufsichtsrechtlichen Maßnahmen durch die in der Verfügung benannten zuständigen Aufsichtsbehörden führen.