Button-Zustände: Warum jeder Knopf zeigen muss, was gerade passiert

Du klickst auf „Absenden“ und nichts passiert. Kein Farbwechsel, keine Meldung. Hat es geklappt? Also klickst du noch einmal. Und noch einmal. Am Ende hat die Firma drei gleiche Anfragen im Postfach, und du bist dir trotzdem nicht sicher. Dieser Beitrag ist Teil 1 meiner Serie Mikrointeraktionen. Ich zeige dir, welche Zustände ein Knopf auf deiner Website braucht. So sieht jeder, was gerade passiert. Das gilt auch für Menschen mit Tastatur oder Screenreader. Am Ende gibt es eine Checkliste zum Abhaken, auch als PDF.

Button-Zustände: Was das ist

Ein Knopf (englisch Button) ist das, was du auf einer Website drückst, damit etwas passiert. Ein Formular abschicken zum Beispiel, oder etwas in den Warenkorb legen. Button-Zustände sind die kleinen sichtbaren Änderungen, mit denen der Knopf dir antwortet. Er sagt damit zum Beispiel: „Ich habe deinen Klick bemerkt“ oder „Ich arbeite gerade“.

Solche kleinen Rückmeldungen heißen Mikrointeraktionen. Meist dauern sie nur einen Augenblick. Trotzdem entscheiden sie, ob sich eine Seite verlässlich anfühlt. Diese Zustände kommen auf fast jeder Website vor:

• Normal: So sieht der Knopf aus, wenn niemand etwas tut. Er muss klar als Knopf erkennbar sein.
• Hover: Die Maus liegt auf dem Knopf. Er ändert zum Beispiel die Farbe.
• Fokus: Wer mit der Tabulator-Taste durch die Seite springt, sieht einen Rahmen um den Knopf. Drückt man jetzt Enter, wird genau dieser Knopf ausgelöst.
• Gedrückt: Der Knopf zeigt im Moment des Klicks, dass er reagiert hat.
• Lädt: Die Aktion dauert. Im Knopf steht etwa „Wird gesendet …“.
• Deaktiviert: Der Knopf ist gerade nicht nutzbar, meist grau.

Woher das Wissen kommt

Der Begriff Mikrointeraktion wurde vor allem durch das Buch „Microinteractions“ von Dan Saffer bekannt (O’Reilly, 2013). Saffer zerlegt jede kleine Interaktion in vier Teile. Für Knöpfe zählt vor allem einer davon: die Rückmeldung, die dir zeigt, was passiert ist. Bei einem Knopf sind die Zustände genau diese Rückmeldung.

Die Nielsen Norman Group ist eine bekannte Beratungsfirma für Benutzerfreundlichkeit. Diese Firma hat die Zustände 2025 in einem eigenen Artikel beschrieben (Gordon, „Button States: Communicate Interaction“). Ihr Fazit: Wie gut ein Knopf seinen Zustand zeigt, ist entscheidend für ein gutes Design. Den Zustand „lädt“ nennt sie ausdrücklich als Ergänzung für Aktionen, die länger dauern.

Die dritte Quelle sind die Web Content Accessibility Guidelines, kurz WCAG. Das ist der internationale Standard für barrierefreie Websites, herausgegeben vom W3C. Mehrere seiner Regeln betreffen Knöpfe direkt. Dazu weiter unten mehr.

Was die Forschung sagt

Warum reicht es nicht, wenn der Knopf einfach funktioniert? Die Antwort liefert eine alte Faustregel von Jakob Nielsen aus dem Jahr 1993 („Response Times: The 3 Important Limits“):

• 0,1 Sekunden sind ungefähr die Grenze, bis zu der eine Reaktion als sofort empfunden wird.
• 1 Sekunde ist ungefähr die Grenze, bis zu der der Gedankenfluss nicht unterbrochen wird.
• 10 Sekunden sind ungefähr die Grenze, bis zu der man aufmerksam bei der Sache bleibt.

Für Knöpfe heißt das: Der gedrückte Zustand muss sofort kommen, also innerhalb von 0,1 Sekunden. Dauert die Aktion länger als etwa eine Sekunde, braucht es den Zustand „lädt“. Sonst fragt sich der Besucher, ob überhaupt etwas passiert. Wie du bei längeren Wartezeiten die richtige Ladeanzeige wählst, kommt in einem eigenen Teil dieser Serie.

Beim deaktivierten Knopf sind sich die Fachleute uneinig. Vitaly Friedman vom Smashing Magazine hat die typischen Probleme 2021 zusammengefasst („Frustrating Design Patterns: Disabled Buttons“). Sein Kernpunkt: Ein deaktivierter Knopf sagt nicht, was falsch ist. Man ist blockiert, weiß aber nicht, warum. Er rät, den Knopf in vielen Fällen aktiv zu lassen. Fehlt etwas, sagt das Formular beim Klick, was genau fehlt.

