Ein Irrtum  

Die Frage ist schon sehr alt: Brauchen Links ein Tooltip beziehungsweise ein title-Attribut oder nicht? Es gibt erstaunlich viele Fragen von Kunden dazu. Die Antwort lautet eigentlich „nein“.

Die Frage nach dem Tooltip für Links taucht regelmäßig auf. Dabei geht es nicht nur um Webseiten, sondern auch um Word-Dokumente und PDF-Dateien. Warum besteht diese Frage eigentlich? Warum wird auch zwölf Jahre nach Veröffentlichung der WCAG 2.0 immer noch angenommen, Links brauchen Tooltips?

Eine einfache Antwort lautet, dass „früher“ – bevor es ARIA gab – ein Tooltip manchmal erforderlich war, um Links „sprechend“ zu machen. Auch heute gibt es Situationen, in denen ein Tooltip sinnvoll ist. Spätestens 2014 mit der Veröffentlichung von ARIA 1.0 gibt es zumindest im Web aber sinnvollere Alternativen.

Mindestanforderung für Linktexte

Die Mindestanforderungen der Barrierefreiheit (aktuell: WCAG 2.1 Stufe AA) besagen in Erfolgskriterium 2.4.4, das der Zweck eines Links durch den Linktext und seinen Kontext bestimmt werden können muss. So ist ein Konstrukt wie

<p>Essen gibt es in der Mensa. Den Speiseplan findet Ihr <a href="speiseplan.html">hier</a>.</p>

absolut in Ordnung. Der Kontext ist der Absatz beziehungsweise der Satz, und der Linkzweck kann dadurch bestimmt werden.

Es gibt andere Konstrukte, wo ein Link keinen solchen Kontext aufweist, zum Beispiel:

<h2>Verpflegung</h2>
<p>Essen gibt es in der Mensa. Zum Speiseplan:</p>
<p><a href="speiseplan.html">weiter</a></p>

Dieser Linktext besitzt keinen unmittelbaren Kontext, so dass Autoren einen Kontext herstellen müssen. Da es bei dieser Anforderung darum geht, dass Screenreadernutzer den Linkzweck bestimmen können müssen, sollte das aria-describedby-Attribut für den weiter-Link bevorzugt werden. Zulässig nach Erfolgskriterium 2.4.4 ist aber auch das title-Attribut:

<p><a title="Verpflegung" href="speiseplan.html">weiter</a></p>

Das ist aber nur dann sinnvoll, wenn der Link keinen Linkkontext besitzt. In diesem Beispiel werden Screenreader bei Fokus auf den Link normalerweise den Linktext gefolgt vom Text im title-Attribut ausgeben, also „Link: weiter Verpflegung“.

Weitergehende Anforderung

Es gibt ein zweites Kriterium in den WCAG 2.1 zum Linktext. In Erfolgskriterium 2.4.9 auf Konformitätsstufe AAA wird vorgegeben, dass der Linkzweck anhand des Linktextes selbst erkannt werden soll. Dann erfüllt ein Linktext wie „hier“ oder „weiter“ die Anforderung nicht, weil der Linkzweck nicht alleine vom Linktext abgeleitet werden kann.

Dieses Kriterium muss nicht zwingend (und kann oft nicht) erfüllt werden. Ein solcher Link könnte mit einem Tooltip versehen werden, aber damit wäre Erfolgskriterium 2.4.9 immer noch nicht erfüllt. Bei Erfolgskriterium 2.4.9 geht es um den sichtbaren Linktext. Im Übrigen geht es in diesem Erfolgskriterium auch nicht um Screenreadernutzer, sondern um Nutzer mit einer Leseschwäche. Um Erfolgskriterium 2.4.9 zu erfüllen muss der Linktext selbst „sprechend“ sein.

title-Attribute für Links sind zu vermeiden

Trotz anderer Behauptungen sind Tooltips keine gute Wahl, um den Linkzweck anzugeben. Nach Erfolgskriterium 2.4.4 sind Tooltips noch zulässig, um einen Linkkontext herzustellen, aber es geht dabei um eine Lösung zweiter Wahl.

Wenn die aktuelle HTML 5.2 Spezifikation herangezogen wird, wird deutlich, warum title-Attribute zu vermeiden sind:

Relying on the title attribute is currently discouraged as many user agents do not expose the attribute in an accessible manner as required by this specification (e.g., requiring a pointing device such as a mouse to cause a tooltip to appear, which excludes keyboard-only users and touch-only users, such as anyone with a modern phone or tablet).

Wenn title-Attribute eingesetzt werden, dann sollten sie ausschließlich Informationen aus dem visuellen Kontext wiederholen. Der Grund ist leicht erklärt: title-Attribute sind nicht barrierefrei, denn sie sind auf Touch-Screens oder per Tastatur allgemein nicht zugänglich. Sie dürfen deshalb keine neuen Informationen enthalten.

Die Ausnahme bricht die Regeln

