Vor einigen Monaten gab es einen längeren kritischen Artikel zur Barrierefreiheit von Disabled Buttons. Tenor war, dass diese Buttons vermieden werden sollten. Um den Artikel zu lesen, muss man ein Medium-Mitglied sein. Wie der alte Groucho Marx möchte ich nicht in einem Club Mitglied sein, das mich als Mitglied aufnehmen würde, deshalb habe ich auf die Lektüre des Beitrags „Never, ever disable buttons — Requirements for an accessible solution“ verzichtet, dafür gibt es auch keinen Link.
Disabled heißt in dem Kontext, dass Buttons zwar im User Interface vorhanden, aber nicht anklickbar sind, visuell sind sie in der Regel ausgegraut und in der Accessibility API werden sie als Element mit der richtigen Rolle, also zum Beispiel „Button“, aber als nicht aktivierbar ausgegeben. NVDA sagt zum Beispiel „nicht verfügbar“.
Rein technisch gibt es mit der Barrierefreiheit kein Problem. Selbst Olles HTML bietet den State Disabled. Das Gegen-Argument lautet dass man erst am Ende eines Formulars feststellt, dass das Formular nicht verschickt werden kann. Allerdings ist meines Erachtens ein gewichtigeres Problem vorhanden, wenn der Button trotz Fehlern aktiviert werden kann. Die Screenreader-Nutzerin merkt erst nach dem Abschicken und dem Neu-Rendern der Seite durch den Screenreader, dass es ein Problem gab, ärgerlich vor allem bei umfangreichen Seiten. Stellen wir uns etwa ein Newsletter-Formular vor, welches relativ am Ende einer Unterseite ist. Auch besteht die Gefahr, dass die Nutzerin bei statischen Formularen gar nicht merkt, dass ein Fehler aufgetreten ist. Wie oft schickt man ein Formular ab und geht nicht noch mal sicher – oder bekommt keine Bestätigung – dass es geklappt hat? Aus meiner Sicht ist das ein Argument für Disabled Buttons und deren Zugänglichkeit.
Etwas anders ist die Situation bei dynamisch validierten Formularen. Hier kann man die Nutzerin bei Klick auf den Button mit einer Meldung auf das Problem hinweisen und den Fokus auf das eventuell falsche Formular-Element legen. Bei Newslettern ist das häufig die Checkbox zum Datenschutz.
Das Problem beginnt hier buchstäblich gesprochen schon früher in schlechtem Formular-Design. Wenn Fehler automatisch festgestellt werden können, müssen die Nutzerinnen spätestens darauf hingewiesen werden, wenn sie das jeweilige Formular-Element verlassen. Ich bin ja generell kein Fan des User-Interfaces der Deutschen Bahn, aber zumindest kriegen sie das gut hin. Sie machen das in dem Interface, in welchem man eine Mobilitätshilfe online anfordern kann.
Verlässt man ein Pflichtfeld ohne oder mit falscher Angabe, wird man sofort darauf hingewiesen. Entscheidend ist also nicht der Disabled Button, sondern ein gutes Fehlermanagement im Formular. Dazu gehört die dynamische Validierung von Eingabenund die korrekte Ausweisung von Pflichtfeldern. Das erreicht man, indem man zum Beispiel „Pflichtfeld“ in das Label schreibt und ARIA required verwendet.
Natürlich wird es immer noch Leute geben, die das Formular falsch ausfüllen. Aber wie oben gesagt kann man das durch ein vernünftiges Fehler-Management reduzieren und dann ist der Button nicht mehr disabled, wenn man ihn erreicht.
Auch spricht nichts dagegen, vor bzw. auf dem Disabled Button Informationen dazu zu geben, warum der Button nicht aktiviert werden kann.