Buttons vs. Links: der richtige Einsatz

Ein Link führt woanders hin, ein Button löst etwas aus: Wer navigiert – zu einer anderen Seite, einem Anker, einem Dokument –, nimmt <a href>; wer eine Aktion anstößt – absenden, ein Menü öffnen, mehr laden –, nimmt <button>. Das Aussehen darfst du dabei frei wählen; die Wahl des Elements folgt der Funktion, nicht dem Design.

Es ist eine der kleinsten Entscheidungen im Frontend und eine der folgenreichsten. Beide Elemente kann man so gestalten, dass sie identisch aussehen – für das Auge ist der Unterschied also keiner. Für Tastatur, Screenreader und Sprachsteuerung liegen dagegen Welten dazwischen.

Das Wichtigste in Kürze

• Ortswechsel = Link, Zustandsänderung = Button. Das ist die ganze Regel.
• Ein Test, der fast immer trägt: Könnte man das sinnvoll in einem neuen Tab öffnen? Wenn ja, ist es ein Link.
• Screenreader führen getrennte Listen für Links und Schaltflächen – eine falsch ausgezeichnete Aktion versteckt sich in der falschen Liste.
• Der <div>-Button ist der teuerste Fehler: nicht fokussierbar, nicht tastaturbedienbar, ohne Rolle.
• Im Formular gehört an jeden Button ein type – sonst sendet er ungewollt ab.
• WCAG-Bezug: 4.1.2 Name, Rolle, Wert und 2.1.1 Tastatur – beide Stufe A.

Der Unterschied im Detail

Diese Unterschiede sind nicht kosmetisch. Vier Konsequenzen, die im Alltag zählen:

Die Rolle setzt eine Erwartung. Wer „Link“ hört, rechnet mit einem Ortswechsel; wer „Schaltfläche“ hört, mit einer Aktion. Ein Link, der plötzlich ein Modal öffnet, ist so überraschend wie ein Button, der die Seite wechselt.

Screenreader führen getrennte Listen. Nutzende können sich alle Links oder alle Schaltflächen einer Seite auflisten lassen und darüber springen. Wer „In den Warenkorb“ als Link auszeichnet, sorgt dafür, dass diese Aktion in der Schaltflächenliste fehlt – und dass die Linkliste mit Einträgen zugemüllt wird, die nirgendwohin führen.

Die Tastaturbedienung folgt der Rolle. Ein Button reagiert auf Enter und Leertaste, ein Link nur auf Enter. Baut man das mit dem falschen Element nach, muss man dieses Verhalten mühsam selbst nachrüsten.

Sprachsteuerung braucht die Rolle. Wer per Sprache bedient, sagt „Klick In den Warenkorb“. Damit das funktioniert, muss der sichtbare Text Teil des zugänglichen Namens sein (2.5.3 Beschriftung im Namen) – und das Element muss die erwartete Rolle haben.

Der Entscheidungsbaum

In der Reihenfolge, in der ich die Fragen in der Praxis durchgehe:

1. Führt die Betätigung zu einer anderen Adresse – Seite, Anker, Datei, fremde Domain?

   Ja Es ist ein Link: <a href="…">.

   Nein Weiter zu Frage 2.

2. Ändert sich nur etwas auf der aktuellen Seite – aufklappen, filtern, absenden, umschalten?

   Ja Es ist ein Button: <button type="button">.

   Nein Weiter zu Frage 3.

3. Beides – erst passiert etwas, danach wird umgeleitet (Logout, Bestellung abschicken)?

   Ja Das Hauptverhalten entscheidet, und das ist die Aktion: ein Button, meist in einem kleinen <form>.

   Nein Wenn du hier landest: Würde „In neuem Tab öffnen“ Sinn ergeben? Dann Link, sonst Button.

Der häufigste Fehler: der <div>-Button

Das größte Problem ist gar nicht die Verwechslung von <a> und <button>, sondern der komplette Verzicht auf beide:

<!-- Falsch: ein klickbares div ist kein Bedienelement -->
<div class="btn" onclick="senden()">Absenden</div>

So ein <div> ist nicht fokussierbar, reagiert nicht auf die Tastatur und hat für einen Screenreader keine Rolle – es ist schlicht kein Bedienelement. Wer es nachrüsten will, braucht überraschend viel:

<!-- Der Nachbau – und selbst der ist noch unvollständig -->
<div
  class="btn"
  role="button"
  tabindex="0"
  onclick="senden()"
  onkeydown="if (event.key === 'Enter' || event.key === ' ') { event.preventDefault(); senden(); }"
>
  Absenden
</div>

