WCAG 2.4.9: Zweck des Links (nur Link)

Was diese Regel bedeutet

\n

WCAG 2.4.9 — Link Purpose (Link Only) ist ein Erfolgskriterium der Stufe AAA unter WCAG 2.1 und 2.2. Es verlangt, dass der Zweck jedes Links allein aus dem Linktext bestimmt werden kann. Anders als das entsprechende Kriterium der Stufe AA, WCAG 2.4.4 (Link Purpose — In Context), das erlaubt, den Linkzweck aus dem umgebenden Kontext wie einer Überschrift, einem Absatz oder einer Tabellenzelle abzuleiten, ist 2.4.9 deutlich strenger: Der Linktext selbst muss vollständig selbsterklärend sein, ohne jegliche Abhängigkeit vom umgebenden Inhalt.

\n

Das Kriterium gilt für alle Hyperlinks, die mit dem <a>-Element erstellt werden, sowie für jedes interaktive Element, das einen Accessible Name trägt und sich wie ein Link verhält. Dazu gehören Bildlinks (bei denen das alt-Attribut des Bildes oder ein aria-label den Accessible Name bereitstellt), als Buttons gestaltete Links und SVG-basierte Links. Der Accessible Name des Links — berechnet aus seinem sichtbaren Text, aria-label, aria-labelledby oder dem Alternativtext des Bildes — muss für sich allein vermitteln, wohin der Link führt oder was er bewirkt.

\n

Was als bestanden gilt: Ein Link erfüllt 2.4.9, wenn eine Person, die nur den Linktext liest — und sonst nichts auf der Seite — den Zielort oder die Funktion des Links sicher verstehen kann. Ein Link mit der Beschriftung „Download the 2024 Annual Accessibility Report (PDF, 2.4 MB)“ besteht beispielsweise, weil alle relevanten Informationen im Linktext selbst enthalten sind. Ein Link mit der Beschriftung „Read the full article: How to Write Accessible Link Text“ besteht ebenfalls. Ein Bildlink mit alt='View pricing plans' besteht, weil der Alt-Text vollständig beschreibend ist.

\n

Was als nicht bestanden gilt: Links mit Text wie „click here“, „read more“, „learn more“, „this“, „here“ oder jeder anderen Formulierung, die nur im Kontext eine Bedeutung hat, erfüllen dieses Kriterium nicht. Ebenso fällt ein Link durch, der ein Bild umschließt, dessen alt-Attribut leer ist oder fehlt, sodass der Link keinen Accessible Name hat. Links, die aria-label oder aria-labelledby verwenden, deren berechneter Accessible Name aber dennoch vage ist, fallen ebenfalls durch.

\n

Offizielle Ausnahmen: WCAG nennt ausdrücklich eine Ausnahme — wenn der Zweck des Links für alle Nutzerinnen und Nutzer absichtlich mehrdeutig ist, nicht nur für Menschen mit Behinderungen. Ein Beispiel wäre ein Teaser-Link in einem Mystery-Spiel mit der Beschriftung „Proceed“ (bei dem die Mehrdeutigkeit Teil des beabsichtigten Designs ist); dieser würde nicht als Fehler gewertet, sofern die Mehrdeutigkeit universell gilt. Diese Ausnahme ist eng gefasst und sollte nicht als Schlupfloch für schlechte Linktext-Praktiken genutzt werden.

\n\n

Warum das wichtig ist

\n

Aussagekräftiger Linktext gehört zu den wirkungsvollsten Barrierefreiheitsverbesserungen, die eine Website vornehmen kann. Die Gruppen, die am stärksten von vagem Linktext betroffen sind, sind Screenreader-Nutzende, Personen, die per Tastatur navigieren, Menschen mit kognitiven Beeinträchtigungen und Nutzende von Sprachsteuerungssoftware.

\n

Screenreader-Nutzende — typischerweise Menschen, die blind sind oder eine starke Sehbeeinträchtigung haben — navigieren häufig auf einer Seite, indem sie sich eine Liste aller Links anzeigen lassen. Beliebte Screenreader wie NVDA, JAWS und VoiceOver bieten diese Funktion, die den Accessible Name jedes Links extrahiert und als eigenständige Liste darstellt. Wenn Links „click here“, „read more“ oder „details“ lauten, wird diese Liste zu einer Reihe identischer, bedeutungsloser Einträge. Die Person hat keine Möglichkeit zu erkennen, welchen Link sie aktivieren soll, ohne für jeden Link den umgebenden Inhalt zu lesen — eine langsame, frustrierende und oft unmögliche Aufgabe, insbesondere auf Seiten mit Dutzenden von Links.