Im Web dürfte es normalerweise keinen Grund für ein title-Attribut für Links geben, denn die Verknüpfung von sichtbarem Text mit einem Link sollte besser mit dem aria-describedby-Attribut vorgenommen werden, aber wie sieht es bei Dokumenten aus. Für Dokumente gelten die gleichen Mindestanforderungen der Barrierefreiheit aus den WCAG 2.1 wie für Webseiten, das heißt: Tooltips sind generell zu vermeiden. Um Erfolgskriterium 2.4.4 zu erfüllen, sind Tooltips aber zulässig.

Neben den WCAG 2.1 gibt es auch den Standard PDF/UA (DIN- ISO 14289), der in Abschnitt 7.18.5-2 besagt, dass alternative Beschreibungen im contents-Schlüssel für Link-Annotationen erforderlich sind. Mit anderen Worten bedeutet das, dass Links einen Tooltip benötigen. Diese Anforderung weicht von der WCAG-Anforderung ab, denn die WCAG hebt auf den bestimmbaren Linkzweck ab.

PDF/UA gilt allgemein als zu erfüllender Standard, wenn es um barrierefreie PDF-Dateien geht. Wenn die Konformität zu PDF/UA erreicht werden soll, müssen Links einen Tooltip bekommen, was sinnvollerweise bereits im Originaldokument (zum Beispiel als QuickInfo für einen Link in einer Word-Datei) anzulegen ist. Wer barrierefreie PDF aus einer anderen Anwendung PDF/UA-konform generieren will, muss Tooltips ebenfalls berücksichtigen.

Pikanterweise wird der contents-Schlüssel in einer PDF-Datei weder am Bildschirm angezeigt noch von Screenreadern ausgegeben. Was Adobe Acrobat angeht, so taucht ein contents-Schlüssel eines Links in PDF gar nicht erst in der entsprechenden Schnittstelle (den sogenannten Accessibility-Tree) auf, und Screenreader können den Inhalt gar nicht ausgeben. Die Berücksichtigung von Tooltips wird nur zur Erfüllung des PDF/UA-Standards benötigt.

Empfehlung

Tooltips sollten für Links eigentlich vermieden werden. Wenn PDF-Dateien generiert werden und PDF/UA-Konformität erzielt werden muss, dann gibt es keine „sinnvolle“ Empfehlung für den Text im Tooltip eines Links. Tooltips sollten nur Texte wiederholen, die bereits im visuellen Kontext sichtbar sind. In der Praxis wird meist der Linktext einfach wiederholt. Einen Nutzen stiftet diese Technik niemanden.

Zu dieser Fragestellung habe ich auf Twitter auch keine befriedigenden Antworten bekommen:

Warum wollen so viele Tooltips für Links in Dokumenten schreiben? Wegen der Barrierefreiheit? In welchen Screenreadern und in welchen Dokumentenformaten funktioniert das denn? #a11y

— Jan Hellbusch (@2bweb) February 19, 2020

Für Webseiten, aber auch für alle Dokumente außer PDF können Tooltips im Allgemeinen weggelassen werden. Stattdessen sollte versucht werden jedem Link einen Linkkontext zu geben. Nur wenn es nicht möglich ist, einen Linkkontext herzustellen, muss gehandelt werden:

• Da es bei Erfolgskriterium 2.4.4 um Screenreader geht, sollte bei Webseiten ein sichtbarer Text (aus dem visuellen Kontext) per aria-describedby mit dem Link verknüpft werden. title-Attribute für Links auf Webseiten sollten ansonsten vermieden werden.
• In Dokumentformaten käme zwar ein Tooltip in Frage, um Erfolgskriterium 2.4.4 zu erfüllen, aber beispielsweise in Microsoft Word werden Tooltips (QuickInfos) für Links ebenfalls nicht von Screenreadern unterstützt, denn auch Microsoft Word schreibt den Tooltip nicht in den Accessibility-Tree. Der QuickInfo in Microsoft Word erfüllt Erfolgskriterium 2.4.4 ebenso wenig wie der contents-Schlüssel in PDF.

So gesehen fördert ein Tooltip die Barrierefreiheit nicht, im Gegenteil: Sie ist ohne Nutzen beziehungsweise nur für bestimmte Nutzergruppen (insbesondere Mausnutzer) zugänglich. Unter dem Strich dürften Tooltips nicht eingesetzt werden, weil sie nicht barrierefrei sind.

Diese Empfehlungen sind nicht neu. Warum Online-Redaktionen Tooltips tatsächlich für Links berücksichtigen, ist nicht klar. In jedem Fall kann aber die PDF/UA-Spezifikation (nicht nur an diese Stelle) als unstimmig oder gar fehlerhaft bezeichnet werden. Darüber hinaus gibt es wie bei vielen anderen Themen das Copy&Paste-Phänomen: Was vor 15 Jahren galt, wird bis heute fortgeschrieben, obwohl es seit über 10 Jahren neue Regeln gibt.