Linktext, der auch außerhalb des Kontexts Sinn ergibt

Wie Screenreader-Nutzer tatsächlich navigieren

Bevor wir darüber sprechen, wie man Linktext schreibt, hilft es zu verstehen, wie Menschen Links tatsächlich nutzen, wenn sie die Seite nicht sehen können.

Screenreader bieten eine Abkürzung, von deren Existenz die meisten sehenden Nutzer nichts wissen: Durch Drücken einer einzigen Taste (in den meisten Screenreadern üblicherweise der Buchstabe L) werden alle Links auf der Seite nacheinander durchlaufen und einzeln, außerhalb des Kontexts, vorgelesen. Nutzer setzen dies ein, um eine Seite schnell zu überfliegen — so wie das Auge eines sehenden Nutzers Überschriften und Handlungsaufforderungs-Buttons überfliegen könnte.

Wenn Ihre Seite zwölf Links mit dem Text “Mehr lesen” enthält, ist diese Liste bedeutungslos. Der Nutzer hört: “Mehr lesen. Mehr lesen. Mehr lesen. Mehr lesen…” Er kann nicht erkennen, wohin einer davon führt.

Das ist das grundlegende Problem, das die Barrierefreiheit von Linktext zu lösen versucht: Jeder Link muss selbsterklärend sein, denn der Kontext verschwindet, wenn man per Link navigiert.

Was WCAG sagt

2.4.4 Linkzweck (im Kontext) auf Stufe A verlangt, dass sich der Zweck jedes Links allein aus dem Linktext oder aus dem Linktext zusammen mit seinem umgebenden Kontext (dem Absatz, Listenelement, der Tabellenzelle oder Überschrift, in der er steht) bestimmen lässt.

2.4.9 Linkzweck (nur Link) auf Stufe AAA geht weiter und verlangt, dass sich der Linkzweck allein aus dem Linktext ergibt, ohne sich auf den Kontext zu stützen. Dies anzustreben ist eine gute Idee, selbst wenn Sie nur die AA-Konformität anvisieren.

2.5.3 Beschriftung im Namen (Stufe A) verlangt, dass, wenn ein Link oder Button eine sichtbare Textbeschriftung hat, der zugängliche Name mit diesem Text beginnt. Ein Icon-Button mit der Beschriftung “Mehr über Barrierefreiheit erfahren” und einem aria-label von “Hier klicken” verstößt gegen dieses Kriterium.

Häufige Fehler und was stattdessen zu tun ist

”Hier klicken” und “Mehr lesen”

Dies sind die weitverbreitetsten Barrierefreiheitsfehler bei Links im Web.

<!-- Fehler: keine Bedeutung außerhalb des Kontexts -->
<a href="/blog/wcag-compliance">Read more</a>

<!-- Erfüllt: selbsterklärend -->
<a href="/blog/wcag-compliance">Lesen Sie unseren Leitfaden zur WCAG-2.2-Konformität</a>

Die Lösung ist fast immer einfach: Ersetzen Sie die vage Formulierung durch Text, der das Ziel oder die Handlung beschreibt.

Generische “Hier”-Links

“Hier klicken, um den Bericht herunterzuladen” scheitert aus demselben Grund — das Linkwort selbst ist nur “hier”.

<!-- Fehler -->
<p>Für die vollständigen Ergebnisse klicken Sie <a href="/report.pdf">hier</a>.</p>

<!-- Erfüllt: der Linktext beschreibt, worauf verlinkt wird -->
<p>Laden Sie den <a href="/report.pdf">Barrierefreiheits-Auditbericht 2025 (PDF)</a> herunter.</p>

Beachten Sie den PDF-Hinweis in Klammern — dies ist gute Praxis, um Nutzer darüber zu informieren, dass das Folgen des Links ein PDF statt einer Webseite öffnet.

Links zum selben Ziel mit unterschiedlichem Text oder verschiedene Ziele mit demselben Text

Beides schafft Verwirrung. Wenn fünf Navigationslinks alle “Mehr erfahren” sagen, aber auf verschiedene Serviceseiten verweisen, können Nutzer nicht vorhersehen, wo sie landen. Umgekehrt sind zwei verschiedene Links, die “WCAG-Konformitätsleitfaden” sagen, aber auf unterschiedliche Seiten führen, ebenso verwirrend.

Nur-Icon-Links und -Buttons

Ein Link oder Button, der nur ein Symbol enthält — keinen sichtbaren Text —, muss einen zugänglichen Namen über aria-label oder aria-labelledby erhalten. Ohne ihn kündigen Screenreader den Dateinamen des Icon-Bildes oder gar nichts an.

