Woher der deaktivierte Button seine Regel hat

Das Blog hipuku hat am 12. November 2026 zurückverfolgt, woher die Regel stammt, dass sich ein ausgegrauter Befehl nicht wählen lässt: aus den Menüs von Apples Lisa, nicht aus Formularen.^[1] Alle acht verglichenen Designsysteme führen den deaktivierten Button, seine Beschriftung erreicht laut Messung des Autors nur 1,36:1 bis 3,35:1 Kontrast.^[1]

Bemerkenswert daran: Die Lisa-Regel von 1980 ließ den abgedunkelten Befehl noch zu, erst das Handbuch von 1983 machte ihn unwählbar.^[1] Heute steht die Frage wieder offen: Zwei der acht Systeme bieten inzwischen einen Zustand, der erreichbar bleibt.

Woher stammt die Regel für ausgegraute Befehle?

Aus Menüs: Der interne Lisa-Standard von 1980 erlaubte das Abdunkeln wirkungsloser Befehle. Als „nicht wählbar“ steht die Regel erst im Handbuch von 1983.

Nach Angaben von hipuku erlaubt Abschnitt 26 des Lisa-Standards vom 20. September 1980, unterzeichnet von Bill Atkinson, ausdrücklich, einen abgedunkelten Befehl trotzdem aufzurufen.^[1] Im Lisa-Handbuch von 1983 heißt es dagegen, ein dunkler Menüpunkt lasse sich nicht wählen.^[1] Warum sich die Regel änderte, dokumentiert laut dem Autor kein erhaltenes Lisa-Dokument.

Den Weg zum Button beschreibt der Autor über Apples „Inside Macintosh“ von 1985 und HTML 4 von 1997.^[1] Die HTML-4-Spezifikation nennt drei Folgen von disabled: Das Element erhält keinen Fokus, die Tabulatortaste überspringt es, und sein Wert wird beim Absenden nicht übertragen.^[2]

Zwei Systeme fallen aus der Reihe: Polaris rendert laut hipuku statt disabled ein aria-disabled samt tabindex="-1", bleibt also ebenfalls per Tab unerreichbar.^[1] Die übrigen sieben setzen auf das native Attribut.

Warum sollten deaktivierte Buttons erreichbar bleiben?

Weil ein nicht fokussierbarer Button für Screenreader-Nutzer unsichtbar bleibt. aria-disabled hält ihn auffindbar, verlangt aber eigenen Code gegen Klicks.

Der Barrierefreiheits-Leitfaden des W3C hält fest, dass Screenreader-Nutzer nicht fokussierbare, deaktivierte Elemente deutlich seltener entdecken, weil sie sich vor allem über den Fokus orientieren.^[6] Das native disabled reicht deshalb nur, wenn der Zustand aus dem Umfeld klar wird, etwa bei „Zurück“ auf der ersten Tabellenseite.

Die Kehrseite: Ein Button mit aria-disabled bleibt klickbar, der Entwickler muss den Klick selbst abfangen und den Grund dort platzieren, wo ihn der Screenreader vorliest. Material führt dafür softDisabled, Primer inactive; beide bleiben fokussierbar und können ihren Grund nennen.^[1]

Atlassian rät, Buttons in Formularen möglichst nicht zu deaktivieren, sondern klickbar zu lassen und Fehlermeldungen zu zeigen; Tooltips an deaktivierten Buttons lehnt es ab.^[4] GOV.UK empfiehlt, sie zu vermeiden, solange Untersuchungen keinen Nutzen belegen.^[5] WCAG nimmt Text inaktiver Bedienelemente vom Kontrastgebot aus, nennt dafür aber ausdrücklich den Absenden-Button mit unvollständigem Formular.^[3]

Was bedeutet das für Ihre Formulare?

Lassen Sie den Absenden-Button klickbar und zeigen Sie nach dem Klick, was fehlt. Bleibt ein ausgegrauter Zustand, gehört die Begründung sichtbar neben den Button.

Prüfen Sie zuerst, welchen Stil Ihr Theme oder Designsystem für den deaktivierten Zustand mitbringt, auch bei shadcn/ui. Wie häufig Barrierefreiheitsfehler in Shops sind, zeigt eine Studie zu Produktseiten, und worauf es bei deaktivierten Buttons ankommt, haben wir im August beschrieben.

Quellen

Mehr Newshunger?

• Lassen Sie Nutzer klicken: Deaktivierte Buttons schaden der Bedienung
• Barrierefreiheit im Onlinehandel: 64 % der Produktseiten haben kritische Fehler
• Ein Designsystem ist, was es tut: Ex-USWDS-Entwickler warnt vor shadcn/ui für Behörden
• Der „Disability Dongle“: Ein blinder Autor fordert sauberen Code statt teurer Prototypen
• Für Design-Systeme gibt es keinen besseren Namen
• Designsysteme sollten von Haus aus schnell sein: Den Odell misst zehn Bibliotheken