Deaktivierte Buttons und Barrierefreiheit
Aktualisiert am 14. Oktober 2026 · Lesezeit: 6 Min.
Das ausgegraute „In den Warenkorb“, bis eine Größe gewählt ist, der Button „Kostenpflichtig bestellen“, der deaktiviert bleibt, bis jedes Feld ausgefüllt ist – deaktivierte Buttons gibt es in Online-Shops überall. Die WCAG haben dafür eine eigene Ausnahme, aber das macht sie nicht in jedem Fall zu einer guten Idee. Diese Seite behandelt die Regeln, die beiden Wege, einen Button zu deaktivieren, und bessere Alternativen. Sie gehört zur Reihe barrierefreie UI-Muster.
Was die WCAG sagen
- Kontrastausnahme. 1.4.3 Kontrast (Minimum) nimmt „Text oder Bilder von Text, die Teil eines inaktiven Bedienelements der Benutzerschnittstelle sind“ aus, und 1.4.11 Nicht-Text-Kontrast nimmt inaktive Komponenten ebenfalls aus. Das W3C definiert eine inaktive Komponente als eine, die „sichtbar, aber derzeit nicht bedienbar ist“, und nennt einen deaktivierten Absende-Button als Beispiel. Das Understanding-Dokument erklärt, die Ausnahme bestehe, weil noch kein einzelner guter Weg gefunden wurde, deaktivierte Bedienelemente darzustellen.
- Name, Rolle, Zustand. 4.1.2 Name, Rolle, Wert: Der Zustand „deaktiviert“ muss im Code bereitgestellt werden, nicht nur durch graue Farbe.
- Anweisungen. 3.3.2 Beschriftungen oder Anweisungen: Muss der Nutzer etwas tun, bevor ein Button funktioniert, sagen Sie es.
- Fehler. 3.3.1 Fehlererkennung: Ein deaktivierter Absende-Button ist keine Fehlermeldung. Der Nutzer muss weiterhin in Textform erfahren, was falsch ist.
Geringer Kontrast bei einem deaktivierten Button verstößt also nicht gegen die WCAG – aber ein deaktivierter Button, den niemand versteht, kann trotzdem gegen die genannten Kriterien verstoßen und kostet ganz sicher Umsatz.
disabled oder aria-disabled
Attribut disabled |
aria-disabled="true" |
|
|---|---|---|
| Funktioniert bei | Nativen Formularelementen: button, input, select, textarea, fieldset |
Jedem Element mit interaktiver Rolle |
| Kann aktiviert werden | Nein, der Browser blockiert es | Ja – Ihr Skript muss die Aktion ignorieren |
| In der Tab-Reihenfolge | Nein | Ja |
| Screenreader sagt „nicht verfügbar“/„abgeblendet“ an | Ja | Ja |
Der APG-Leitfaden zur Tastaturbedienung sagt: „Browser entfernen HTML-Eingabeelemente mit dem Attribut disabled aus der Tab-Reihenfolge.“ Wo Nutzer ein deaktiviertes Element entdecken müssen – das APG nennt Menüeinträge, Tabs, Listbox-Optionen und Baumeinträge –, verwendet es aria-disabled="true", damit das Element fokussierbar bleibt. Das APG-Muster für Buttons sagt außerdem: Ist die Aktion eines Buttons nicht verfügbar, „hat der Button aria-disabled mit dem Wert true“.
Die praktische Regel: Verwenden Sie disabled, wenn es nicht stört, dass der Button übersprungen wird; verwenden Sie aria-disabled, wenn Nutzer den Button finden und erfahren müssen, warum er nicht funktioniert.
Codebeispiel
<!-- Discoverable: stays in the tab order, the reason is announced -->
<p id="size-hint">Wählen Sie eine Größe, um den Artikel in den Warenkorb zu legen.</p>
<button type="button" id="add" aria-disabled="true" aria-describedby="size-hint">
In den Warenkorb
</button>
<script>
const add = document.getElementById('add');
add.addEventListener('click', (event) => {
if (add.getAttribute('aria-disabled') === 'true') {
event.preventDefault(); // block the action yourself
document.getElementById('size').focus();
return;
}
addToCart();
});
// When a size is selected: add.setAttribute('aria-disabled', 'false');
</script>
<!-- Fine to skip: a native disabled control the user does not need to reach -->
<button type="button" disabled>Vorherige Seite</button>
Gestalten Sie [aria-disabled="true"] so, dass es nicht verfügbar aussieht – der Browser tut das nicht für Sie.
Bessere Alternativen
- Lassen Sie „Kostenpflichtig bestellen“ aktiv. Wird er mit fehlenden Daten gedrückt, zeigen Sie Fehlermeldungen als Text und setzen den Fokus auf den ersten Fehler oder eine Fehlerübersicht. Siehe Formularvalidierung und Fehlermeldungen.
- Sagen Sie, was nötig ist, neben einem deaktivierten Button, in sichtbarem Text, nicht in einem Tooltip beim Darüberfahren.
- Verbergen Sie eine nicht verfügbare Option nicht ohne Erklärung – eine ausverkaufte Größe kann in der Liste bleiben, gekennzeichnet als „ausverkauft“.
Tastaturbedienung
| Taste | Button mit disabled |
Button mit aria-disabled |
|---|---|---|
| Tab | Überspringt den Button | Setzt den Fokus darauf; der Screenreader sagt, dass er nicht verfügbar ist, und liest die Beschreibung vor |
| Enter / Leertaste | Nichts | Nichts passiert – oder das Skript setzt den Fokus auf das, was fehlt |
Typische Fehler in Online-Shops
- „In den Warenkorb“ deaktiviert, bis eine Variante gewählt ist, ohne sichtbaren Hinweis. Tastaturnutzer erreichen den Button nie und wissen nicht, warum.
- Der Button „Bezahlen“ im Checkout ist deaktiviert, bis alle Felder die Validierung bestehen, während die Felder keine Fehlermeldungen zeigen.
- Ein Button, der deaktiviert aussieht, es aber nicht ist (nur graue Gestaltung), oder einer, der im Code deaktiviert ist, aber aktiv aussieht.
aria-disabled="true"ohne Absicherung im Skript, sodass der Button trotzdem absendet.- Der deaktivierte Zustand wird nur durch geringere Deckkraft gezeigt, während der Grund in einem
title-Tooltip steht. - Unlesbar heller deaktivierter Text bei wichtigen Informationen wie „Nicht auf Lager“. Der Text mag vom Kontrast ausgenommen sein, aber die Information sollte auch in lesbarem Text verfügbar sein.
Was automatische Prüfungen finden und was manuell zu testen ist
| Automatisch (axe-core-Regel) | Was sie findet |
|---|---|
color-contrast |
Text mit geringem Kontrast; deaktivierte Bedienelemente werden übersprungen, wie es die WCAG-Ausnahme vorsieht |
button-name |
Buttons ohne Namen, deaktiviert oder nicht |
aria-valid-attr-value |
aria-disabled mit ungültigem Wert, aria-describedby mit Verweis auf eine fehlende ID |
aria-allowed-attr |
ARIA-Attribute, die für die Rolle des Elements nicht erlaubt sind |
Alle sind Karten in unserer Regelbibliothek. Manuelle Tests: Versuchen Sie, das Formular oder die Produktauswahl nur mit der Tastatur abzuschließen, prüfen Sie, dass jedes deaktivierte Bedienelement einen sichtbaren Grund hat, und prüfen Sie mit einem Screenreader, dass der Zustand und der Grund angesagt werden. Der Kontrast-Checker hilft, einen Stil für den deaktivierten Zustand zu wählen, der lesbar bleibt.
Starten Sie die kostenlose Prüfung einer Seite. Sie ist eine automatische Prüfung, kein vollständiges Audit.
Häufige Fragen
Müssen deaktivierte Buttons die Kontrastanforderungen der WCAG erfüllen?
Nein. Sowohl 1.4.3 Kontrast (Minimum) als auch 1.4.11 Nicht-Text-Kontrast nehmen inaktive Bedienelemente aus, die das W3C als sichtbar, aber derzeit nicht bedienbar definiert. Ein deaktivierter Absende-Button ist das Beispiel, das das W3C nennt.
Was ist der Unterschied zwischen disabled und aria-disabled?
Das HTML-Attribut disabled macht ein natives Bedienelement unbedienbar und nimmt es aus der Tab-Reihenfolge. aria-disabled="true" teilt assistiven Technologien nur mit, dass das Element nicht verfügbar ist; es bleibt fokussierbar, und Sie müssen die Aktion in Ihrem Skript selbst blockieren.
Ist es schlecht, den Absende-Button zu deaktivieren, bis das Formular gültig ist?
Es verursacht oft Probleme: Nutzer erfahren nicht, was fehlt, und Tastaturnutzer erreichen den Button gar nicht erst. Meist ist es besser, ihn aktiv zu lassen und beim Absenden klare Fehlermeldungen zu zeigen.
Wie erkläre ich, warum ein Button deaktiviert ist?
Schreiben Sie den Grund in sichtbaren Text in der Nähe des Buttons, zum Beispiel „Wählen Sie eine Größe, um den Artikel in den Warenkorb zu legen“, und verbinden Sie ihn per aria-describedby. Verlassen Sie sich nicht auf einen Tooltip beim Darüberfahren.
Kann eine automatische Prüfung deaktivierte Buttons testen?
Kontrastprüfungen überspringen deaktivierte Bedienelemente, wie es auch die WCAG tun. Automatische Regeln prüfen, ob aria-disabled einen gültigen Wert hat und Buttons einen Namen haben. Ob Nutzer verstehen, warum ein Button nicht verfügbar ist, muss manuell getestet werden.
Quellen
- W3C, Understanding 1.4.3 Contrast (Minimum): https://www.w3.org/WAI/WCAG22/Understanding/contrast-minimum.html
- W3C, Understanding 1.4.11 Non-text Contrast: https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html
- W3C WAI, APG Developing a Keyboard Interface (focusability of disabled controls): https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/
- W3C WAI, APG Button pattern: https://www.w3.org/WAI/ARIA/apg/patterns/button/