WCAG 2.4.4: Linkzweck (im Kontext)

WCAG 2.4.4 verlangt, dass sich das Ziel jedes Links aus seinem Linktext ergibt – oder aus dem Linktext zusammen mit seinem programmatisch ermittelbaren Kontext, also demselben Satz, Listenpunkt, Absatz oder derselben Tabellenzelle. „Hier klicken“, „Mehr“ und „Weiterlesen“ scheitern daran regelmäßig, weil sie außerhalb ihres Kontexts nichts aussagen.

(Englisch: Link Purpose (In Context).)

Das Wichtigste in Kürze

• Der Maßstab ist die Linkliste, nicht die Seite: Screenreader-Nutzer lassen sich alle Links einer Seite aus dem Zusammenhang gerissen anzeigen.
• Als Kontext zählt nur, was programmatisch verbunden ist – derselbe Satz, Absatz, Listenpunkt, dieselbe Tabellenzelle oder die zugehörige Kopfzelle. Eine Überschrift zwei Absätze weiter oben zählt nicht.
• Die Optik darf „Mehr erfahren“ bleiben. Ergänzt man den zugänglichen Namen um das Ziel, ist das Kriterium erfüllt, ohne dass sich das Design ändert.
• Gleicher Text, gleiches Ziel – gleicher Link. Zwei Links mit identischem Text, die woandershin führen, sind ein Verstoß; identischer Text auf dasselbe Ziel ist unproblematisch.
• Bei Datei-Links gehören Format und Größe in den Text („Jahresbericht (PDF, 2 MB)“) – sonst weiß niemand vorher, was passiert.
• Automatisch prüfbar ist das nicht. Ob ein Name existiert, findet ein Werkzeug; ob er den Zweck nennt, entscheidet ein Mensch.
• Auf Stufe AAA verschärft 2.4.9 die Regel: Dann muss der Linktext allein genügen, ganz ohne Kontext.

Was ist ein guter Linktext?

Der Normtext erlaubt zwei Wege: Entweder ergibt sich der Zweck aus dem Linktext allein, oder aus dem Linktext zusammen mit dem programmatisch ermittelbaren Kontext. Genau dieses „programmatisch ermittelbar“ ist der Punkt, an dem in Prüfungen gestritten wird. Es zählt:

• der Satz, in dem der Link steht,
• der Absatz oder Listenpunkt, der ihn enthält,
• die Tabellenzelle und die zugehörige Kopfzelle,
• das übergeordnete Listenelement bei verschachtelten Listen.

Es zählt nicht: eine Überschrift weiter oben, ein Bild daneben, eine Bildunterschrift in einem anderen Element oder die räumliche Nähe auf dem Bildschirm. Für eine Karte mit Bild, Überschrift, Teasertext und einem „Mehr erfahren“-Link am Ende bedeutet das: Die Überschrift der Karte ist kein Kontext, solange sie nicht Teil desselben Elements ist.

Praktisch heißt das: Der Kontext ist ein zulässiger Weg, aber nicht der robuste. Nur ein selbsterklärender Linktext funktioniert auch in der Linkliste, in der Sprachsteuerung, in der Suchergebnisvorschau und beim Überfliegen. Den vollen Wortlaut samt der zulässigen Techniken führt das Understanding-Dokument des W3C zu 2.4.4 auf; im BITV-Test heißt der Prüfschritt „2.4.4 Aussagekräftige Linktexte“.

Die Ausnahme im Normtext: mehrdeutig für alle

Der Kriteriumstext endet mit einer Einschränkung, die selten mitzitiert wird: „… außer in Fällen, in denen der Zweck des Links mehrdeutig für Benutzer im Allgemeinen wäre.“ Gemeint sind Links, bei denen die Unklarheit Absicht ist und alle gleich trifft – die drei Türen in einem Quiz, das verdeckte Los in einem Gewinnspiel, der bewusst unbenannte Link in einem Rätsel. Wer sieht, weiß dort genauso wenig wie wer hört.

Der Prüfsatz dazu ist eine einzige Frage: Weiß ein sehender Mensch an dieser Stelle mehr als jemand mit Screenreader? Lautet die Antwort ja, greift die Ausnahme nicht. Sie ist deshalb kein Notausgang für schwache Linktexte: Ein „hier“ im Fließtext ist – wenn überhaupt – über den Kontext-Weg erfüllt, nie über die Ausnahme. Und zwölf Kacheln mit „Mehr erfahren“ deckt sie erst recht nicht, denn deren Ziele stehen ja fest; sie stehen nur nicht im Link.

