Warum Links nicht in einem neuen Tab geöffnet werden sollten

Die zwei wichtigsten Gründe, Links nicht in einem neuen Fenster zu öffnen, sind Barrierefreiheit und die Freiheit des Nutzers selbst zu entscheiden, wie sich Links verhalten.

Neue Fenster zu öffnen kann für Nutzer überraschend und verwirrend sein. Betroffen sind auf der einen Seite Nutzer, die auf Screenreader angewiesen sind, aber auch Nutzer mit Konzentrationsschwierigkeiten können durch den plötzlichen Wechsel aus ihrer Konzentration gerissen werden. Dazu kommt, das einigen Nutzern der Fenster- oder Tab-Wechsel nicht auffällt, weil sie z.B. eine Bildschirm-Lupe nutzen, oder tatsächlich so konzentriert auf den Inhalt sind, dass sie es schlicht nicht mitbekommen. Insbesondere bei der Navigation auf Smartphones fällt der Tab-Wechsel oft nicht auf, da hier bei manchen Browsern lediglich der Tab-Zähler inkrementiert wird.

Das Öffnen eines Links in einem neuen Tab führt zusätzlich dazu, das z.B. die Browser-Funktionen des Zurück-Springens nicht mehr funktionieren. Diese kann auf verschiedene Weise bedient werden: über den Zurück-Button des Browsers, durch die Zurück-Tasten an vielen Mäusen, durch horizontales Scrollen oder Wischen ( z.B. mit dem Mausrad oder der Apple Magic-Mouse oder auf Touch-Geräten wie Smartphones und Tablets). Tatsächlich habe ich schon einige Male Nutzern über die Schulter geschaut, die in dieser Situation dann nicht den Tab geschlossen haben, sondern das gesamte Browserfenster. Sie waren so desorientiert, das die intuitive Reaktion war, komplett von vorne anzufangen: neues Fenster öffnen und mühsam wieder auf die vorherige Ansicht navigieren.

Und warum sollte der Entwickler der Seite dem Nutzer vorschreiben, dass dieser das Linkziel unbedingt in einem neuen Tab öffnen muss? Das Problem ist, wenn das Standardverhalten überschrieben wird, hat der Nutzer nicht mehr die Möglichkeit zu entscheiden, was in dem Moment und auf dem Gerät gerade das Richtige für ihn ist. In manchen Situationen brauche ich das eine, in anderen vielleicht das andere. Im Standard-Verhalten gibt es vielfältige Möglichkeiten, den Link trotzdem in einem neuen Tab, zu öffnen:

• Rechtsklick und „Öffnen in neuen Tab“ auswählen
• Klick mit mittlerer Maustaste
• Klick mit gedrückter CMD/STRG-Taste
• Drag’n’Drop des Links in die Tableiste oder aus dem Fenster heraus
• Mit der Tastatur den Fokus auf den Link setzen und CMD/STRG + ENTER drücken
• Rechtsklick, „Link kopieren“, neuen Tab öffnen, Zwischenablage einfügen

Im umgekehrten Fall funktioniert nur die letzte und doch sehr umständliche Variante: Rechtsklick, Link kopieren, URL-Leiste auswählen, Zwischenablage einfügen.

Werden Links also automatisch in einem neuen Tab geöffnet, wird dem Nutzer die Option genommen, selbst zu entscheiden. Wir denken wir wüssten es besser als der Nutzer, tun wir aber nicht. Lass dem Nutzer die Wahl!

Es gibt also gute Gründe, Links nicht in einem neuen Fenster zu öffnen. Und auch einige schlechte Gründe, die oft genannt werden, um zu rechtfertigen es trotzdem zu tun. Hier beispielhaft ein paar der schlechten Gründe, die ich immer wieder in Diskussionen höre:

• „Ich will den User nicht komplett wegführen“: 
  Oft ist das, was dahinter steht, der Marketing-Gedanke, dass Besucher dann die eigene Website nicht verlassen. Tatsächlich tun sie das in einem neuen Tab aber „noch mehr“ da dann ja sogar der Zurück-Button des Browsers nicht mehr wie gewohnt funktioniert. Es wird ihm also sogar schwerer gemacht, wieder zurückzukehren.
• „Mir ist ja eigentlich viel wichtiger, dass der Kunde sich mit dem Produkt beschäftigt und nicht mit [xy].“: 
  Wenn das Produkt interessant war, wird der Kunde zurückkommen. Wenn nicht, ist der alte Tab auch schnell geschlossen.