Zwei Attribute, ein zusätzlicher Tastatur-Handler – und das preventDefault(), damit die Leertaste nicht die Seite scrollt. Was dann immer noch fehlt: der deaktivierte Zustand, das Absenden im Formular, das Verhalten bei erzwungenen Farbmodi, die Unterstützung von Sprachsteuerung. Dagegen:

<!-- Richtig: das native Element kann das alles schon -->
<button type="button" onclick="senden()">Absenden</button>

Genau das meint die erste Regel von ARIA: Nimm das native Element, statt seine Rolle nachzubauen.

Ebenso verbreitet ist der Link ins Nichts: <a href="#" onclick="…">. Er führt nirgendwohin und tut eigentlich etwas – also ist er weder Fisch noch Fleisch. Bei einem Klick springt die Seite zusätzlich nach oben. Soll etwas passieren, gehört dahin ein Button.

Und eine Stufe schlimmer ist das <a> ohne href: Ohne dieses Attribut ist ein Anker kein Link mehr – er ist nicht fokussierbar und hat keine Rolle. Optisch fällt das nie auf.

Aussehen ist frei – das Element folgt der Funktion

Wichtig ist die Trennung von Bedeutung und Optik: Ein Link darf wie ein Button aussehen, und ein Button darf wie ein Link aussehen. Man wählt das Element nach der Funktion und gestaltet es danach beliebig.

Auf der Startseite dieser Website sind die großen „Buttons“ zum Beispiel bewusst <a>-Elemente – sie sehen aus wie Schaltflächen, führen aber zu einer anderen Seite, sind also Links. Ein „Absenden“ im Formular daneben wäre umgekehrt immer ein echter <button>, egal wie schlicht er gestaltet ist.

Diese Entscheidung hat eine Nebenwirkung, die selten mitgedacht wird: Ein Crawler folgt nur <a href="…">. Eine Navigation aus <button>-Elementen mit onclick ist für Suchmaschinen und KI-Systeme eine Sackgasse – die Zielseiten existieren dann zwar, sind aber nicht verlinkt und erben keine Relevanz. Was das für die Struktur einer Website bedeutet, steht unter Interne Verlinkung als Strategie.

Die Stolperfalle type im Formular

Ein Detail, das ich schon oft als Fehlerquelle erlebt habe: Innerhalb eines <form> ist <button> standardmäßig ein Absende-Button (type="submit"). Ein Button, der etwas anderes tun soll – ein Akkordeon aufklappen, ein Feld hinzufügen –, muss deshalb ausdrücklich type="button" bekommen, sonst schickt er beim Klick ungewollt das ganze Formular ab.

<form action="/bestellen" method="post">
  <button type="button" onclick="zeileHinzufuegen()">Zeile hinzufügen</button>
  <button type="submit">Bestellung abschicken</button>
</form>

Das ist eine Zeile, die ich mir zur Gewohnheit gemacht habe: type an jedem Button im Formular bewusst setzen.

Zwei Ergänzungen, die selten bekannt sind: Ein zweiter Absende-Button kann mit formaction ein abweichendes Ziel ansteuern (etwa „Als Entwurf speichern“), und <button> ist dem alten <input type="submit"> vorzuziehen, weil er Auszeichnung im Beschriftungstext erlaubt – ein Icon plus Text zum Beispiel.

Die Grenzfälle, über die man wirklich streitet

Zwei dieser Zeilen verdienen einen Kommentar. Filter sind der klassische Zweifelsfall: Wer sie als Link auf eine echte URL baut, bekommt Teilbarkeit, Vor-/Zurück-Navigation und Funktion ohne JavaScript geschenkt – dieselbe Sache als Button gebaut, verliert all das. Und der Logout ist deshalb ein Button, weil ein Link von Browsern und Sicherheits-Scannern vorab abgerufen werden kann; wer sich schon einmal durch einen Linkprüfer ausloggen ließ, macht diesen Fehler kein zweites Mal.

Deaktivierte Schaltflächen: disabled oder aria-disabled?

Ein Thema, an dem sich Barrierefreiheit und gute Bedienung reiben. Das native disabled schaltet die Schaltfläche vollständig ab – sie ist nicht mehr klickbar, nicht mehr fokussierbar und taucht beim Durchtabben nicht auf. Wer per Tastatur oder Screenreader unterwegs ist, findet sie schlicht nicht und erfährt auch nicht, warum sie nicht geht.

<!-- Ganz abgeschaltet: unsichtbar für die Tastatur -->
<button type="submit" disabled>Bestellung abschicken</button>

<!-- Auffindbar, aber wirkungslos – mit Erklärung, was fehlt -->
<button type="submit" aria-disabled="true" aria-describedby="warum">
  Bestellung abschicken
</button>
<p id="warum">Bitte bestätige zuerst die Lieferadresse.</p>