Wen betrifft es besonders?

Screenreader-Nutzer navigieren häufig über Links – entweder mit der Tab-Taste von Link zu Link oder über die Elementliste, die alle Links einer Seite untereinander zeigt. In beiden Fällen fehlt der umgebende Text. Zehnmal „Mehr erfahren“ ist dort zehnmal dieselbe Nicht-Information.

Für Sprachsteuerungs-Nutzer ist der Linktext der Befehl. „Klicke Mehr erfahren“ trifft bei fünf gleichen Links entweder das Falsche oder löst eine Rückfrage mit Nummernauswahl aus – aus einem Klick werden drei Schritte.

Menschen mit kognitiven Einschränkungen profitieren davon, dass ein Link vorher sagt, wohin er führt: Das reduziert Fehlklicks und den Aufwand, sich zurückzuorientieren. Und alle Überflieger lesen ohnehin nur die hervorgehobenen Elemente – Linktexte sind deshalb ein Lesbarkeits- und nebenbei ein SEO-Signal.

Richtig & falsch im Code

<!-- Falsch: Ziel steht außerhalb des Links -->
<p>Unsere Preisliste finden Sie <a href="/preise.html">hier</a>.</p>

<!-- Falsch: identischer Text, verschiedene Ziele -->
<a href="/preise.html">Mehr erfahren</a>
<a href="/kurse.html">Mehr erfahren</a>

<!-- Richtig: der Link nennt das Ziel selbst -->
<p>Alle Details stehen in der <a href="/preise.html">Preisliste</a>.</p>

Für Karten-Layouts, in denen das Design ein kurzes „Mehr erfahren“ verlangt, gibt es zwei saubere Muster:

<!-- Muster A: unsichtbarer Zusatz im Link -->
<a href="/kurs-aria.html">
  Mehr erfahren<span class="visually-hidden"> zum Kurs „ARIA in der Praxis“</span>
</a>

<!-- Muster B: die Überschrift ist der Link, die Karte wird klickbar gemacht -->
<article class="card">
  <h3><a href="/kurs-aria.html" class="card-link">Kurs „ARIA in der Praxis“</a></h3>
  <p>Drei Stunden Praxis zu Rollen, Zuständen und Live-Regionen.</p>
</article>

/* Muster B: die ganze Karte klickbar, ohne zweiten Link */
.card { position: relative; }
.card-link::after { content: ''; position: absolute; inset: 0; }

Muster B ist das robustere – es erzeugt genau einen Link pro Karte, der Linktext ist die Überschrift, und die Trefferfläche bleibt die ganze Karte. Details und Fallstricke stehen unter klickbare Cards.

Bei aria-label ist Vorsicht geboten: Es ersetzt den sichtbaren Text vollständig. Wer es nutzt, muss den sichtbaren Text darin wörtlich enthalten, sonst funktioniert die Sprachsteuerung nicht mehr – das verlangt 2.5.3 Beschriftung im Namen.

<!-- Falsch: sichtbarer Text kommt im Namen nicht vor -->
<a href="/preise.html" aria-label="Zur Preisübersicht">Mehr</a>

<!-- Richtig: sichtbarer Text ist im Namen enthalten -->
<a href="/preise.html" aria-label="Mehr zur Preisübersicht">Mehr</a>

So testest du es

1. Linkliste ziehen: In NVDA mit NVDA + F7 die Elementliste öffnen und auf „Links“ stellen; in VoiceOver über den Rotor. Ist jeder Eintrag für sich verständlich?
2. Volltextsuche nach den üblichen Verdächtigen: „hier“, „mehr“, „weiter“, „Link“, „klicken“, „Details“, „Info“. Das findet in fünf Minuten den Großteil der Fälle.
3. Doppelte Linktexte suchen: Zwei identische Texte, die auf verschiedene Ziele zeigen, sind ein Verstoß – auch wenn beide für sich aussagekräftig sind.
4. Karten-Layouts einzeln prüfen: Enthält der zugängliche Name des Links das Ziel? Im Accessibility-Panel der DevTools steht er direkt am Element.
5. Datei-Links prüfen: Steht Format und Größe im Text? Wird eine Datei heruntergeladen, ohne dass es vorher jemand ankündigt?
6. Auf dem Smartphone dieselbe Liste ziehen: Das BFSG erfasst Apps genauso wie Websites. In VoiceOver stellst du den Rotor mit der Zwei-Finger-Drehgeste auf „Links“, in TalkBack wählst du über die vertikale Dreifinger-Wischgeste die Navigationsoption „Links“ – und blätterst dann durch wie im Browser. Genau so geht der BITV-Test im Prüfschritt 2.4.4 nach WCAG2ICT vor; Links auf PDFs und externe Ziele sieht er sich dort stichprobenartig an.