Die Grenzen dieser Quellen

• Es gibt keine große Studie mit Zahlen zu Button-Zuständen. Die Empfehlungen beruhen auf Nutzertests und Erfahrung. Verspricht dir jemand eine exakte Prozentzahl mehr Anfragen durch Button-Zustände, hat er das vermutlich nicht gemessen.
• Nielsens Zeitgrenzen sind Richtwerte. Er schreibt selbst von „ungefähr“. Die Werte stammen aus den frühen 1990er-Jahren und gelten seither als Faustregel, nicht als feste Grenze.
• Beim deaktivierten Knopf ist sich die Fachwelt nicht einig. Die Nielsen Norman Group beschreibt ihn als normalen Zustand. Friedman hält ihn in vielen Fällen für schädlich. Friedmans Artikel stützt sich auf Beobachtungen, nicht auf eine veröffentlichte Studie.

Wo dich das betrifft

Diese Situationen sehe ich auf Firmenwebsites und in Online-Shops am häufigsten:

• Das Kontaktformular gibt keine Rückmeldung. Nach dem Klick passiert ein paar Sekunden lang nichts. Viele klicken dann ein zweites Mal, und du bekommst die Anfrage doppelt.
• Der Fokus wurde entfernt. Manche Designer finden den Rahmen beim Fokus störend und schalten ihn per Code ab. Wer mit der Tastatur unterwegs ist, sieht dann nicht mehr, wo er gerade ist. Wie du den Fokus gut gestaltest, steht im Beitrag Sichtbarer Fokus.
• Der Knopf „Bestellen“ bleibt grau. Im Shop fehlt ein Haken bei den AGB. Der Knopf sagt das aber nicht. Kunden suchen den Fehler oder brechen ab.
• Der Hover-Effekt ist der einzige Hinweis. Am Handy gibt es keine Maus und damit keinen Hover. Was nur beim Drüberfahren sichtbar wird, fehlt dort ganz.
• Der Fokus verschwindet hinter dem Kopfbereich. Ein fixierter Kopfbereich oder ein Cookie-Banner deckt den Knopf ab, auf dem der Fokus gerade liegt.

Schon mal dein eigenes Kontaktformular abgeschickt und dabei genau hingeschaut? Weißt du ohne Blick ins Postfach, ob es geklappt hat?

Beispiel: Der graue Knopf ohne und mit Begründung

Die Grafik zeigt dasselbe Bestellformular zweimal. In beiden Fällen fehlt noch der Haken bei den AGB. Links ist der Knopf blass grau, ohne Hinweis. Mit der Tab-Taste kommt man nicht einmal hin. Rechts ist der Knopf ebenfalls grau, aber gut lesbar. Direkt darunter steht, was fehlt. Mit der Tab-Taste bleibt er erreichbar, und ein Screenreader liest den Grund mit vor. Ein Screenreader ist eine Software, die den Bildschirm vorliest.

Probier es direkt aus: Klick die Knöpfe mit der Maus an. Danach drück ein paar Mal die Tabulator-Taste und löse sie mit Enter aus.

Technisch steckt hinter der rechten Variante ein kleiner Unterschied. Das HTML-Merkmal disabled schaltet einen Knopf komplett ab. Er fällt dabei auch aus der Reihenfolge, in der man mit Tab durch die Seite springt. Die Alternative heißt aria-disabled. Laut der Entwickler-Dokumentation von Mozilla (MDN) meldet sie den Knopf nur als nicht verfügbar. Er bleibt mit der Tastatur erreichbar. Dein Entwickler muss dann selbst dafür sorgen, dass der Klick nichts auslöst. Das ist eine Sache von wenigen Zeilen.

Barrierefreiheit und Recht

Button-Zustände sind kein reines Geschmacksthema. Mehrere Regeln der WCAG betreffen sie direkt. Die WCAG teilen ihre Regeln in Stufen ein. Gesetzlich zählt die Stufe AA. Sie enthält auch alle Regeln der Stufe A. Die Stufe AAA ist freiwillig. Diese Regeln sind für Knöpfe wichtig:

