- Betont die Probleme bei der Verwendung allgemeiner Linktexte wie „Hier klicken“
- Im Sinne einer besseren Barrierefreiheit sollten Linktexte die Bedeutung des Inhalts klar vermitteln
- Negative Auswirkungen auf Suchmaschinen und die Nutzererfahrung von Screenreader-Nutzern
- Klare, kontextbezogene Linkformulierungen bieten Vorteile für Nutzer und Technik gleichermaßen
- Seit 2001 gibt es auf Ebene von Webstandards und UX-Prinzipien Bestrebungen, korrekte Linktexte zu empfehlen
Einleitung
- Die Verwendung allgemeiner Linktexte wie „Hier klicken“ oder „click here“ ist seit langem eine verbreitete Praxis unter Webentwicklern
- Diese Vorgehensweise bringt jedoch erhebliche Nachteile in Bezug auf Barrierefreiheit, Usability und SEO mit sich
Bedeutung von Linktexten und Problempunkte
- Linktexte sollten Informationen liefern, damit Nutzer vor dem Klicken vorhersagen können, wohin der Link führt
- Wird lediglich „Hier klicken“ verwendet, existiert der Link ohne Kontext, was zu Verwirrung bei Nutzern und eingeschränkter Barrierefreiheit führt
Auswirkungen auf Barrierefreiheit und Nutzererfahrung
- Wenn Screenreader-Nutzer eine Linkliste auf einer Seite durchgehen, hören sie immer wieder denselben Inhalt „Hier klicken“, wodurch die Informationsaufnahme erschwert wird
- Sind Links mit konkreten Formulierungen, die Bedeutung transportieren, versehen, steigt die Effizienz der Nutzungserfahrung sowohl für sehbehinderte Menschen als auch für Nutzer in verschiedensten Situationen
Aspekte der Suchmaschinenoptimierung (SEO)
- Auch Suchmaschinen analysieren Linktexte, um Relevanz und Qualität von Inhalten zu bewerten
- Linktexte mit wichtigen Keywords und Kontext wirken sich positiv auf Suchranking und Sichtbarkeit aus
Empfehlungen für gute Linktexte
- Empfohlen wird die Verwendung von Linktexten, die den Kontext klar widerspiegeln
- Beispiel: „Aktuelle Richtlinien zur Barrierefreiheit ansehen“
- Dieses Prinzip wird seit 2001 im Zuge der Entwicklung von Webstandards und einer stärkeren UX-Orientierung kontinuierlich betont
Fazit
- Statt „Hier klicken“ sollten aussagekräftige Texte als Link verwendet werden; das ist ein wesentlicher Standard für das heutige und zukünftige Web
1 Kommentare
Kommentare auf Hacker News
Aus Sicht der Barrierefreiheit lesen Screenreader für sehbehinderte Menschen eine Seite linear vor.
Um sich vom linearen Lesen zu lösen, bieten sie oft die Möglichkeit, Listen von Elementen wie Überschriften oder Links separat zu durchsuchen, ohne den Kontext ihrer ursprünglichen Position.
Wenn alle Links „click here“ heißen, nimmt man diesen Nutzern faktisch den nichtlinearen Zugriff.
Daher wirken „get Amaya“ oder „go to the Amaya website“ durchaus in Ordnung.
Außerdem ist es keine gute Praxis, wenn ein Download-Button auf github.io eine ausführbare Datei von einer Seite wie SourceForge holt, die als Malware-Site wahrgenommen wird. wxMaxima kommt mir da in den Sinn.
Das heißt nicht, dass man die Tools ändern sollte, aber es sollte eine Möglichkeit geben, Leuten, die sich nicht selbst in die Funktionsweise von Screenreadern einarbeiten werden, diese visuell zu veranschaulichen.
Ich weiß allerdings nicht, wie gut die erste in Screenreadern unterstützt wird.
Bearbeitung: Links von WCAG 2.0 auf 2.2 aktualisiert.
Trotzdem würde ich, statt wie im Beispiel des Artikels nur „Amaya“ stehen zu lassen, eher mehr Handlung einbauen, etwa „Get Amaya“.
Nutzer können sich zum Beispiel von Landmark zu Landmark, von Überschrift zu Überschrift oder in einem Gliederungsnavigationsmodus durch beides bewegen.
Der entscheidende Punkt ist, dass Screenreader-Navigation nicht dasselbe ist wie Tastaturnavigation.
Ich stimme überhaupt nicht zu. Das von ihnen als schlechtes Beispiel angeführte „To download W3C's editor/browser Amaya, click here.“ ist sehr klar.
Wenn man den Link anklickt, wird es entweder direkt heruntergeladen oder man gelangt zur Download-Seite.
Umgekehrt sieht „Get Amaya!“ eher wie ein Link zur Amaya-Website aus und nicht wie einer zur Download-Seite; für Downloads ist das also nicht effektiv.
„Tell me more about Amaya: W3C's free editor/browser that lets you create HTML, SVG, and MathML documents.“ ist auch nicht besonders gut. Das ist kein Satz über einen Download, und „tell me more“ ist zwar eine Aufforderung, aber ausgerechnet nicht der Link.
Die konventionelle Nutzung im Web, also „To download W3C's editor/browser Amaya, click here.“ oder „Download Amaya, the W3C's editor/browser.“, ist völlig in Ordnung.
Die Vorstellung, ein Link dürfe kein Verb sein, wirkt ziemlich seltsam. Wenn er eine Handlung wie Download oder Mehr erfahren enthält, kann ein Link selbstverständlich ein Verb sein.
Das ist etwas anderes als etwa Referenzlinks in Wikipedia, bei denen man mehr über ein Thema erfährt.
„click here“ macht sehr deutlich, dass der Link kein bloßer Verweis ist, sondern ein Aktionslink. Bei „Get Amaya!“ fühlt es sich nicht so an, als würde einem gesagt, wie man Amaya bekommt, sondern eher so, als sei „Amaya“ ein Referenzlink und kein Download-Link.
Selbst wenn man eine Suchmaschine baut: Welche Information soll „click here“ dem Index liefern?
Ich stimme nicht zu, dass das Verb an sich das große Problem ist, aber wenn das Verb „click“ und das Objekt „here“ ist, ist es etwas anderes.
Einen Linktext „Click Here to download Amaya“ kann ich ertragen, aber wenn der Link buchstäblich nur aus den zwei Wörtern „click here“ besteht, lässt er sich in vielen Kontexten nicht von anderen Links unterscheiden.
„Download Amaya“ kann ein hervorragender Link sein. Nur „Amaya“ oder nur „click here“ ist nicht gut, außer es geht auf eine Amaya-Informationsseite.
Letztlich ist das „click here“-Problem, wie andere Kommentare sagen, ein Accessibility-Problem; die Botschaft wirkt ziemlich verwässert, weil es damit vermischt wird, ob der Linktext das Ziel korrekt widerspiegelt.
aria-describedbykann helfen, aber wenn man den Text im Link selbst besser macht, kann man diese Notwendigkeit vermeiden.Beim Thema Verben stimme ich zu.
Auch der britische Government Digital Service gibt in seinen Accessibility-Guidelines eine ähnliche Empfehlung: https://design.homeoffice.gov.uk/accessibility/links
Sie sind nicht unbedingt die hübschesten, aber bei Dingen wie den dicken schwarz-gelben Rahmen von Formular-Komponenten gilt: Barrierefreiheit hat Vorrang vor Design.
Das W3C sagt „Get Amaya“, „Read more about Amaya“, während das Home Office „Get Amaya“, „Read more about Amaya“ sagt.
Letzteres wirkt deutlich sinnvoller, verursacht aber andere Probleme, wenn man es im Kontext verwendet.
Persönlich denke ich, dass beide zwei unterschiedliche Use Cases miteinander verwechseln. Links werden oft inline in Sätzen verwendet; die Fälle, die W3C und Home Office behandeln, wären eher als Buttons außerhalb eines Satzes besser aufgehoben, etwa
[Download],[Documentation].Beim Use Case von Hyperlinks innerhalb von Fließtext wirken jedoch beide Varianten holprig.
Wie sollte man zum Beispiel „PiPedal is a guitar effects pedal that runs on Raspberry Pi. To download PiPedal, click here. To read the documentation, click here.“ verbessern?
Ich verstehe die Einwände, aber eine Änderung wie „PiPedal is a guitar effects pedal that runs on Raspberry Pi. Get Pipedal. Read the documentation.“ kann ich schwer akzeptieren. Das entspricht nicht englischem Sprachgebrauch.
In der tatsächlichen Dokumentation habe ich es als „To download PiPedal, visit the Download Page. To learn more about Pipedal, view the Documentation.“ formuliert, aber meiner Erfahrung nach ist es oft sehr schwierig, „click here“ zu nominalisieren.
Noch mehr gilt das bei Sätzen wie „Ubuntu Server installs don't suffer from this problem; but before choosing an Ubuntu Server install, you should read the Ubuntu Server section of the "Installing on Ubuntu" page.“
Dann fragt man sich, was genau daran falsch sein soll, „here“ als Pronomen für das Bezugsziel zu verwenden.
In diesem Use Case steht der Link in einem Satz, der den gesamten nötigen Kontext liefert, daher gibt es möglicherweise gar kein echtes Accessibility-Problem.
Auch das erste Beispiel ist ein Lead-Satz auf einer Webseite, bei dem Kürze wichtig ist.
Ist „To download PiPedal, click here.“ wirklich ein Accessibility-Problem? Erst recht, wenn direkt darüber die Buttons
[ Download ] [ Documentation ]stehen.Die wirklich wichtige Kennzahl ist hier, wie viele Leute die Download-Seite besuchen.
Aus dieser Perspektive bin ich ziemlich skeptisch, ob „To download PiPedal, visit the Download Page.“ wirklich besser ist.
Persönlich finde ich das zweite Beispiel, von dem sie abraten, besser: „To download Amaya, go to the Amaya_Website and get the necessary software.“
Bei einem Link, der nur „Amaya“ heißt, weiß man nicht, ob es ein interner oder externer Link ist, und selbst wenn aus dem Kontext klar ist, dass man Amaya herunterladen will, ist schwer zu erkennen, ob er direkt zu einer Datei oder zu einer Download-Seite führt.
Vielleicht liegt es am Alter, aber ich habe Links immer instinktiv so verstanden, dass sie auf Substantive verweisen.
Ein Link zeigt auf einen Ort, und dieser Ort hat einen Namen, kein Verb oder Adjektiv.
Deshalb ist ein Link zu „meiner Website“ in Ordnung, aber ein Link wie „zu meiner Website gehen“ fühlt sich für mich grundsätzlich falsch an.
Ich mag auch den Imperativton sehr ungern und würde Sätze wie „go to my website“ oder „follow this link“ nie schreiben.
Allerdings wird es mehrdeutig, wenn ein Link eine Aktion wie einen Download startet. Aber wenn man das als Substantiv „Download“ oder „Downloader“ auffasst, ist es immer noch ein Substantiv.
Das ist vermutlich eine Internet-Debatte, die ich bis zum Ende ausfechten werde.
Call-to-Action-Texte sind ein eigenes Thema, aber Seiten, die nur das Wort „here“ verlinken, sind ein klares Versagen von Autorinnen und Autoren, die das Hypertext-Medium nicht verstanden haben.
„click here“ wirkt wie eine versehentlich stehen gelassene Regieanweisung.
Die meisten Autorinnen und Autoren schreiben beim Verfassen nicht im Hypertext-Kontext, sondern machen Regieanweisungen statt Link-Syntax wie in Markdown zum Standard.
Mir fällt ein Beitrag über einen Link mit der Beschriftung „I forgot my password“ ein.
Ich dachte, ob es besser wäre, „click here if ...“ zu schreiben, wusste aber intuitiv, dass auch das nicht richtig ist.
Nutzlose Elemente auf einer Webseite zu ignorieren, ist für manche Menschen eine Fähigkeit, die sie nicht haben, und ich weiß nicht, wie man sie ihnen beibringen soll.
Daran denke ich jedes Mal, wenn ich jemandem ohne Hintergrundwissen bei der Webnutzung helfe. Manche Nutzer denken selbst dann noch sorgfältig über den buchstäblich ersten Eintrag auf der Seite nach, wenn dort „Please enable notifications“ steht, bevor sie überhaupt den zweiten Eintrag sehen.
Umso mehr, weil auch die Google-Suche inzwischen vor den eigentlichen Ergebnissen mehrere Bildschirmseiten voller Müll anzeigt.
Ein damit zusammenhängendes Problem ist, dass manche den erkenntnistheoretischen Status von Texten auf einer Seite nicht nach Arten unterscheiden können.
So gibt es etwa Nutzer, die einen anklickbaren Link „I forgot my password“ sehen und glauben, das sei nicht die Stelle, auf die man klickt, wenn man sein Passwort vergessen hat, sondern ein Satz, der mitteilt, dass sie ihr Passwort vergessen haben.
Natürlich hat der Tod der UI-Standardisierung dieses Problem deutlich verschärft.
https://mstdn.io/@mattskala/113188291223682980
Ich erinnere mich an die Zeit, als Microsoft viele Buttons aus der UI entfernte und durch vage eingefärbte Textlinks ersetzte. Danach wurde es viel schwieriger herauszufinden, worauf man klicken sollte.
Nutzer passen sich intuitiv an Maschinen an, und Entwickler passen sich an Nutzer an; so entsteht eine Rückkopplungsschleife.
Anders gesagt: Weil es auf zahllosen Websites und in Apps Links mit „I forgot my password“ gab, hat sich sehr wahrscheinlich auch die Bedeutung der Sprache verändert.
Zumindest in diesem Kontext werden sich die meisten Menschen so anpassen, dass sie die Absicht verstehen.
Jüngere Generationen, die keine andere Art kennen, halten das womöglich nicht einmal für beachtenswert.
Deshalb hat es auch einen Wert, Konventionen beizubehalten, selbst wenn sie isoliert betrachtet keinen Sinn ergeben.
Wenn alle Beispiele konsistent davon ausgehen, dass tatsächlich „Amaya“ heruntergeladen wird, wäre einfach der Hyperlink Download Amaya besser.
Wenn möglich, wäre auch ein Download-Icon gut, das zeigt, dass es zu einer echten Datei führt.
Denn so erkennt man, dass es sich nicht um einen Link zu einer anderen Seite handelt, auf der der echte Download-Button zwischen vier Anzeigen versteckt ist.
Dragan Espenschied (despens) schrieb 2022 einen Beitrag darüber, wie sich Linktexte im Lauf der Zeit verändert haben: https://despens.systems/2022/06/button-pushes-you/
Er beschreibt den Wandel von Call-to-Action-Formulierungen hin zu Button-Texten, die den Nutzer beschreiben.
Sinngemäß: „Stattdessen müssen sie den Zustand des Nutzers neu konfigurieren. Der Nutzer muss die geschriebene Beschwörung akzeptieren und seine Haltung ändern, bevor er auf die folgenden Informationen zugreifen kann.“
„Get Amaya.“ und „Tell me more about Amaya.“ wirken nicht elegant.