\n

Laut der Weltgesundheitsorganisation haben weltweit etwa 2.2 Milliarden Menschen eine Form von Sehbeeinträchtigung, von denen mindestens 1 Milliarde eine Erkrankung hat, die hätte verhindert werden können oder noch nicht behandelt wurde. Selbst bei Nutzenden ohne Sehbehinderung profitieren motorisch beeinträchtigte Personen, die auf Schaltersteuerung oder Sprachnavigation (mit Tools wie Dragon NaturallySpeaking) angewiesen sind, enorm von beschreibendem Linktext, weil sie einen Link direkt durch Aussprechen oder Auswählen seines Namens aktivieren können. Auch Gruppen mit kognitiven Beeinträchtigungen — darunter Menschen mit Aufmerksamkeitsdefiziten, Gedächtnisproblemen oder Leseschwierigkeiten — profitieren, weil klare Linkbeschriftungen die kognitive Belastung und den Bedarf, den Kontext erneut zu lesen, verringern.

\n

Betrachten wir ein Szenario aus der Praxis: eine türkische Staatsbürgerin oder ein türkischer Staatsbürger besucht die Website eines öffentlichen Krankenhauses, um einen Termin zu buchen. Die Seite hat drei Service-Buttons, die jeweils die Phrase „Randevu Al“ (Termin buchen) enthalten, ohne weiteren Kontext im Linktext. Eine blinde Person, die die Linkliste ihres Screenreaders öffnet, sieht „Randevu Al“, „Randevu Al“ und „Randevu Al“ — drei ununterscheidbare Optionen. Sie kann nicht erkennen, welcher Link für Kardiologie, welcher für Allgemeinmedizin und welcher für Radiologie ist, ohne zum Kontext zurück zu navigieren. Um WCAG 2.4.9 zu erfüllen, müsste jeder Link „Randevu Al — Kardiyoloji“, „Randevu Al — Genel Pratisyen“ und „Randevu Al — Radyoloji“ lauten, sodass der Zweck allein aus dem Linktext eindeutig hervorgeht.

\n

Über die Barrierefreiheit hinaus hat beschreibender Linktext einen erheblichen SEO-Nutzen. Suchmaschinen-Crawler gewichten den Ankertext beim Indexieren von Seiten, und beschreibende Links verbessern die Relevanzsignale sowohl für die Quellseite als auch für die Zielseite. Das Ersetzen generischer Ankertexte durch aussagekräftige Formulierungen verbessert die Auffindbarkeit und senkt Absprungraten — zum Vorteil aller Nutzenden.

\n\n

Verwandte Axe-core-Regeln

\n

WCAG 2.4.9 erfordert manuelle Tests, weil automatisierte Tools keine Bedeutung oder Absicht erkennen können — sie können das Fehlen eines Accessible Name markieren, aber nicht beurteilen, ob ein vorhandener Accessible Name ausreichend beschreibend ist.

\n