• 2.4.7 Fokus sichtbar (Stufe AA): Wer die Seite mit der Tastatur bedient, muss sehen, wo der Fokus gerade steht (W3C, Understanding 2.4.7).
• 1.4.11 Kontrast von Nicht-Text-Elementen (Stufe AA): Knopf und Rahmen müssen sich deutlich vom Hintergrund abheben. Die Regel nennt dafür ein Kontrastverhältnis von mindestens 3:1. Das ist ein Messwert für den Helligkeitsunterschied. Das gilt auch für den Fokus-Rahmen. Ausgenommen sind deaktivierte Knöpfe. Auch der Hover-Effekt muss die 3:1 nicht erreichen. Die Maus zeigt ja selbst, wo man ist (W3C, Understanding 1.4.11). Prüfen kannst du Farben mit meinem Kontrast-Checker.
• 4.1.2 Name, Rolle, Wert (Stufe A): Auch Hilfsprogramme wie Screenreader müssen erkennen können, was ein Element ist und in welchem Zustand es steht. Ändert sich der Zustand, müssen sie davon erfahren (W3C, Understanding 4.1.2).
• 4.1.3 Statusmeldungen (Stufe AA): Eine Meldung wie „Gesendet“ muss so eingebaut sein, dass ein Screenreader sie vorliest, ohne dass der Fokus springt. Das W3C nennt genau das abgeschickte Formular als Beispiel (W3C, Understanding 4.1.3).
• 2.4.11 Fokus nicht verdeckt (Stufe AA, neu in WCAG 2.2): Das fokussierte Element darf nicht vollständig von anderen Inhalten verdeckt sein. Das W3C nennt fixierte Kopf- und Fußbereiche als typische Ursache (W3C, Understanding 2.4.11).

Deutschland und Österreich: In der Praxis gilt für das Barrierefreiheitsstärkungsgesetz (BFSG) in Deutschland und das Barrierefreiheitsgesetz (BaFG) in Österreich heute die Norm EN 301 549 V3.2.1 und damit WCAG 2.1 AA als Maßstab. Die ersten vier Regeln oben sind darin schon enthalten. Damit gelten sie heute für alle, die unter diese Gesetze fallen, etwa Online-Shops für Verbraucher. Die Regel 2.4.11 kam erst mit WCAG 2.2. Die neue Fassung V4.1.1 ist seit September 2026 veröffentlicht und nimmt WCAG 2.2 auf. Verbindlicher Maßstab wird sie, sobald die EU sie im Amtsblatt nennt (Stand: November 2026). Bis dahin ist 2.4.11 empfohlen, aber noch keine Pflicht. Den aktuellen Stand erkläre ich im Beitrag EN 301 549 V4.1.1 ist da.

Schweiz: Konkrete Vorgaben zur digitalen Barrierefreiheit macht das Behindertengleichstellungsgesetz (BehiG) bisher nur dem Bund (Standard eCH-0059). Eine Teilrevision, die auch private Anbieter einbezieht, wird derzeit im Parlament beraten. Wer an Verbraucher in der EU verkauft, kann schon heute unter den European Accessibility Act fallen. Kleinstunternehmen mit Dienstleistungen sind ausgenommen. Mehr dazu in der BehiG-Checkliste für Schweizer Websites.

Wann welcher Zustand sinnvoll ist

Immer: Jeder Knopf braucht einen klaren Normalzustand und einen sichtbaren Fokus. Dazu kommt die Reaktion beim Drücken, egal wie klein die Website ist. Der Fokus ist für die Tastatur Pflicht.

Hover: Er ist eine nette Ergänzung für Maus-Nutzer. Er darf aber nie die einzige Stelle sein, an der eine Information steht. Am Handy fehlt er komplett.

Lädt: Sinnvoll, sobald eine Aktion spürbar dauert. Das ist ungefähr ab einer Sekunde der Fall, etwa beim Absenden eines Formulars. Bei Aktionen, die sofort fertig sind, braucht es keinen Ladezustand. Ein Kreisel, der nur kurz aufblitzt, wirkt eher unruhig.

Deaktiviert: Hier rate ich zur Vorsicht. In Formularen ist es meist besser, den Knopf aktiv zu lassen. Fehlt beim Klick noch etwas, sagt eine klare Fehlermeldung, was. Richtig eingebaut, erreicht sie alle, auch Screenreader-Nutzer. Einen deaktivierten Knopf würde ich nur einsetzen, wenn der Grund direkt daneben steht. Ein Beispiel ist ein Artikel, der gerade ausverkauft ist. Wie gute Fehlermeldungen in Formularen aussehen, steht im Beitrag Barrierefreie Formulare komplett.

Noch ein Punkt, den viele übersehen: Ein Zustand nur über Farbe reicht nicht. Wer Rot und Grün schlecht unterscheiden kann, sieht den Unterschied eventuell nicht. Ergänze darum eine zweite Änderung, etwa eine Unterstreichung oder einen Text wie „Wird gesendet …“.

Checkliste: Button-Zustände auf deiner Website

Hake ab, was auf deiner Website schon passt. Dein Stand bleibt in diesem Browser gespeichert.