• „Mir ist das Öffnen im neuen Tab lieber.“ 
  Persönliche Präferenzen unterscheiden sich. Nur weil dir das lieber wäre, rechtfertigt das nicht, die Barriere- und Wahlfreiheit aller Nutzer einzuschränken. Zudem ist meiner Erfahrung nach die User Experience mit der wichtigste Punkte bei der Entwicklung einer Website und die Präferenzen der Besucher zu berücksichtigen ist ein wichtiger Aspekt davon.

Aber natürlich gibt es zu jeder Regel auch Ausnahmen. Das W3C beschreibt in der Guideline G200: Opening new windows and tabs from a link only when necessary wann es berechtigt ist, Links in einem neuen Tab zu öffnen:

1. Opening a page containing context-sensitive information, such as help instructions, or an alternate means of completing a form, such as a calendar-based date picker, will significantly disrupt a multi-step workflow, such as filling in and submitting a form, if the page is opened in the same window or tab.
2. The user is logged into a secured area of a site, and following a link to a page outside of the secured area would terminate the user's logon. In this case opening external links in an external window allows the user to access such references while keeping their login active in the original window.

Offensichtliche Beispiele dafür sind das Anzeigen der AGB während eines Bestellvorgangs oder eben die genannten Hilfe-Seite bei der Formular-Eingabe. In solchen Fällen wären durch ein Verlassen des Kontextes Eingaben erneut nötig – was natürlich kein sinnvolles Verhalten darstellt.

Hier gibt es aber auch andere Lösungsansätze. Sowohl GitHub als auch GitLab lassen es beispielsweise ohne Warnung zu, dass man das Formular zum Erstellen eines Issues verlässt, z.B. über den (externen) Link zu den Community Guidelines. Ein Problem ist das aber auf diesen Plattformen nicht. Eingaben werden im LocalStore des Browsers hinterlegt, sodass die sorgsam formulierten Texte nicht verloren gehen und bei der Navigation zurück direkt wieder da sind. Ich persönlich finde das eine viel elegantere Lösung. (Das hilft übrigens ganz nebenbei auch noch bei einem Absturz des Browsers.)

CSS-Tricks nennt noch eine weitere interessante Ausnahme: durch den Nutzer initiierte Medienwiedergabe. Diese würde beendet werden, wenn die Seite durch einen Link verlassen wird. Spannend jedoch: YouTube kümmert sich darum nicht. Ich vermute, weil es auf einer reinen Video-Platform wie YouTube die Erwartung ist, dass das aktuelle Video unterbrochen wird, wenn ich ein anderes Video auswähle. Bei einem Musik-Player erwarte ich ja auch nicht, dass das aktuelle Lied weiter läuft, wenn ich ein neues starte. Aber auch hier: hat man nur versehentlich auf das neue Video geklickt und navigiert zum vorherigen Video, hat sich YouTube die Abspielposition gemerkt und die die Wiedergabe wird an der Stelle fortgesetzt.

So richtig interessant wird es jetzt nochmal, wenn man sich überlegt, ob und wie externe Links gekennzeichnet werden. Als diese Diskussion intern in unserem Frontend-Team aufkam, war ich zunächst der Meinung, dass Links nur markiert werden sollten, wenn sie sich in einem neuen Fenster öffnen.

Tatsächlich empfehlen aber vielen Quellen externe Links allgemein mit einem kleinen Icon zu markieren, ähnlich wie wir es bis vor kurzem im mStudio getan haben. Als Beispiel wird oft Wikipedia genannt, die externe Weblinks eben genau so handhaben: visuell markieren, aber nicht automatisch in einem neuen Tab öffnen. Ein weiteres Beispiel: U.S. Web Design System (USWDS). Hier wird dieses Icon ebenfalls für externe Links verwendet, unabhängig davon, ob sie sich im selben Fenster oder in einem neuen öffnen.

Als ich einem Kollegen davon erzählt habe, war seine Reaktion ähnlich wie meine Meinung vor der Recherche:

Uh, interessant. Ich hab’ das (genannte) Icon in seiner Semantik immer fest mit “Macht einen neuen Tab auf” assoziiert, und nicht mit “Externer Link”.

Und das ist nicht verwunderlich. Der Guide G201 des W3C beschreibt, dass eine Warnung dem Nutzer helfen kann die oben beschriebenen Probleme zu verstehen und dadurch die Barrierefreiheit sichergestellt wird, wenn man dann doch mal einen Link in einem neuen Tab öffnen muss.

Für die Umsetzung werden zwei Beispiele genannt:

