UX & Softwareergonomie
Tastaturzugänglichkeit ist mehr als die Frage, ob mit der Tab-Taste irgendein Element erreicht werden kann. Für eine belastbare technische Prüfung werden Bedienbarkeit, Fokusreihenfolge, sichtbarer Fokus, dynamische Fokuswechsel und die semantische Kommunikation von Rolle, Name und Zustand zusammen untersucht.
Kurzantwort
Die Prüfung folgt einem definierten Bedienpfad ausschließlich mit Tastatur und erfasst zugleich DOM- beziehungsweise Accessibility-Semantik. Ein Element gilt nicht allein deshalb als zugänglich, weil es fokussierbar ist: Aktion, Fokusbewegung, sichtbarer Zustand und semantische Information müssen zusammenpassen.
Vom abgegrenzten Nutzungsszenario zur nachvollziehbaren fachlichen Aussage
1. Prüfbereich und konkrete Bedienpfade festlegen
Eine Tastaturprüfung beginnt nicht mit wahllosem Tabben durch eine Seite, sondern mit relevanten Aufgaben. Für jede Aufgabe wird festgelegt, welche interaktiven Elemente erreicht und ausgelöst werden müssen, welche Browser- beziehungsweise Plattformumgebung vorliegt und welcher Produktstand untersucht wird.
Bei Webanwendungen ist außerdem zu unterscheiden, ob native HTML-Elemente oder individuell implementierte Widgets verwendet werden. Native Elemente bringen typischerweise browserseitiges Tastaturverhalten mit; bei ARIA-basierten Komponenten muss die erforderliche Bedienlogik häufig ausdrücklich implementiert werden. Die Prüfdokumentation hält diese technische Ausgangslage fest.
2. Tastaturbedienbarkeit und Reihenfolge praktisch reproduzieren
Für den Bedienpfad wird geprüft, ob alle notwendigen Funktionen ohne Maus oder Touch erreichbar und auslösbar sind. Dabei gehören Tab und Shift+Tab zur Navigation zwischen Komponenten, während komplexe Widgets zusätzliche, musterspezifische Tasten verwenden können. Die WAI-ARIA Authoring Practices beschreiben hierfür verbreitete Konventionen.
Eine bloß erreichbare Komponente genügt nicht, wenn die Reihenfolge unlogisch ist oder der Tastaturpfad zentrale Elemente überspringt. Ebenso problematisch sind positive tabindex-Werte, die eine künstliche Reihenfolge erzeugen und von der Dokumentstruktur abweichen können. Beobachtet werden daher Fokusfolge, Lesereihenfolge und tatsächliche Bedienbarkeit gemeinsam.
3. Sichtbaren Fokus und verdeckte Fokusziele prüfen
Nutzende müssen erkennen können, welches Element gerade den Tastaturfokus trägt. Deshalb wird dokumentiert, ob ein sichtbarer Fokusindikator vorhanden ist, ob er sich ausreichend vom umgebenden Zustand unterscheidet und ob er durch Overlays, Sticky-Elemente oder Scrollpositionen verdeckt wird.
WCAG 2.2 enthält sowohl Focus Visible als auch Focus Not Obscured als relevante Erfolgskriterien. Für die technische Begutachtung wird nicht nur ein statischer Screenshot betrachtet, sondern der Fokuspfad tatsächlich durchlaufen. Dabei können sich Probleme zeigen, die erst nach Scrollen, Öffnen eines Dialogs oder Einblenden dynamischer Inhalte entstehen.
4. Rolle, Name und Zustand semantisch nachvollziehen
Visuelle Darstellung und zugängliche Semantik können voneinander abweichen. Ein Element kann wie ein Button aussehen, technisch aber keine geeignete Rolle, keinen zugänglichen Namen oder einen nicht aktualisierten Zustand besitzen. Die Prüfung betrachtet deshalb DOM- und Accessibility-Informationen gemeinsam mit dem beobachtbaren Verhalten.
Bei dynamischen Komponenten sind Zustände wie ausgewählt, erweitert, deaktiviert oder ungültig relevant. Werden ARIA-Rollen und -Eigenschaften eingesetzt, müssen sie mit der tatsächlichen Interaktion übereinstimmen. Zusätzliche ARIA-Attribute verbessern eine Komponente nicht, wenn Tastaturverhalten oder Zustandslogik weiterhin fehlerhaft sind.
5. Dynamische Fokuswechsel und Fokusverlust untersuchen
Dialoge, Menüs, entfernte Listenelemente oder asynchron aktualisierte Bereiche können den Fokus verlagern. Wird ein fokussiertes Element aus dem DOM entfernt, ohne einen sinnvollen neuen Fokus zu setzen, kann die Orientierung verloren gehen. Nach dem Schließen eines Dialogs kann beispielsweise die Rückkehr zum auslösenden Element erforderlich sein.
Die WAI-ARIA Authoring Practices betonen sichtbaren und vorhersehbaren Fokus sowie konsistente Fokusbewegung. In der Untersuchung werden deshalb Eröffnung, Bedienung und Schließen dynamischer Komponenten als vollständige Sequenz geprüft. Ein korrekter Ausgangszustand reicht nicht aus, wenn der Fokus während der Interaktion verschwindet oder unerwartet springt.
6. Aussage auf Plattform, Komponenten und Prüfscope begrenzen
WCAG- und WAI-ARIA-Bezüge sind insbesondere für Webinhalte und Webanwendungen relevant. Für native Desktop- oder Mobile-Anwendungen können andere Plattformmechanismen und technische Standards maßgeblich sein. Der Bericht nennt deshalb ausdrücklich, welche Technologie, Browser- oder Betriebssystemumgebung und welche Komponenten untersucht wurden.
Auch eine bestandene Tastatur- und Fokusprüfung ist keine vollständige Barrierefreiheitsaussage. Wahrnehmbarkeit, Inhalte, Kontraste, Alternativtexte, Sprache, Zoomverhalten und weitere Kriterien können außerhalb des gewählten Prüfscope liegen. Die Schlussfolgerung bleibt auf die tatsächlich geprüften Bedienpfade und semantischen Zustände begrenzt.
Reicht es aus, wenn jedes Bedienelement mit Tab erreicht werden kann?
Nein. Erreichbarkeit ist nur ein Teil der Untersuchung.
Der Fokus muss sinnvoll geführt und sichtbar sein, die Aktion muss mit Tastatur tatsächlich ausführbar bleiben und Rolle, Name sowie Zustände müssen zur Komponente passen.
Bei komplexen Widgets können außerdem etablierte komponentenspezifische Tastaturmuster erforderlich sein.
Ist die Untersuchung für diesen Themenbereich technisch und methodisch nachvollziehbar?
- Sind die relevanten Aufgaben und der untersuchte Browser-, Geräte- oder Plattformstand festgelegt?
- Lassen sich alle für die Aufgabe notwendigen Aktionen ohne Zeigegerät erreichen und ausführen?
- Ist die Fokusreihenfolge logisch und mit Dokument- beziehungsweise Lesereihenfolge vereinbar?
- Bleibt der Tastaturfokus sichtbar und wird er nicht durch überlagernde Inhalte verdeckt?
- Stimmen zugänglicher Name, Rolle und semantischer Zustand mit Darstellung und Funktion überein?
- Wird Fokus bei Dialogen, dynamischen Updates und entfernten Komponenten vorhersehbar weitergeführt?
- Begrenzt der Befund seine Aussage auf die tatsächlich geprüften Komponenten und Bedienpfade?
Konstruiertes Beispiel
Ein benutzerdefiniertes Auswahlmenü lässt sich mit Tab fokussieren und per Enter öffnen. Nach dem Öffnen können die Optionen jedoch nur mit der Maus gewählt werden; zusätzlich bleibt der sichtbare Fokus auf dem auslösenden Element, während ein Screenreader keinen ausgewählten Zustand erhält. Die Untersuchung dokumentiert getrennt Tastaturpfad, Fokusführung und semantischen Zustand.
Das Beispiel ist konstruiert und beschreibt kein reales Mandat.
Quellen und fachliche Grundlage
- WCAG 2.2 W3C – Web Content Accessibility Guidelines (WCAG) 2.2 als normativer Referenzrahmen für Webinhalte. Quelle öffnen.
- WAI-ARIA Praxis W3C WAI – Developing a Keyboard Interface im ARIA Authoring Practices Guide. Quelle öffnen.
- Fokus W3C WAI – Understanding Success Criterion 2.4.7 Focus Visible. Quelle öffnen.
- Eigene Methodik Quellen und Methodik der Wissensplattform. Quelle öffnen.
Weiterführende Beiträge
- Barrierefreiheit technisch prüfen
- Fehlerzustände, Rückmeldungen und Benutzerkontrolle untersuchen
- Alle Beiträge in diesem Themenbereich
Eigene Fachliteratur und Veröffentlichungen
Die folgenden eigenen Arbeiten dienen der fachlichen Vertiefung und methodischen Einordnung. Sie ersetzen keine erforderlichen Primär-, Norm-, Hersteller- oder sonstigen unabhängigen Fachquellen. Unveröffentlichte Manuskripte, Entwürfe und Lehrunterlagen werden hier bewusst nicht als öffentliche Quellen ausgewiesen.
Technische Untersuchung zu UX, Softwareergonomie und Barrierefreiheit
Die konkrete Aussagekraft hängt vom Nutzungskontext, dem Systemstand, den Prüfkriterien und der dokumentierten Evidenz ab.
UX- & Barrierefreiheitsprüfung ansehen