Barrierefreiheit in Security-Werkzeugen: wenn eine Barriere zum operativen Risiko wird

Über Barrierefreiheit spricht man meist bei öffentlichen Websites und Consumer-Apps. Interne Werkzeuge, und Security-Werkzeuge im Besonderen, kommen selten vor.

Das sollten sie. Ich arbeite seit Jahren sowohl an Barrierefreiheit als auch an Cybersecurity, und ich halte die Schnittmenge für unterschätzt.

Eine Security-Konsole ist ein Werkzeug für Entscheidungen unter Druck. Alles, was sie schwerer lesbar, bedienbar oder verständlich macht, ist nicht nur unbequem. Es verlangsamt die Reaktion und erhöht die Fehlerwahrscheinlichkeit.

Wer diese Werkzeuge nutzt

Security- und Betriebsteams sind keine einheitliche Gruppe. Dazu gehören Menschen mit Sehbehinderung, Farbsehschwäche, Legasthenie, motorischen Einschränkungen oder Aufmerksamkeitsbesonderheiten. Dazu gehören Menschen, die spät arbeiten, müde, auf einem Laptop statt an den gewohnten Monitoren, oder mit Bildschirmlupe, weil die Augen angestrengt sind.

Barrierefreiheit betrifft sie alle. Und bei einem Vorfall werden vorübergehende Einschränkungen häufig: Müdigkeit, Stress, ein Telefon statt eines Arbeitsplatzes.

Wo Security-Werkzeuge meist scheitern

Farbe als einziges Signal. Rot, Gelb und Grün für den Schweregrad, ohne Text oder Form. Etwa jeder zwölfte Mann hat eine Form von Farbsehschwäche. Auf einem Status-Dashboard ist das ein echtes Problem.

Wenig Kontrast für „Nebeninformationen“. Graue Zeitstempel, blasse Beschriftungen, kleine Schrift für die Details, die sich bei einer Untersuchung als entscheidend erweisen.

Bedienung nur mit der Maus. Zeitleisten mit Ziehen zum Auswählen, Details nur beim Überfahren, eigene Tabellen, die sich nicht per Tastatur bedienen lassen.

Dichte Tabellen ohne Struktur. Tabellen ohne echte Kopfzellen sind mit Screenreadern unbenutzbar und für alle schwierig, wenn sie groß werden.

Alarme, die wandern oder verschwinden. Hinweise, die nach wenigen Sekunden verschwinden, Listen, die sich selbst aktualisieren und die Zeile verschieben, die man gerade anklicken wollte.

Unklare Sprache. Fehlermeldungen und Alarme, geschrieben für den Entwickler, der sie angelegt hat, nicht für die Person, die handeln muss.

Wo man anfängt

Für Fortschritte braucht es kein vollständiges Audit. Beginnen Sie mit den Bildschirmen, die bei einem Vorfall genutzt werden.

1. Nie nur Farbe. Ergänzen Sie jeden Status um eine Beschriftung oder ein Symbol. Diese eine Änderung hilft allen.
2. Kontrast prüfen bei Texten und Statusanzeigen gemäß WCAG AA, Nebentexte eingeschlossen.
3. Den Tastaturtest machen. Können Sie einen Alarm sichten, seine Details öffnen und handeln, ohne Maus? Ist der Fokus immer sichtbar?
4. Die Tabellen reparieren. Echte Kopfzellen, sortierbare Spalten, die assistiven Technologien angekündigt werden, und Filter statt endlosem Scrollen.
5. Zeitkontrolle den Nutzern geben. Alarme bleiben, bis sie geschlossen werden; automatische Aktualisierung lässt sich pausieren.
6. Die Meldungen neu schreiben. Was ist passiert, was betrifft es, was ist zu tun.

Die WCAG-2.2-Kriterien zu Fokussichtbarkeit und Zielgröße sind eine gute praktische Checkliste; ich habe sie in WCAG 2.2: was sich ändert zusammengefasst.

Das wirtschaftliche Argument

Barrierefreie Werkzeuge sind schneller erlernbar, verursachen weniger Fehler und funktionieren für einen größeren Talentpool, in einem Feld, dem chronisch Menschen fehlen. Und mit dem European Accessibility Act, der seit Juni 2025 gilt, wird Barrierefreiheit für viele digitale Produkte und Dienste zur Grunderwartung.

Das stärkste Argument ist aber das operative. In der Sicherheit kostet ein falsch gelesener Bildschirm keinen verlorenen Klick. Er kostet einen übersehenen Vorfall.