Buttons vs. Links: der richtige Einsatz

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

Die Regel dahinter ist erfreulich einfach, und ich halte sie für eine der nützlichsten Faustregeln überhaupt: Ein Link führt woanders hin, ein Button löst etwas aus. Wer dorthin navigiert – zu einer anderen Seite, einem Anker, einem Dokument –, braucht ein <a href>. Wer eine Aktion anstößt – absenden, ein Menü öffnen, mehr laden –, braucht ein <button>.

Der Unterschied im Detail

Diese Unterschiede sind nicht kosmetisch. Die angekündigte Rolle setzt eine Erwartung: Wer „Link“ hört, rechnet mit einem Ortswechsel; wer „Schaltfläche“ hört, mit einer Aktion. Und die Tastaturbedienung folgt der Rolle – ein Button reagiert eben auch auf die Leertaste, ein Link nicht. Baut man das mit dem falschen Element nach, muss man dieses Verhalten mühsam selbst nachrüsten.

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 das korrigieren will, müsste tabindex, role="button" und eigene Tastatur-Handler für Enter und Leertaste ergänzen. Drei Attribute und etwas Skript, um nachzubauen, was ein <button> von sich aus mitbringt. Genau das meint die erste Regel von ARIA: Nimm das native Element.

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

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. Soll etwas passieren, gehört dahin ein Button.

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.

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>
  <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.

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.
• Button für Navigation. Wer per JavaScript die URL ändert, statt ein <a href> zu nutzen, bricht „in neuem Tab öffnen“, Mittelklick und das Kopieren des Links.
• type vergessen. Im Formular sendet ein Button ohne type="button" ungewollt ab.
• Nur ein Icon ohne Text. Ein Button braucht einen zugänglichen Namen – siehe Icons & SVGs.

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 meist ein Button (oft 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.

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.

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. Das Aussehen darfst du frei wählen – die Wahl des Elements aber nie dem Zufall überlassen.