Link-Vorschau beim Überfahren: Hover-Previews und Link-Karten

Wo gibt es Hover-Vorschauen heute noch?

Ein bekanntes heutiges Beispiel für Hover-Vorschauen sind die Seitenvorschauen der Wikipedia. Die Funktion „Page Previews“ erscheint beim Überfahren eines Links auf einen anderen Artikel. Sie zeigt eine kurze Zusammenfassung und, falls vorhanden, ein Bild. Laut der Projektseite auf mediawiki.org lief das Projekt von März 2014 bis Mai 2018 (Quelle: mediawiki.org/wiki/Page_Previews, Stand: Oktober 2026).

Die Wikimedia-Entwickler begründen Page Previews mit dem Lesefluss. Ohne Vorschau müssten Leser mehrere Tabs öffnen, um einen Begriff im Zusammenhang zu verstehen. Die Vorschau soll die „Kosten“ eines Links senken und Kontext liefern, ohne die Seite zu verlassen (Quelle: mediawiki.org/wiki/Page_Previews, Stand: Oktober 2026).

Eine zweite Form der Link-Vorschau entsteht nicht beim Überfahren, sondern beim Teilen. Messenger und soziale Netzwerke bauen aus Titel, Beschreibung und og:image einer Seite eine Karte. Diese Angaben definiert das Open-Graph-Protokoll (Quelle: ogp.me/, Stand: Oktober 2026). Wie man sie setzt, beschreibt Open-Graph-Bild richtig setzen.

Warum funktioniert Hover auf dem Smartphone nicht zuverlässig?

Die CSS-Pseudoklasse :hover ist auf Touchscreens laut MDN problematisch. Je nach Browser greift sie nie oder nur kurz nach dem Antippen. Oder sie bleibt aktiv, bis ein anderes Element berührt wird. MDN fordert deshalb, Inhalte auch auf Geräten mit eingeschränkter oder ohne Hover-Fähigkeit zugänglich zu machen (Quelle: developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/:hover, Stand: Oktober 2026).

Die Media-Abfrage @media (hover: hover) beschränkt eine Hover-Vorschau auf passende Geräte. Gemeint sind Geräte, deren primäres Eingabegerät bequem schweben kann. Der Wert none steht laut MDN für Eingaben, die gar nicht oder nur unbequem schweben können. Ein Beispiel sind Mobilgeräte, die Hover per langem Tippen nachbilden. Die Abfrage ist seit Dezember 2018 browserübergreifend verfügbar (Quelle: developer.mozilla.org/en-US/docs/Web/CSS/Reference/At-rules/@media/hover, Stand: Oktober 2026).

.linkvorschau { display: none; }
@media (hover: hover) {
  a:hover + .linkvorschau,
  a:focus-visible + .linkvorschau { display: block; }
}

Tastaturnutzer brauchen für Hover-Vorschauen denselben Zugang wie Mausnutzer. Dafür eignet sich die Pseudoklasse :focus-visible. Sie greift, wenn ein Element den Fokus hat und der Browser den Fokus sichtbar machen will. Der Browser entscheidet das per Heuristik, typischerweise bei Tastaturbedienung (Quelle: developer.mozilla.org/en-US/docs/Web/CSS/Reference/Selectors/:focus-visible, Stand: Oktober 2026).

Was verlangt WCAG 2.2 von Hover-Vorschauen?

Für Link-Vorschauen gilt das WCAG-2.2-Kriterium 1.4.13 „Content on Hover or Focus“ (Stufe AA). Es erfasst Inhalte, die bei Hover oder Fokus erscheinen und wieder verschwinden. Das Kriterium verlangt drei Dinge. Die Vorschau muss sich ohne Bewegen von Maus oder Fokus schließen lassen (dismissible). Der Mauszeiger muss auf die Vorschau wandern können, ohne dass sie verschwindet (hoverable). Sie muss sichtbar bleiben, bis Hover oder Fokus enden, der Nutzer sie schließt oder ihre Information nicht mehr gilt (persistent) (Quelle: w3.org/WAI/WCAG22/Understanding/content-on-hover-or-focus.html, Stand: Oktober 2026).

Vom WCAG-Kriterium 1.4.13 ausgenommen sind Inhalte, deren Darstellung der Browser steuert. Ein Beispiel sind Tooltips aus dem HTML-Attribut title. Eigene Tooltips, Untermenüs und andere nicht-modale Popups fallen dagegen ausdrücklich darunter (Quelle: w3.org/WAI/WCAG22/Understanding/content-on-hover-or-focus.html, Stand: Oktober 2026).

Das Bild in einer Hover-Vorschau braucht zusätzlich eine Textalternative. Das verlangt das Kriterium 1.1.1 „Non-text Content“ (Stufe A): Jeder Nicht-Text-Inhalt braucht eine Textalternative mit gleichem Zweck. Ausgenommen sind die im Kriterium aufgeführten Situationen, etwa Bedienelemente, zeitbasierte Medien und reine Dekoration (Quelle: w3.org/TR/WCAG22/#non-text-content). Die aktuelle Fassung der W3C-Empfehlung WCAG 2.2 trägt das Datum 12. Dezember 2024 (Quelle: w3.org/TR/WCAG22/, Stand: Oktober 2026).

Kann HTML Hover-Vorschauen ohne JavaScript?

Das Popover-API von HTML liefert Bausteine für Hover-Vorschauen ohne JavaScript. Das globale Attribut popover macht ein Element zum Popover. Mögliche Zustände sind auto, hint oder manual. MDN beschreibt außerdem „Interest Invokers“. Das Attribut interestfor an einem Link oder Button verweist auf die ID eines Popovers. Dieses erscheint dann bei Hover oder Fokus, ohne JavaScript (Quelle: developer.mozilla.org/en-US/docs/Web/API/Popover_API, Stand: Oktober 2026).

<a href="https://example.org/" interestfor="vorschau-1">example.org</a>
<div id="vorschau-1" popover="hint">
  <img src="/thumbs/example-org.webp" width="320" height="200"
       alt="Startseite von example.org">
</div>

MDN führt das Popover-API als „Baseline 2025 – Newly available“. Seit Januar 2025 funktioniert es in den aktuellen Browsern. Auf älteren Geräten funktioniert es womöglich nicht, und einzelne Teile werden unterschiedlich unterstützt (Quelle: developer.mozilla.org/en-US/docs/Web/API/Popover_API, Stand: Oktober 2026). Für interestfor lohnt deshalb vor dem Einsatz ein Blick in die Kompatibilitätstabelle.

Woher kommt das Bild einer Hover-Vorschau?

Das Bild einer Hover-Vorschau sollte vorab erzeugt und von der eigenen Domain ausgeliefert werden. Ein Live-Abruf bei einem fremden Dienst übermittelt die IP-Adresse des Besuchers. Das Landgericht München I sah 2022 darin beim Einbinden von Google Fonts einen Rechtsverstoß. Die Schriften ließen sich nämlich auch ohne Verbindung zu Google nutzen (Quelle: gesetze-bayern.de/Content/Document/Y-300-Z-BECKRS-B-2022-N-612). Wie man Screenshots selbst erzeugt, steht unter Website-Screenshot selbst erstellen.