Linktexte wie „hier“ oder „mehr erfahren“ und nackte URLs als Linktext meldet der Struktur-Check automatisch.

Häufiger Fehler in der Praxis

Der Klassiker ist nicht das „hier“ im Fließtext – das ist seit Jahren bekannt. Der Klassiker sind Kachelübersichten: Blog-Teaser, Produktkarten, Referenzkacheln. Jede Kachel endet mit „Mehr erfahren“, und weil das Design konsistent ist, sind es zwölf identische Links auf einer Seite. Optisch großartig, in der Linkliste unbrauchbar. Da hilft kein Nachbessern am Text – da muss man ans Muster ran.

Der zweite Fall ist der doppelte Link pro Karte: Bild und Überschrift zeigen beide auf dasselbe Ziel, das Bild hat einen Alt-Text, die Überschrift den Titel – der Screenreader liest beides. Für 2.4.4 ist das kein Verstoß, aber es verdoppelt die Linkliste. Die Lösung ist alt="" am Bild, weil der Text die Information schon trägt (siehe 1.1.1).

Und dritter Punkt, der in Behördenprojekten immer wieder auftaucht: PDF-Links ohne Ankündigung. Ein Link führt scheinbar auf eine Seite und öffnet stattdessen ein 14-MB-Dokument. Das ist nicht nur unhöflich, es kostet Menschen mit begrenztem Datentarif Geld – und wer per Screenreader arbeitet, landet unvermittelt in einem PDF statt im Browser. Format und Größe im Linktext lösen das in vier Wörtern.

Häufige Fragen

Ist „hier klicken“ automatisch ein Verstoß?

Nicht automatisch – wenn der Satz drumherum das Ziel nennt und der Link im selben Satz steht, ist der Kontext programmatisch ermittelbar und 2.4.4 formal erfüllt. In der Linkliste bleibt der Eintrag trotzdem nutzlos, und auf Stufe AAA fällt er durch. Deshalb ist der aussagekräftige Linktext auch dann die bessere Wahl, wenn die Mindestanforderung erfüllt wäre.

Dürfen mehrere Links denselben Text haben?

Ja, solange sie zum selben Ziel führen. Zwei „Zur Preisliste“-Links auf derselben Seite sind unkritisch. Führen identische Texte aber auf verschiedene Seiten, ist das ein Verstoß – und zugleich der Fall, der Nutzerinnen am meisten Zeit kostet.

Zählt die Überschrift einer Karte als Kontext?

Nur wenn sie programmatisch mit dem Link verbunden ist – also im selben Element liegt oder per aria-labelledby referenziert wird. Räumliche Nähe genügt nicht. Deshalb ist das Muster „Überschrift ist der Link“ dem Muster „Überschrift plus separater Mehr-Link“ überlegen.

Wie kennzeichne ich Links, die in einem neuen Fenster öffnen?

WCAG 2.4.4 verlangt das nicht ausdrücklich, aber 3.2.5 auf Stufe AAA und die deutsche Prüfpraxis erwarten einen Hinweis. Am robustesten steht er im zugänglichen Namen: <a href="…" target="_blank">Jahresbericht <span class="visually-hidden">(öffnet in neuem Fenster)</span></a>. Ein reines Symbol ohne Textalternative genügt nicht.

Gilt das Kriterium auch für Buttons?

Nein, für Buttons greift 4.1.2 Name, Rolle, Wert – dort ist ein zugänglicher Name Pflicht. Die praktische Anforderung ist aber dieselbe: „Absenden“ sagt mehr als „OK“, und ein Icon-Button ohne Namen fällt in beiden Fällen durch.

Verwandte Themen

• Buttons vs. Links – erst das richtige Element, dann der richtige Text
• Klickbare Cards – das Kachelmuster ohne doppelte Links
• 2.5.3 Beschriftung im Namen – warum aria-label den sichtbaren Text enthalten muss
• 2.4.6 Überschriften und Beschriftungen – dieselbe Logik für Überschriften
• Interne Verlinkung als Strategie – dieselben Texte als SEO-Hebel