1. Knöpfe sehen nach Knopf aus. Öffne eine wichtige Seite, etwa das Kontaktformular. Erkennst du ohne Nachdenken, was man drücken kann?
2. Mit der Maus reagiert der Knopf. Fahr mit der Maus über den Knopf. Ändert sich etwas, zum Beispiel die Farbe oder eine Unterstreichung?
3. Mit der Tastatur ist der Fokus sichtbar. Klick in die Adresszeile und drück mehrmals die Tabulator-Taste. Siehst du bei jedem Knopf einen deutlichen Rahmen, der nicht verdeckt ist?
4. Der Klick wird sofort bestätigt. Drück einen Knopf und schau genau hin. Ändert er sich gleich beim Drücken?
5. Beim Senden steht ein Text im Knopf. Schick das Formular ab. Steht im Knopf oder daneben etwas wie „Wird gesendet …“? Ein zweiter Klick löst keine zweite Anfrage aus.
6. Danach kommt eine klare Meldung. Steht nach dem Absenden in Worten, ob es geklappt hat? Prüf mit dem Screenreader deines Handys, ob die Meldung vorgelesen wird.
7. Ein grauer Knopf sagt, warum er grau ist. Such ausgegraute Knöpfe, etwa im Bestellprozess. Steht direkt daneben, was fehlt?

PDF, 2 Seiten, 28 KB · barrierefrei nach PDF/UA · Kästchen am Bildschirm abhakbar · frei, ohne Anmeldung

Häufige Fragen

Welche Button-Zustände braucht eine Website mindestens?

Jeder Knopf braucht einen klar erkennbaren Normalzustand und einen sichtbaren Fokus für die Tastatur. Dazu kommt eine sofortige Reaktion beim Drücken. Dauert eine Aktion länger als etwa eine Sekunde, braucht es zusätzlich einen Ladezustand mit Text.

Darf ich den Fokus-Rahmen entfernen, weil er nicht ins Design passt?

Nein. Ein sichtbarer Fokus ist nach WCAG 2.4.7 Pflicht und damit Teil der Anforderungen von BFSG und BaFG. Du darfst ihn aber gestalten, etwa in deiner Markenfarbe, solange er genug Kontrast hat. Wie das geht, steht im Beitrag Sichtbarer Fokus.

Ist ein deaktivierter Knopf verboten?

Nein. Die WCAG nimmt deaktivierte Knöpfe sogar von der Kontrastregel aus. Das Problem ist ein anderes: Ohne Begründung weiß niemand, was fehlt. Schreib den Grund direkt daneben. Oder lass den Knopf aktiv und zeig beim Klick eine klare Fehlermeldung.

Reicht ein drehender Kreisel als Ladezustand?

Für sehende Maus-Nutzer oft schon. Ein Screenreader erfährt davon aber nichts, wenn der Kreisel nur ein Bild ist. Besser ist ein Text wie „Wird gesendet …“ im Knopf. Die Meldung danach muss dein Entwickler als Statusmeldung einbauen. Dann liest der Screenreader sie vor.

Wie prüfe ich die Button-Zustände selbst?

Leg die Maus weg und geh die Seite nur mit der Tabulator-Taste durch. Schick ein Formular ab und achte darauf, was der Knopf tut. Am Handy kannst du den eingebauten Screenreader einschalten, also VoiceOver am iPhone oder TalkBack bei Android. Die Checkliste oben führt dich Schritt für Schritt durch.

Du willst wissen, ob die Knöpfe und Formulare auf deiner Website für alle funktionieren? Ich prüfe deine Seite nach WCAG 2.2 AA und gebe dir einen Prüfbericht mit allen Barrieren, nach Priorität sortiert. Die Barrierefreiheits-Prüfung (EAA-Audit) gibt es ab 540 €. Einen ersten Eindruck bekommst du kostenlos mit meinem Barrierefreiheits-Schnellcheck. Alle Teile der Serie findest du auf der Übersichtsseite Mikrointeraktionen.

Quellen

• Gordon, K. (2025): Button States: Communicate Interaction. Nielsen Norman Group
• Saffer, D. (2013): Microinteractions. O’Reilly Media
• Nielsen, J. (1993): Response Times: The 3 Important Limits. Nielsen Norman Group
• Friedman, V. (2021): Frustrating Design Patterns: Disabled Buttons. Smashing Magazine
• MDN Web Docs: aria-disabled
• W3C: Understanding SC 2.4.7 Focus Visible
• W3C: Understanding SC 1.4.11 Non-text Contrast
• W3C: Understanding SC 4.1.2 Name, Role, Value
• W3C: Understanding SC 4.1.3 Status Messages
• W3C: Understanding SC 2.4.11 Focus Not Obscured (Minimum)