BARRIEREFREIHEIT ≠ OVERLAY · 37
Barrierefreie Links: vor dem Anklicken wissen, wohin es geht
📅 10. November 2026 · ⏱ 6 Min. Lesezeit
Ein Link soll eine Entscheidung ermöglichen, statt zum Raten zu zwingen. Text, Kontext und Verhalten bestimmen, ob Menschen sich mit Screenreader, Tastatur, Sprachsteuerung oder Vergrößerung orientieren können.
01. Wenn alle Wege nur „hier“ heißen
Stellen Sie sich eine Dienstleistungsseite mit acht Links namens „Weitere Informationen“ vor. Wer die vollständige Seite sieht, ordnet jeden Link vielleicht seiner Karte zu. Wer dagegen eine Linkliste anhört, bekommt möglicherweise acht identische Namen. Die Person muss zum Inhalt zurückkehren, jeden Bereich suchen und dessen Beziehung zum Ziel rekonstruieren. Ein einfacher Schritt wird zu einer unnötigen Suche.
Das betrifft nicht nur blinde Menschen. Bei Vergrößerung ist möglicherweise lediglich ein Ausschnitt der Karte sichtbar; bei Tastaturbedienung muss jeder Haltepunkt bewertet werden. Beschreibende Links verringern den Aufwand schon vor der Aktivierung. Entscheidend ist, was Menschen anhand der tatsächlich verfügbaren Informationen erwarten können, nicht was Gestaltende aus der vollständigen Anordnung bereits wissen.
02. Beschreiben Sie den Zweck statt einer leeren Aufforderung
„Öffnungszeiten ansehen“ macht das Ziel deutlicher als „Hier klicken“. „Anmeldeleitfaden herunterladen“ erklärt mehr als „Herunterladen“. Ein Link muss trotzdem kein endloser Satz werden. Wählen Sie die Wörter, die die Ressource von anderen unterscheiden, und wiederholen Sie nicht den gesamten Absatz. Gute Kürze erhält die entscheidende Information.
Die Beschriftung muss zum Zielinhalt passen. Öffnet „Preise der Dienstleistung“ eine Werbestartseite ohne Preise, ist die Aufgabe nicht gelöst. Kontrollieren Sie Links nach Dokumentwechseln und Umstrukturierungen. Ein zuvor richtiger Name kann irreführend werden, obwohl die URL weiterhin funktioniert. Redaktionelle Genauigkeit gehört zur Barrierefreiheit und zur täglichen Pflege. Legen Sie fest, wer die Beschriftungen zusammen mit den verlinkten Ressourcen aktualisiert.
03. Gültiger Kontext und Verständnis ohne Kontext
WCAG 2.2 unterscheidet zwischen dem Linkzweck im Kontext und der strengeren Anforderung, ihn allein aus dem Namen zu verstehen. Erfolgskriterium 2.4.4 auf Stufe A erlaubt Linktext zusammen mit einem durch Software bestimmbaren Kontext. Ein zugehöriger Absatz, Listeneintrag oder eine Tabellenzelle kann relevante Informationen liefern.
„Weiterlesen“ ist deshalb nicht automatisch in jeder Situation ein Verstoß. Untersuchen Sie die tatsächliche Zuordnung statt ausschließlich die optische Nähe. Auch wenn der Kontext das Kriterium erfüllt, erleichtert ein genauer Name häufig Linklisten und schnelles Erkunden. Trennen Sie die Konformitätsbewertung von der Entscheidung für eine verständlichere Nutzung. Eine hilfreiche Empfehlung ist keine erfundene Pflicht, und eine hübsche Karte belegt noch keine programmatische Beziehung.
04. Sichtbarer und vorgelesener Name müssen zusammenpassen
Der zugängliche Name eines Links kann aus Text, einem Bild oder beispielsweise aria-label entstehen. Steht sichtbar „Kontakt“, lautet der zugängliche Name aber völlig anders, kann eine Person mit Sprachsteuerung den Link möglicherweise nicht durch Aussprechen der sichtbaren Wörter aktivieren. Kriterium 2.5.3 verlangt gegebenenfalls, dass der Name den Text der sichtbaren Beschriftung enthält.
Die erste Wahl ist meist, den sichtbaren Text für alle zu verbessern. Ergänzen Sie nicht pauschal lange versteckte Beschreibungen, ohne den resultierenden Namen zu prüfen. Auch das title-Attribut darf nicht der einzige Ort sein, an dem das Ziel erklärt wird: Der Zugriff unterscheidet sich je nach Gerät. Untersuchen Sie den berechneten Namen und hören Sie sich die Ausgabe innerhalb der tatsächlichen Oberfläche an.
05. Auch ein verlinktes Bild braucht einen Zweck
Ist ein Bild der einzige Inhalt eines Links, sollte seine Textalternative die Funktion des Links vermitteln. Bei einem Logo zur Startseite ist diese Navigation wichtig, nicht die Beschreibung jeder gezeichneten Kurve. Eine verlinkte Lupe sollte nicht nach einer Datei wie „symbol-final-2.svg“ benannt sein. Beschreiben Sie die angebotene Funktion aus Sicht der nutzenden Person.
Gehören Bild und Text zu demselben Link und erklärt der Text bereits den Zweck, kann ein dekoratives Bild eine leere Alternative erhalten. So werden Wiederholungen vermieden. Prüfen Sie außerdem Karten mit Bild, Titel und Schaltfläche zum selben Ziel. Mehrere aufeinanderfolgende Links erzeugen möglicherweise unnötige Haltepunkte. Suchen Sie eine konsistente Lösung ohne verschachtelte Links oder den Verlust nativer Semantik und Bedienung.
06. Links und Schaltflächen erfüllen verschiedene Aufgaben
Ein Link führt zu einer Ressource oder Position. Eine Schaltfläche löst eine Aktion aus, beispielsweise das Öffnen eines Bereichs oder das Absenden eines Formulars. Beide können ähnlich aussehen, erzeugen aber unterschiedliche Erwartungen. Verwenden Sie native Elemente passend zur Funktion. Ein Link ohne echtes Ziel ist keine Universallösung für alle Bedienelemente.
Ersetzen Sie diese Grundlage nicht durch ein div mit Klickereignis und improvisierter Rolle. Dann müssten Fokus, Tastaturaktivierung und weitere bereits vom nativen Element bereitgestellte Verhaltensweisen nachgebaut werden. Prüfen Sie, dass Links mit Eingabe funktionieren und Schaltflächen der erwarteten Bedienung folgen. Die Technik soll die Aufgabe unterstützen, statt Menschen bei jeder Komponente ein neues Verhalten entdecken zu lassen. Das gilt auch für optisch einheitliche Aktionsleisten.
07. Downloads und Kontextwechsel vorhersehbar machen
Führt ein Link zu einem Dokument, benennen Sie dessen Thema eindeutig. Format und gegebenenfalls Dateigröße helfen bei der Entscheidung, ob das Öffnen auf einem Telefon oder bei begrenzter Verbindung sinnvoll ist. „Anmeldeleitfaden, PDF“ vermittelt mehr als eine lange Adresse oder ein unerklärtes Symbol.
Öffnen Sie neue Tabs nicht aus Gewohnheit. Gibt es einen Grund dafür, unterstützt ein Hinweis die Orientierung. Diese gute Praxis ist von der Behauptung zu unterscheiden, jeder neue Tab verletze automatisch WCAG. Ein verständlicher Link macht außerdem die Zieldatei nicht barrierefrei. Ein unstrukturiertes PDF bleibt trotz perfekter Beschriftung problematisch. Prüfen Sie den gesamten Weg von der Auswahl bis zur tatsächlichen Nutzung der Ressource und ihrer Inhalte.
08. Erkennbarkeit, Fokus und ausreichend Platz
Links innerhalb eines Absatzes müssen ohne ausschließliche Abhängigkeit von Farbe erkennbar sein. Unterstreichungen sind häufig eine klare und beständige Lösung. Prüfen Sie Kontraste und verhindern Sie, dass Besuchs- oder Fokuszustände den Text unlesbar machen. Die Interaktion sollte bereits erkennbar sein, bevor ein Mauszeiger darüber bewegt wird.
Gehen Sie mit Tab und Umschalt+Tab durch die Links. Der Fokusindikator muss sichtbar sein; eine fokussierte Komponente darf durch selbst erstellte Inhalte nicht vollständig verdeckt werden. Diesen letzten Fall behandelt WCAG 2.2 in 2.4.11. Prüfen Sie zusätzlich Abstände und anwendbare Anforderungen an Zielgrößen einschließlich ihrer Ausnahmen. Eine vergrößerte Klickfläche darf keine Überlappung erzeugen, die versehentlich ein anderes Ziel aktiviert.
09. Prüfen Sie die Entscheidung vor dem Klick
Wählen Sie eine echte Aufgabe: Öffnungszeiten finden oder den Supportkontakt erreichen. Lesen Sie zunächst nur die Linknamen und notieren Sie das erwartete Ziel. Folgen Sie anschließend dem Weg und vergleichen Sie Erwartung und Ergebnis. Wiederholen Sie dies bei Bedarf mit Screenreader, Linkliste, Tastatur und Vergrößerung.
Automatische Werkzeuge erkennen bestimmte fehlende Namen oder Kontrastprobleme. Sie entscheiden aber nicht, ob „Weitere Informationen“ die richtige Ressource verspricht oder eine Übersetzung die Bedeutung erhält. Dokumentieren Sie Mehrdeutigkeiten mit Position, ausgegebenem Namen und erwartetem Ziel. Bewerten Sie nicht die gesamte Website anhand eines einzelnen Links. Menüs, Karten, Fußbereich und redaktionelle Inhalte stammen häufig aus unterschiedlichen Komponenten und benötigen jeweils eine eigene Prüfung.
10. An der Quelle korrigieren und Klarheit erhalten
Prüfen Sie in WordPress und Divi sowohl den Editorinhalt als auch das resultierende HTML und den zugänglichen Namen. Korrigieren Sie das gemeinsame Modul, wenn viele Karten denselben Fehler wiederholen. Übersetzen Sie Beschriftungen und kontrollieren Sie die Zielsprache. Eine lokalisierte Bezeichnung hilft wenig, wenn die Ressource überraschend in eine andere Sprache wechselt.
Ein Overlay kennt die redaktionelle Absicht jedes Links nicht selbstständig und garantiert nicht, dass ein allgemeiner Name die richtige Ressource beschreibt. Darstellungseinstellungen können ergänzen, diese Entscheidung aber nicht ersetzen. Nehmen Sie eine einfache Frage in die Freigabe auf: Kann die Person vor der Aktivierung informiert wählen? Barrierefreiheit verbessert sich, wenn Menschen ihr Ziel erkennen, den erwarteten Inhalt erreichen und anschließend selbstständig weitermachen können.