Die Faustregel, mit der ich gut fahre: disabled ist richtig, wenn die Schaltfläche gerade schlicht bedeutungslos ist (etwa in einem inaktiven Bereich). Sobald sie das Ziel der Nutzenden ist und nur noch eine Bedingung fehlt, ist aria-disabled="true" besser – die Schaltfläche bleibt auffindbar und kann erklären, was fehlt. Wichtig dabei: aria-disabled verhindert nichts von selbst; die Wirkung muss man im Handler unterbinden.

Gestaltung: drei Dinge, die man nicht verhandeln sollte

• Sichtbarer Fokus. Beides sind Bedienelemente; wer sie per Tastatur erreicht, muss sehen, wo er ist. Details unter Tastaturbedienung & sichtbarer Fokus.
• Zielgröße. Mindestens 24 × 24 CSS-Pixel oder ausreichend Abstand zum Nachbarn (2.5.8 Zielgröße). Icon-Schaltflächen sind hier die üblichen Sünder.
• Ein zugänglicher Name. Ein Button mit reinem Icon braucht Text – sichtbar oder per aria-label. Siehe Icons & SVGs.

Häufige Fehler

• <div> oder <span> mit onclick. Nicht fokussierbar, nicht tastaturbedienbar, ohne Rolle.
• <a href="#"> für Aktionen. Ein Link, der nirgendwohin führt – hier gehört ein Button hin.
• <a> ohne href. Kein Link, kein Fokus, keine Rolle.
• Button für Navigation. Wer per JavaScript die URL ändert, statt ein <a href> zu nutzen, setzt „in neuem Tab öffnen“, Mittelklick und das Kopieren des Links außer Kraft.
• type vergessen. Im Formular sendet ein Button ohne type="button" ungewollt ab.
• role="button" auf einen Link geklebt. Dann sagt der Screenreader „Schaltfläche“, das Element verhält sich aber wie ein Link – die Ansage lügt.
• Nur ein Icon ohne Text. Ein Button braucht einen zugänglichen Namen.
• disabled auf dem Absende-Button, bis das Formular fehlerfrei ist – die häufigste unbeabsichtigte Sackgasse in Formularen.

Häufige Fragen

Und wenn etwas sowohl navigiert als auch eine Aktion auslöst?

Dann entscheidet das Hauptverhalten. Ein „Logout“, der serverseitig eine Aktion ausführt und danach umleitet, ist ein Button (meist in einem kleinen Formular). Im Zweifel frage ich: Könnte man das sinnvoll in einem neuen Tab öffnen? Wenn ja, ist es ein Link.

Brauche ich role="button" überhaupt jemals?

Selten. role="button" ist für die Fälle gedacht, in denen ein <button> partout nicht möglich ist – und selbst dann musst du Fokus und Tastatur selbst nachrüsten. In fast allen Situationen ist das echte <button>-Element die bessere Wahl.

Darf ein Link aussehen wie ein Button?

Ja. Wichtig ist nur, dass er sich auch wie ein Link verhält: Mittelklick, „in neuem Tab öffnen“ und das Kopieren der Adresse müssen funktionieren. Umgekehrt gilt dasselbe: Ein als Textlink gestalteter Button bleibt eine Schaltfläche.

Wie sieht es mit der Tastaturbedienung aus?

Native <a href> und <button> sind automatisch fokussierbar und in der Tab-Reihenfolge. Worauf es bei Fokus und Reihenfolge sonst noch ankommt, behandelt Tastaturbedienung & sichtbarer Fokus.

Was ist mit klickbaren Karten oder Tabellenzeilen?

Die Zeile oder Karte selbst ist kein Bedienelement. Üblich und robust ist ein echter Link auf der Überschrift, dessen Klickfläche per CSS über die ganze Karte gezogen wird – siehe Klickbare Cards.

Sind Buttons in Formularen automatisch barrierefrei?

Die Rolle und die Tastaturbedienung ja, der Rest nicht: Beschriftung, Fokus, Zielgröße und die Rückmeldung nach dem Klick bleiben deine Aufgabe. Zur Rückmeldung siehe Statusmeldungen.

Fazit

Führt es woanders hin, ist es ein Link; passiert etwas, ist es ein Button. Diese eine Unterscheidung erspart dir nachgerüstete Tastatur-Handler, falsche Screenreader-Ansagen und kaputte „in neuem Tab öffnen“-Funktionen. Für die Grenzfälle hilft die Tab-Frage, für deaktivierte Schaltflächen die Unterscheidung zwischen disabled und aria-disabled. Das Aussehen darfst du frei wählen – die Wahl des Elements aber nie dem Zufall überlassen.

Quellen

• Button Pattern (W3C ARIA Authoring Practices Guide – erwartetes Tastaturverhalten und Rollen)
• Das button-Element (MDN – Attribute, type, formaction, Zustände)