WCAG 2.1 - 2.1.2
No Keyboard Trap
Wenn der Tastaturfokus auf ein Element der Seite mithilfe einer Tastaturschnittstelle verschoben werden kann, dann kann der Fokus auch von diesem Element nur mit einer Tastaturschnittstelle entfernt werden. Wenn es mehr als unmodifizierte Pfeil- oder Tabulatortasten oder andere standardmäßige Ausstiegsmethoden erfordert, wird der Benutzer über die Methode zum Verschieben des Fokus informiert.
Inhalt
Was steht in den Guidelines zum Success Criterium 2.1.2 - No Keyboard Trap?Was Bedeutet das Success Criterium 2.1.2 - No Keyboard Trap?Warum ist es so wichtig, das Success Criterium 2.1.2 - No Keyboard Trap zu beachten?Was hat das Success Criterium 2.1.2 - No Keyboard Trap mit dem BFSG zu tun?Lösungen für 2.1.2 - No Keyboard Trap anhand von CodebeispielenWie löse ich Verstöße gegen das Success Criterium 2.1.2 - No Keyboard Trap?Was steht in den Guidelines zum Success Criterium 2.1.2 - No Keyboard Trap?
Was Bedeutet das Success Criterium 2.1.2 - No Keyboard Trap?
Das Success Criterion 2.1.2 verlangt, dass Nutzer*innen, die nur eine Tastatur (Keyboard) zur Bedienung der Website verwenden, zu keiner Zeit in einem bestimmten Bereich der Seite „gefangen“ (eng. „trapped“) sein dürfen. Wenn z.B. ein Dialogfenster, Formularfeld oder Menü mit der Tastatur aufgerufen wird, muss es jederzeit möglich sein, dieses Element auch wieder zu verlassen und zur normalen Seitenbedienung zurückzukehren – ohne eine Maus oder spezielle Tastenkombination zu benötigen, die nicht dokumentiert ist.
Konkret: Es darf keine Stelle auf der Website geben, wo man mit der Tabulator-Taste oder anderen Standard-Tasten nicht mehr weiterkommt oder aus einem Bereich nicht mehr herausnavigieren kann.
Typische Beispiele
- Ein Modal-Dialog, aus dem ich nur per Maus und nicht per Tab oder ESC-Taste herauskomme.
- Eingabefelder oder Inhaltsbereiche (z.B. iFrames), in denen die Tabulator-Taste nicht mehr weiterführt oder "verschluckt" wird.
Technische Anforderungen
- Nutzer*innen müssen mit der Tastatur jedes interaktive Element erreichen und jederzeit den Fokus weiterbewegen oder verlassen können.
- Sollte ein Bereich den Tastaturfokus einfangen (z.B. ein Dialog), muss klar kommuniziert und technisch ermöglicht werden, wie man diesen Bereich wieder verlässt (z.B. mit ESC oder Tab zurück auf die Seite).
Warum ist es so wichtig, das Success Criterium 2.1.2 - No Keyboard Trap zu beachten?
Viele Menschen mit Behinderungen bedienen das Web ausschließlich mit der Tastatur (z. B. blinde Nutzer*innen mit Screenreader oder Menschen mit motorischen Einschränkungen, die keine Maus nutzen können). Wird an irgendeiner Stelle auf einer Seite der Tastaturfluss unterbrochen und kann der Bereich nicht wieder verlassen werden, kann die Seite nicht mehr sinnvoll genutzt werden. Dies führt zu Frustration und im schlimmsten Fall zum vollständigen Nutzungsausschluss.
Was hat das Success Criterium 2.1.2 - No Keyboard Trap mit dem BFSG zu tun?
Im Rahmen des Barrierefreiheitsstärkungsgesetzes (BFSG) ist die Einhaltung der WCAG-Kriterien, insbesondere der Tastaturbedienbarkeit, verpflichtend. Der Gesetzgeber verlangt, dass digitale Angebote für alle Menschen, auch ohne Mausbedienung, vollständig nutzbar sind. Ein "Keyboard Trap" kann dazu führen, dass Betroffene wichtige Funktionen wie Navigation, Formulare oder Dialoge nicht erreichen oder verlassen können. Eine solche Website ist nicht barrierefrei und damit nicht konform zum BFSG.
Lösungen für 2.1.2 - No Keyboard Trap anhand von Codebeispielen
Falscher Code
<div tabindex="0" onkeydown="if(event.key === 'Tab'){event.preventDefault();}">
<p>Hier kommt man mit der Tab-Taste nicht mehr raus!</p>
</div>Korrekter Code
<div tabindex="0">
<p>Hier ist die Tabulator-Navigation wie gewohnt möglich.</p>
</div>Im schlechten Beispiel wird das Tab-Verhalten per JavaScript unterdrückt (event.preventDefault()), so dass Nutzer*innen in diesem Bereich gefangen sind. Das gute Beispiel lässt die Tab-Navigation zu und verhindert so keinen Fokuswechsel.
Falscher Code
<button onclick="openModal()">Details ansehen</button>
<!-- Das Modal kann nur mit der Maus geschlossen werden -->
<div id="modal" style="display: none;">
<p>Wichtige Informationen</p>
<button onclick="closeModal()">Schließen</button>
</div>Korrekter Code
<button onclick="openModal()" aria-haspopup="dialog">Details ansehen</button>
<!-- Dialog ist per Tab und ESC schließbar -->
<div id="modal" role="dialog" aria-modal="true" tabindex="-1" style="display: none;">
<p>Wichtige Informationen</p>
<button onclick="closeModal()">Schließen</button>
</div>
<script>
// Fokus ins Modal setzen und ESC schließt es:
document.getElementById('modal').addEventListener('keydown', function(e) {
if (e.key === 'Escape') closeModal();
});
</script>Im schlechten Beispiel kann das Modal nur mit der Maus geschlossen werden; es gibt keine Möglichkeit für Tastaturnutzer*innen, es zu verlassen. Im guten Beispiel wird durch die Rolle 'dialog', das Attribut 'aria-modal' und die Möglichkeit, das Modal mit der ESC-Taste zu schließen, sichergestellt, dass niemand gefangen bleibt.
Wie löse ich Verstöße gegen das Success Criterium 2.1.2 - No Keyboard Trap?
Unser Accessibility Audit bietet Ihnen die Möglichkeit, mittels unseres AI-basierten Barrierefreiheits-Assistenten, vollautomatisch konkrete Lösungsvorschläge für Ihre Seite zu erstellen. Dafür scannen wir Ihre Website und ihren Quellcode, finden Problemstellen und zeigen Ihnen anhand Ihres eigenen Websitecode fertige Lösungen zum Kopieren und Einfügen. Starten Sie jetzt den Accessibility Audit kostenlos.