<!-- Fehler: angesagt als "Link, Grafik" oder der SVG-Dateiname -->
<a href="/social/twitter">
  <svg><!-- Twitter-Symbol --></svg>
</a>

<!-- Erfüllt: aria-label liefert den zugänglichen Namen -->
<a href="/social/twitter" aria-label="QualiBooth auf Twitter">
  <svg aria-hidden="true"><!-- Twitter-Symbol --></svg>
</a>

Das aria-hidden="true" am SVG verhindert, dass Screenreader den SVG-Titel oder -Inhalt ansagen — da der Link selbst bereits eine Beschriftung hat, ist der Icon-Inhalt redundant.

aria-label zur Ergänzung von sichtbarem Text verwenden

Wenn eine Seite mehrere “Herunterladen”-Links hat und Sie den sichtbaren Text nicht ändern können (eine gestalterische Einschränkung), kann aria-label den zugänglichen Namen erweitern:

<!-- Der sichtbare Text ist "Herunterladen", aber der zugängliche Name ist die vollständige Zeichenkette -->
<a href="/report-2025.pdf" aria-label="Barrierefreiheitsbericht 2025 als PDF herunterladen">
  Herunterladen
</a>

Ein Hinweis dazu: WCAG 2.5.3 verlangt, dass der zugängliche Name mit dem sichtbaren Text beginnt. “Herunterladen Barrierefreiheitsbericht 2025 PDF” beginnt mit “Herunterladen” — gut. “Barrierefreiheitsbericht 2025 — PDF herunterladen” tut das nicht — schlecht.

Links, die in einem neuen Tab öffnen

Einen neuen Tab ohne Warnung zu öffnen, verwirrt Nutzer, besonders jene mit kognitiven Behinderungen oder Screenreader-Nutzer, die möglicherweise nicht bemerken, was geschehen ist. Weisen Sie auf das Neuer-Tab-Verhalten im Linktext oder mit einem visuell verborgenen Hinweis hin.

<!-- Signalisiert das Neuer-Tab-Verhalten visuell und für assistive Technologie -->
<a href="https://example.com" target="_blank">
  Beispielbericht ansehen
  <span class="sr-only">(öffnet in neuem Tab)</span>
</a>

Wenn Linktext funktioniert, ohne offensichtlich zu sein

Der Kontext kann unter WCAG 2.4.4 legitim die fehlende Bedeutung liefern. Ein “Herunterladen”-Link ist akzeptabel, wenn er in einer Tabellenzelle steht, deren Spaltenüberschrift “Jahresbericht” und deren Zeilenüberschrift “2025” lautet. Der Kontext macht den Zweck klar.

Das unterscheidet sich von einem “Mehr lesen”-Link am Ende eines eigenständigen Absatzes. Der Absatz liefert Kontext, doch “Mehr lesen” scheitert dennoch, weil der Linktext auf jeden beliebigen Absatz zutreffen könnte — er identifiziert das Ziel nicht eindeutig.

Bildlinks

Wenn der Linkinhalt ein Bild statt Text ist, wird das alt-Attribut des Bildes zum zugänglichen Namen des Links. Der Alternativtext sollte das Ziel des Links beschreiben, nicht das Bild selbst.

<!-- Der Alt-Text beschreibt das Linkziel, nicht das Aussehen des Bildes -->
<a href="/services/audits">
  <img src="audit-icon.png" alt="Dienstleistungen zur Barrierefreiheits-Prüfung">
</a>

Wenn das Bild rein dekorativ ist und von sichtbarem Text im selben Link begleitet wird, sollte das Bild alt="" haben, um zu vermeiden, dass derselbe Text zweimal angesagt wird.

Ein schnelles Audit, das Sie selbst durchführen können

Öffnen Sie Ihre Seite und rufen Sie die Liste der Links mit Ihrem Screenreader auf (oder installieren Sie die kostenlose Browser-Erweiterung HeadingsMap oder WAVE, um die aus dem Kontext extrahierten Links zu sehen). Lesen Sie die Liste durch. Wenn Sie nicht allein aus dem Text erkennen können, wohin jeder Link führt, muss er überarbeitet werden.

Die häufigste Lösung ist das Hinzufügen eines <span class="sr-only"> (visuell verborgen, für Screenreader zugänglich) mit zusätzlichem Kontext oder schlicht das vollständige Umschreiben des Linktexts. Umschreiben ist stets vorzuziehen — es verbessert oft die Nutzbarkeit für alle, nicht nur für Screenreader-Nutzer.

Für eine gründliche Überprüfung der Links Ihrer Website und weiterer WCAG-Kriterien decken unsere manuellen Barrierefreiheits-Audits den Linkzweck als Teil einer umfassenderen Prüfung durch Tester ab, die täglich assistive Technologie nutzen.