\n
• Manuelle Tests erforderlich — link-name (axe-Regel): Die axe-core-Regel link-name erkennt Links, die überhaupt keinen Accessible Name haben (zum Beispiel ein <a>-Element ohne Textinhalt, ohne aria-label, ohne aria-labelledby und ohne Bild mit nicht leerem alt-Attribut). Während diese Regel vollständig leere Links erfasst, kann sie nicht bewerten, ob ein vorhandener Accessible Name sinnvoll ist. Ein Link mit der Beschriftung „here“ besteht die automatisierte link-name-Regel, weil er technisch einen Accessible Name hat — fällt aber bei WCAG 2.4.9 durch, weil dieser Name nicht selbsterklärend ist. Genau deshalb ist 2.4.9 als Kriterium gekennzeichnet, das eine manuelle Prüfung erfordert: Eine Person muss jede Linkbeschriftung lesen und beurteilen, ob sie den Zweck isoliert vermittelt.
\n
• Manuelle Tests erforderlich — identical-links-same-purpose: Axe-core enthält eine Regel, die Gruppen von Links mit identischen Accessible Names, aber unterschiedlichen Zielorten markiert. Dies ist ein Heuristik-Ansatz, der potenzielle Verstöße gegen 2.4.9 sichtbar macht — etwa mehrere „Read More“-Links, die auf unterschiedliche Artikel verweisen. Auch diese Regel erfordert jedoch eine Bestätigung durch eine Person, da identische Namen, die auf dasselbe Ziel verweisen, keinen Verstoß darstellen. Die Regel liefert Kandidaten zur Überprüfung, aber keine endgültigen Fehler.
\n
• Warum Automatisierung nicht ausreicht: Zur Beurteilung des Linkzwecks ist Sprachverständnis erforderlich. Ein automatisiertes Tool kann berechnen, dass der Accessible Name eines Links die Zeichenkette „details“ ist, kann aber nicht erkennen, dass diese Zeichenkette ein Ziel nicht ausreichend beschreibt. Ebenso kann ein Tool nicht beurteilen, ob „View“ ausreicht (vielleicht in einer sehr spezifischen, eng gefassten Oberfläche) oder ob „View the Q3 Financial Statement“ besser ist. Menschliches Urteil, idealerweise kombiniert mit Screenreader-Tests, ist die einzige verlässliche Methode.
\n

\n\n

Wie man testet

\n

\n
1. Automatisierter Scan als Basis: Führen Sie axe DevTools (Browser-Erweiterung) oder Lighthouse auf der Zielseite aus. Suchen Sie in axe DevTools nach Verstößen gegen die Regel link-name — diese stehen für Links ohne jeglichen Accessible Name und sind garantiert Verstöße gegen 2.4.9. Exportieren Sie die Ergebnisse und notieren Sie alle markierten Links. Dieser Schritt schließt Ihr 2.4.9-Audit nicht ab; er identifiziert nur die naheliegendsten Fehler.
\n
2. Erstellen einer Linkliste mit einem Screenreader: Öffnen Sie die Seite in Firefox mit installiertem NVDA. Drücken Sie Einfügen + F7 (NVDA-Kurzbefehl für die Elementeliste) und wählen Sie im Dialog „Links“. Überprüfen Sie die vollständige Liste der Linkbeschriftungen. Fragen Sie sich: Könnte eine Person, die nur diese Liste liest, den Zielort oder die Funktion jedes Links verstehen? Wiederholen Sie diesen Test in JAWS, indem Sie Einfügen + F7 drücken, um den Links-Listen-Dialog zu öffnen, und in VoiceOver unter Safari (macOS), indem Sie VO + U drücken, um den Rotor zu öffnen und zu „Links“ zu navigieren. Markieren Sie jeden Link, dessen Beschriftung mehrdeutig ist, mit unterschiedlichem Ziel dupliziert vorkommt oder ausschließlich aus einer URL-Zeichenkette besteht.
\n
3. Tastatur-Tab-Audit: Navigieren Sie auf der Seite ausschließlich mit der Tab-Taste. Jedes Mal, wenn der Fokus auf einem Link landet, lesen Sie nur den sichtbaren Text des fokussierten Elements (oder hören Sie die Screenreader-Ausgabe). Entscheiden Sie, ohne den umgebenden Inhalt anzusehen, ob der Zweck des Links klar ist. Dokumentieren Sie jeden Link, bei dem der Zweck nicht allein aus dem Linktext hervorgeht.
\n
4. Prüfung von Bildlinks: Identifizieren Sie alle Links, die nur ein Bild enthalten (keinen sichtbaren Text). Untersuchen Sie jeden mit den Entwicklertools des Browsers, um zu überprüfen, ob das Bild ein nicht leeres, beschreibendes alt-Attribut hat oder der Link ein beschreibendes aria-label besitzt. Die Berechnung des Accessible Name sollte zu einer aussagekräftigen Formulierung führen.
\n
5. Prüfung doppelter Linktexte: Suchen Sie im HTML der Seite nach mehreren Vorkommen desselben Linktexts (zum Beispiel mehrere „Read More“- oder „Buy Now“-Anker). Überprüfen Sie, ob diese Links auf dasselbe Ziel verweisen (zulässig) oder auf unterschiedliche Ziele (ein Verstoß gegen 2.4.9, sofern nicht über aria-label oder aria-labelledby differenziert).
\n
6. Test mit Sprachsteuerung: Versuchen Sie mit Dragon NaturallySpeaking oder Windows Voice Access, Links zu aktivieren, indem Sie ihre sichtbare Beschriftung aussprechen. Wenn die gesprochene Beschriftung mehrdeutig ist und mehrere Kandidaten erscheinen (zum Beispiel hebt „Click Read More“ mehrere Links hervor), bestätigt dies einen realen Usability-Fehler im Sinne von 2.4.9.
\n

