Das div, das gerne ein Button gewesen wäre

Jeder Entwickler kennt das. Du baust eine Komponentenbibliothek und das Design verlangt nach einem Button. Aber nicht irgendeinem – einem besonderen. Mit individuellem Styling, einem ausgefallenen Hover-Effekt und vielleicht einem Gradienten, der sich beim Drauftippen verschiebt. Also greifst du dir ein <div>, packst CSS drum rum und fertig.

In Figma sieht alles perfekt aus. In der Demo funktioniert es. Und dann tippt ein echter Nutzer durch die Seite, schickt ein Formular per Tastatur ab oder navigiert mit einem Screenreader – und alles bricht zusammen.

Das Problem ist nicht dein CSS. Das Problem ist, dass du ein <div> für einen Job missbraucht hast, für den es nie gedacht war.

Wie man sich ins Chaos programmiert

Was passiert typischerweise? Du brauchst einen Button, der so und so aussieht. Du erstellst ein <div>, gibst ihm class="btn" und stylst es, bis es zum Design passt. Sieht großartig aus. Aber jetzt soll das Ding auch wie ein Button funktionieren.

Also kommt ein Click-Handler dazu. Dann ein Hover-State. Dann ein Focus-Ring für Keyboard-Nutzer. Dann merkst du, dass Space und Enter nicht funktionieren – also baust du keydown-Listener ein. Der Button soll manchmal deaktiviert sein, also fügst du eine .disabled-Klasse hinzu, die hoffentlich alle richtigen Interaktionen blockiert. Irgendwo dazwischen hast du role="button" und tabindex="0" eingefügt, damit zumindest die Barrierefreiheits-Tools deine Kreation nicht komplett ignorieren.

Glückwunsch. Du hast ein button-förmiges Objekt gebaut, das ungefähr 200 Zeilen JavaScript braucht, um das zu approximieren, was der Browser dir kostenlos mitgeliefert hätte.

Das ist das, was wir mit „Zinsen auf schlechte Architekturentscheidungen" meinen. Jede Zeile Workaround-Code ist Zins auf die ursprüngliche Entscheidung, das falsche Element zu verwenden.

Der unsichtbare Vertrag

Hier ist das Ding an nativen HTML-Elementen: Sie kommen mit einem ganzen Interaktionsvertrag, über den sich die meisten Entwickler keine Gedanken machen – bis er fehlt.

Wenn du ein echtes <button>-Element verwendest, bekommst du:

• Automatische Keyboard-Behandlung – Enter und Space funktionieren genau so, wie Nutzer es erwarten
• Korrektes Focus-Management – Der Button ist natürlich in der Tab-Reihenfolge, kann programmatisch fokussiert werden
• Deaktiviert-Verhalten – Blockiert alle Interaktionen, wird nicht mehr fokussierbar, wird als deaktiviert announced
• Formular-Teilnahme – Schickt Formulare ab, respektiert Validierung, funktioniert mit form.reset()
• Barrierefreiheits-Semantik – Screenreader erkennen es ohne extra ARIA als Button
• Platform-Konventionen – Nutzer wissen bereits, wie Buttons sich verhalten, weil Buttons überall konsistent funktionieren

Mit einem <div> im Button-Kostüm bekommst du... das CSS. Alles andere musst du selber bauen. Und hier kommt das Geheimnis: Egal wie sorgfältig du bist – deine Implementierung wird schlechter sein als das, was Browser liefern. Browser-Teams optimieren diese Verhaltensweisen seit Jahren für verschiedene Plattformen, Edge Cases und assistive Technologien. Dein custom Button hat nur dich.

Die richtige Frage ist nicht „Kann ich es stylen?"

Genau hier entsteht entweder magische Design-Engineering-Zusammenarbeit oder technischer Schuldenberg. Entwickler verstehen „semantisches HTML" oft als „hässliche Browser-Defaults akzeptieren". Darum geht es überhaupt nicht.

Die Frage ist nicht „Kann ich das custom aussehen lassen?" – natürlich geht das. Die Frage ist: „Welche nativen Verhaltensweisen sollten das Styling überleben?"

Ein <button> kann jede visuelle Behandlung bekommen, die du willst. Du kannst alle Default-Styles mit appearance: none entfernen. Du kannst Gradients, Schatten, Animationen, Custom Fonts hinzufügen – was auch immer das Design verlangt. Dem Interaktionsvertrag des Browsers ist es egal, wie dein Button aussieht.

Was du mit einem <div> nicht so leicht hinbekommst, ist das zu replizieren, was der Browser dir automatisch gibt. Also wähle deine Schlachten klug: Investiere deine Engineering-Kraft in das, was dein Produkt einzigartig macht – nicht in das Neuerfinden von Buttons.

Bauen für das echte Web

Deine Nutzer benutzen dein Produkt nicht im Vakuum. Sie tabben zwischen Feldern, während ihre Hände auf der Tastatur bleiben. Sie nutzen Sprachsteuerung zum Navigieren. Sie vergrößern den Bildschirm auf 300%, weil das für sie funktioniert. Sie haben verschiedene Browser, verschiedene Betriebssysteme, verschiedene assistive Technologien.

Die Webplattform gibt dir mit semantischem HTML einen massiven Vorsprung. Native Elemente sind standardmäßig barrierefrei, standardmäßig keyboard-navigierbar, standardmäßig plattformübergreifend. Wenn du diese Infrastruktur bekämpfst, machst du dir nicht nur mehr Arbeit – du baust Komponenten, die für echte Nutzer subtil scheitern werden.

Das nächste Mal, wenn du gerade ein <div> mit role="button" greifen willst, frag dich: Baue ich gerade etwas, das wirklich eine custom Implementierung braucht, oder habe ich einfach Angst vor dem <button>-Tag? Denn die langweilige Lösung ist meistens die richtige. Und „der Browser handhabt es korrekt" ist ein Feature, keine Einschränkung.

Das semantische Web geht nicht um das Befolgen von Regeln. Es geht darum, die richtigen Werkzeuge für den Job zu nutzen – und seine Energie dort zu investieren, wo sie tatsächlich einen Unterschied macht.