1. Aufnahme des Warnhinweises in den Beschreibungstext:
   hier wird ein Text in dem Link beigefügt, der das Verhalten beschreibt. Hervorheben möchte ich dabei, dass der Text echter Teil des Links ist und für alle Clients (nicht nur für Screenreader) sichtbar ist.
2. Verwendung von CSS, um eine Warnung […] anzuzeigen:
   hier wird über CSS und einen <svg>-Tag ein Icon eingebunden. Das Icon erhält zusätzlich einen title, sodass es auch für Accessibility-Tool interpretierbar ist. An diesem Beispiel sieht man gut, dass alleine das Icon nicht ausreichend ist.

Spannend finde ich: hier wird für den 08-15-Website-User nur das Icon zur Warnung genutzt, also ein Widerspruch zwischen den genannten Guidelines von Wikipedia und dem USWDS zum Guide des W3C.

Wenn man das Icon also verwendet, wie es Wikipedia macht, kommen sich jetzt zwei UX-Paradigmen in die Quere:

Gib dem Nutzer die Wahl VS. Breche nicht mit den Erwartungen der Nutzer

Wie also mit diesem Dilemma umgehen? Links doch in einem neuen Tab öffnen? Einfach nur das Icon nicht mehr verwenden? Eine gute Frage … das Feedback, das wir dazu bekommen haben, hat auf jeden Fall schonmal dafür gesorgt, dass das Thema im Frontend-Team nochmal diskutiert wurde.

Allerdings … in seinem Artikel „The Worst Practice Cycle“ beschreibt Mark Root-Wiley wie sich eine aus Bequemlichkeit getroffene Entscheidung zu einer „worst practice“ entwickelt, obwohl diese Lösung eigentlich der „best practice“ widerspricht. Kurzfristig ist es dann natürlich einfacher, diese gewohnte „worst practice“ zu übernehmen, auch wenn es eigentlich gute Argumente für die ursprüngliche best practice gibt. Er vertritt jedoch eine andere Meinung – die ich teile: die Verantwortung von uns Webentwicklern ist es, langfristig zu denken und die Nutzerinnen, aber auch andere Entwickler*innen, aufzuklären und zu zeigen, warum die best practice ihren Mehrwert hat.

I want the ecosystem in which I work to be better for everyone. In trying to help that effort, I work hard to blog about best practices and advocate for them in presentations, trainings, and conversations.

I really do understand the urge to just follow the crowd and do what’s familiar and easy. But I hope you, dear website owner, can join me in moving the web forward.

Auch unternehmensintern sind wir nicht perfekt. Es gibt mit Sicherheit auch auf unseren Seiten und in unseren Systemen Links, die sich in einem neuen Fenster öffnen, obwohl das nicht sein sollte. Bei Systemen, die über viele Teams, teilweise sogar Abteilungen hinweg gepflegt und verwaltet werden, bleibt das nicht aus. Wir versuchen durch interne Schulungen und Gespräche bei allen beteiligten Autorinnen und Entwicklerinnen das Wissen zu streuen und das Bewusstsein dafür zu schärfen.

Es ist ziemlich sicher, dass wir die allermeisten Links so beibehalten bzw. anpassen werden, dass sie sich im selben Fenster öffnen. Bei spezifischen Links überlegen wir, ob hier eine Ausnahme gerechtfertigt ist. Einen Bereich, den wir bereits als Ausnahme identifiziert haben, ist das mStudio und das Kundencenter. Der starke App-Charakter dieser Verwaltungsoberflächen lässt uns dazu tendieren, hier nicht das Standard-Verhalten zu nutzen. Usability-Tests mit A11y-Experten dazu stehen aber noch aus. Lasst uns gerne weiterhin Feedback da.

Und zum Icon: Hier haben wir uns nach ausgiebiger Diskussion dazu entschieden, das Icon nach der Semantik „Öffnet sich in einem neuen Tab“ zu verwenden, so wie es von vielen von euch (und uns) auch intuitiv interpretiert wurde. Es gibt zwar wie erwähnt auch Guides, die das andere Verhalten empfehlen, wir möchten uns hier aber am Guide des W3C orientieren – die entsprechende Änderung für unsere UI-Bibliothek haben wir bereits implementiert.

• W3C G200: Opening new windows and tabs from a link only when necessary
• Guide G201 des W3C
• Nielsen Norman Group: Opening Links in New Browser Windows and Tabs
• CSS-Tricks: When to use target="_blank"
• Wikipedia: External link icons
• U.S. Web Design System (USWDS): Link
• Graham Armfield: Why None of the External Links on this Website Open in a New Window
• Mark Root-Wiley: Don’t Open Links In New Windows
• Mark Root-Wiley: The Worst Practice Cycle