\n\n

Wie man es behebt

\n

Generischer „Read More“-Linktext — Falsch

\n

<!-- Fails 2.4.9: link purpose cannot be determined from link text alone -->\n<article>\n  <h3>How to Improve Your Website's Accessibility Score</h3>\n  <p>Accessibility improvements can dramatically increase your user base...</p>\n  <a href='/blog/improve-accessibility-score'>Read more</a>\n</article>

\n

Generischer „Read More“-Linktext — Richtig

\n

<!-- Passes 2.4.9: link purpose is fully clear from link text alone -->\n<article>\n  <h3>How to Improve Your Website's Accessibility Score</h3>\n  <p>Accessibility improvements can dramatically increase your user base...</p>\n  <a href='/blog/improve-accessibility-score'>\n    Read more about improving your website's accessibility score\n  </a>\n</article>\n\n<!-- Alternative: visually show short text but provide full accessible name -->\n<a href='/blog/improve-accessibility-score'\n   aria-label='Read more about improving your website's accessibility score'>\n  Read more\n</a>

\n\n

Nur-Bild-Link mit fehlendem Alt-Text — Falsch

\n

<!-- Fails 2.4.9: image link has no accessible name; screen readers announce URL or nothing -->\n<a href='https://accsible.com/pricing'>\n  <img src='/icons/pricing.svg' alt=''>\n</a>

\n

Nur-Bild-Link mit fehlendem Alt-Text — Richtig

\n

<!-- Passes 2.4.9: alt text gives the link a fully descriptive accessible name -->\n<a href='https://accsible.com/pricing'>\n  <img src='/icons/pricing.svg' alt='View Accsible pricing plans'>\n</a>\n\n<!-- Alternative using aria-label on the anchor -->\n<a href='https://accsible.com/pricing' aria-label='View Accsible pricing plans'>\n  <img src='/icons/pricing.svg' alt=''>\n  <!-- alt='' hides decorative image from AT; aria-label on <a> provides the name -->\n</a>

\n\n

Mehrere identische „Satın Al“ (Buy Now)-Links — Falsch

\n

<!-- Fails 2.4.9: three identical link labels pointing to different products -->\n<div class='product-card'>\n  <h3>Temel Plan</h3>\n  <a href='/plans/basic'>Satın Al</a>\n</div>\n<div class='product-card'>\n  <h3>Profesyonel Plan</h3>\n  <a href='/plans/pro'>Satın Al</a>\n</div>\n<div class='product-card'>\n  <h3>Kurumsal Plan</h3>\n  <a href='/plans/enterprise'>Satın Al</a>\n</div>

\n

Mehrere identische „Satın Al“ (Buy Now)-Links — Richtig

\n

<!-- Passes 2.4.9: each link has a unique, descriptive accessible name via aria-label -->\n<div class='product-card'>\n  <h3>Temel Plan</h3>\n  <a href='/plans/basic' aria-label='Temel Planı Satın Al'>Satın Al</a>\n</div>\n<div class='product-card'>\n  <h3>Profesyonel Plan</h3>\n  <a href='/plans/pro' aria-label='Profesyonel Planı Satın Al'>Satın Al</a>\n</div>\n<div class='product-card'>\n  <h3>Kurumsal Plan</h3>\n  <a href='/plans/enterprise' aria-label='Kurumsal Planı Satın Al'>Satın Al</a>\n</div>\n\n<!-- Alternative: use visually hidden text inside the anchor -->\n<a href='/plans/basic'>\n  Satın Al <span class='sr-only'>— Temel Plan</span>\n</a>

(Inhalt aufgrund des Tokenlimits gekürzt — bitte diesen Artikel erneut versuchen.)