WCAG 2.1.2: Keine Tastaturfalle

WCAG 2.1.2 verlangt, dass Tastaturnutzende niemals in einer Komponente gefangen sind – wenn der Fokus mithilfe der Tastatur in ein UI-Element verschoben werden kann, muss es auch möglich sein, den Fokus ausschließlich mit der Tastatur wieder daraus zu entfernen. Dieses Kriterium ist entscheidend für Nutzende, die sich ausschließlich auf die Tastaturnavigation verlassen, einschließlich Menschen mit motorischen Beeinträchtigungen und Screenreader-Nutzenden.

Was diese Regel bedeutet

WCAG 2.1.2 — Keine Tastaturfalle — ist ein Erfolgskriterium der Stufe A unter dem Prinzip „Bedienbar“. Es lautet: „Wenn der Tastaturfokus mit einer Tastaturschnittstelle auf eine Komponente der Seite verschoben werden kann, dann kann der Fokus mit einer Tastaturschnittstelle auch wieder von dieser Komponente weg verschoben werden, und wenn es mehr als unveränderte Pfeiltasten oder Tabulatortasten erfordert, um den Fokus zu verschieben, wird der Benutzer über die Methode zum Verschieben des Fokus informiert.“

Praktisch bedeutet dies, dass jede interaktive Komponente auf einer Webseite, in die ein Tastaturnutzer per Tab gelangen kann, dem Nutzer auch erlauben muss, sie wieder per Tab zu verlassen. Eine Tastaturfalle tritt auf, wenn ein Nutzer in ein Widget, einen Dialog, ein benutzerdefiniertes Formularelement, einen eingebetteten Mediaplayer oder einen anderen fokussierbaren Bereich navigiert und diesen dann mit den üblichen Tastaturbefehlen nicht mehr verlassen kann — er ist faktisch gefangen.

Das Kriterium umfasst alle HTML-Elemente, die Tastaturfokus erhalten können: native interaktive Elemente wie <input>, <select>, <textarea>, <button> und <a>-Tags sowie benutzerdefinierte Widgets, die über tabindex, ARIA-Rollen oder JavaScript-Fokusverwaltung Fokus erhalten. Es gilt gleichermaßen für eingebettete Komponenten von Drittanbietern wie Chat-Widgets, Videoplayer, Karten-Einbettungen, Datumswähler und Rich-Text-Editoren.

Eine Komponente besteht dieses Kriterium, wenn ein Tastaturnutzer den Fokus jederzeit mit Standardtasten — typischerweise Tab, Shift+Tab, Escape oder Pfeiltasten — von ihr weg bewegen kann oder wenn die Seite die Nutzer klar über einen nicht standardmäßigen Tastaturmechanismus informiert, um den Fokus zu verschieben. Eine Komponente verfehlt das Kriterium, wenn der Fokus in ihr eingeschlossen wird, ohne dass es einen per Tastatur zugänglichen Ausweg gibt, oder wenn der einzige Mechanismus zum Verlassen einen Mausklick, eine Touch-Geste oder eine andere nicht tastaturbasierte Eingabe erfordert.

WCAG sieht eine enge Ausnahme vor: Es ist zulässig, den Tastaturfokus vorübergehend innerhalb einer Komponente zu begrenzen, wenn dies Teil eines bewussten und barrierefreien Designmusters ist — insbesondere bei einem modalen Dialog. Ein modaler Dialog sollte den Fokus innerhalb des Dialogs halten, solange er geöffnet ist (um zu verhindern, dass Nutzer mit verdeckten Hintergrundinhalten interagieren), muss aber stets eine tastaturzugängliche Möglichkeit bieten, den Dialog zu schließen und den Fokus freizugeben — etwa über eine Escape-Taste oder eine klar beschriftete Schließen-Schaltfläche, die per Tab erreichbar ist. Diese Art von absichtlicher, aber entkommbarer Fokusbegrenzung ist keine Tastaturfalle; sie ist eine korrekte Implementierung des modalen Dialogmusters. Zur Falle wird sie erst, wenn der Nutzer überhaupt nicht entkommen kann.

Warum es wichtig ist

Tastaturfallen gehören zu den gravierendsten Barrierefreiheitsfehlern, die eine Website haben kann. Anders als viele andere Barrieren, die die Nutzung für bestimmte Nutzergruppen lediglich erschweren, kann eine Tastaturfalle einen Nutzer vollständig daran hindern, eine Seite weiter zu verwenden. Sie ist im Grunde das Äquivalent dazu, ein physisches Hindernis in einen Flur zu stellen, ohne einen Weg daran vorbei zu bieten.

Am stärksten betroffen sind Nutzer mit motorischen oder körperlichen Beeinträchtigungen, die keine Maus bedienen können und vollständig auf Tastaturnavigation angewiesen sind. Dazu gehören Menschen mit Erkrankungen wie RSI (Repetitive-Strain-Verletzungen), Multiple Sklerose, Parkinson, Tetraplegie und Zerebralparese. Laut Weltgesundheitsorganisation leben etwa 1,3 Milliarden Menschen — 16% der Weltbevölkerung — mit einer Form einer erheblichen Behinderung, und motorische Beeinträchtigungen machen einen wesentlichen Teil dieser Zahl aus. Für diese Nutzer kann eine Tastaturfalle auf einer Checkout-Seite, einem Login-Formular oder einem Kundenservice-Chat-Widget bedeuten, dass sie die Aufgabe überhaupt nicht abschließen können.

Auch Screenreader-Nutzer — vor allem blinde und sehbehinderte Menschen — sind stark betroffen. Screenreader wie NVDA, JAWS und VoiceOver navigieren vollständig über Tastaturbefehle. Wenn der Fokus in einer Komponente gefangen ist, hört der Screenreader-Nutzer bei jedem Druck auf Tab dasselbe Element, ohne vor- oder zurückgehen zu können. Das ist äußerst desorientierend und zwingt den Nutzer dazu, den Browser-Tab zu schließen oder die Seite zu aktualisieren, wobei alle bereits gemachten Eingaben verloren gehen.

Betrachten wir folgendes Szenario aus der Praxis: Eine Nutzerin mit eingeschränkter Handbeweglichkeit besucht eine türkische E-Commerce-Seite, um ein Produkt zu kaufen. Sie legt einen Artikel in den Warenkorb und geht zur Kasse. Die Checkout-Seite enthält ein Adress-Autovervollständigungs-Widget eines Drittanbieters, das mit einem benutzerdefinierten JavaScript-Framework erstellt wurde. Das Widget öffnet eine Dropdown-Vorschlagsliste, wenn das Adressfeld Fokus erhält. Der Entwickler hat vergessen, Tastaturereignisse zum Schließen dieses Dropdowns zu implementieren — sobald die Nutzerin also in das Adressfeld tabbt und das Dropdown erscheint, kann sie nicht mehr heraus tabben, nicht Escape drücken und das Dropdown nicht ohne Mausklick schließen. Die Nutzerin ist vollständig daran gehindert, den Kauf abzuschließen. Das ist keine kleine Unannehmlichkeit — es ist ein vollständiger Ausschluss von der Dienstleistung.

Über den Zugang für Menschen mit Behinderungen hinaus betreffen Tastaturfallen auch Power-User, die aus Effizienzgründen die Tastatur bevorzugen, Nutzer in Unternehmensumgebungen, in denen die Mausnutzung eingeschränkt ist, sowie Nutzer bestimmter mobiler oder hybrider Geräte mit Hardware-Tastaturen. Die Beseitigung von Tastaturfallen verbessert daher die Nutzungserfahrung für eine breitere Zielgruppe als nur für Menschen mit Behinderungen.

Wie man testet

Führen Sie einen automatisierten Barrierefreiheits-Scan als Basis durch. Öffnen Sie axe DevTools (Browser-Erweiterung) oder führen Sie ein Lighthouse-Accessibility-Audit in den Chrome DevTools aus. Auch wenn keines der Tools eine Tastaturfalle direkt meldet, identifiziert der Scan fokussierbare Elemente, fehlende ARIA-Rollen und falsche Tab-Reihenfolgen, die auf riskante interaktive Komponenten hinweisen können, die manuell untersucht werden sollten. Notieren Sie alle benutzerdefinierten Widgets, eingebetteten iframes, Drittanbieter-Komponenten, modalen Dialoge, Dropdown-Menüs, Datumswähler, Karussells und Rich-Text-Editoren — dies sind die häufigsten Quellen von Tastaturfallen.
Trennen Sie Ihre Maus oder legen Sie sie beiseite. Damit manuelle Tastaturtests aussagekräftig sind, dürfen Sie keine Maus verwenden. Legen Sie die Maus außer Reichweite oder deaktivieren Sie sie in den Betriebssystemeinstellungen, um zu vermeiden, dass Sie während des Tests versehentlich auf sie zurückgreifen.
Navigieren Sie die gesamte Seite ausschließlich mit den Tasten Tab und Shift+Tab. Beginnen Sie in der Adressleiste des Browsers oder am oberen Seitenrand, drücken Sie wiederholt Tab und beobachten Sie, wohin der Fokus wandert. Verfolgen Sie den Fokusindikator bei jedem Schritt visuell. Wenn Sie zu jeder interaktiven Komponente gelangen — insbesondere zu benutzerdefinierten Widgets, eingebetteten Inhalten oder komplexen UI-Elementen — stellen Sie sicher, dass das Drücken von Tab oder Shift+Tab den Fokus sauber aus der Komponente heraus zum nächsten oder vorherigen fokussierbaren Element der Seite verschiebt.
Testen Sie jede interaktive Komponente einzeln. Für modale Dialoge: Öffnen Sie das Modal, vergewissern Sie sich, dass der Fokus hinein verschoben wird, drücken Sie dann Escape und prüfen Sie, ob der Fokus zum auslösenden Element zurückkehrt. Für Dropdown-Menüs: Öffnen Sie das Dropdown, navigieren Sie darin und drücken Sie dann Escape, um zu bestätigen, dass sich das Dropdown schließt und der Fokus zum Auslöser zurückkehrt. Für Datumswähler, Farbwähler und ähnliche Widgets: tabben Sie hinein, interagieren Sie, tabben Sie dann hinaus und bestätigen Sie, dass der Fokus die Komponente verlässt. Für eingebettete iframes (z. B. Karten, Videoplayer, Chat-Widgets): tabben Sie in das iframe, navigieren Sie darin und stellen Sie sicher, dass Sie wieder aus dem iframe heraus auf die Hauptseite tabben können.
Testen Sie mit NVDA und Firefox. Öffnen Sie NVDA, rufen Sie die Seite in Firefox auf und verwenden Sie Tab, um durch interaktive Elemente zu navigieren. Achten Sie darauf, ob NVDA bei jedem Druck auf Tab ein neues Element ansagt oder ob es scheinbar zum selben Element zurückspringt. Wenn Tab den Fokus nicht über eine Komponente hinaus verschiebt, liegt eine Tastaturfalle vor.
Testen Sie mit VoiceOver und Safari auf macOS. Aktivieren Sie VoiceOver (Command + F5), öffnen Sie die Seite in Safari und navigieren Sie mit der Tab-Taste. Bestätigen Sie, dass VoiceOver bei jedem Tab-Druck ein neues Element ansagt und dass der Fokus nie in einem Bereich stecken bleibt, den Sie nicht verlassen können.
Testen Sie mit JAWS und Chrome. Öffnen Sie JAWS, rufen Sie die Seite in Chrome auf und verwenden Sie Tab, um durch alle interaktiven Komponenten zu navigieren. Testen Sie insbesondere Komponenten, die JavaScript-gesteuerte Fokusverwaltung verwenden, da JAWS mit dem Accessibility-Tree interagiert und so Fallen sichtbar machen kann, die bei rein visuellen Tests unentdeckt bleiben.
Prüfen Sie auf nicht standardmäßige Escape-Mechanismen. Wenn eine Komponente eine andere Taste als Tab, Shift+Tab oder Escape zum Verlassen erfordert, stellen Sie sicher, dass die Seite dies klar kommuniziert — zum Beispiel über Bildschirmhinweise, ein Tooltip oder eine ARIA-Live-Region, die beim Eintritt des Fokus in die Komponente eine Ansage macht.

Wie man es behebt

Modaler Dialog ohne Escape-Behandlung — falsch

<!-- Modal öffnet sich, hat aber keinen Escape-Tasten-Handler und keine per Tastatur erreichbare Schließen-Schaltfläche -->
<div id='modal' role='dialog' aria-modal='true' aria-labelledby='modal-title'>
  <h2 id='modal-title'>Confirm Your Order</h2>
  <p>Are you sure you want to place this order?</p>
  <button onclick='submitOrder()'>Confirm</button>
  <!-- Keine Schließen-Schaltfläche, kein Escape-Tasten-Listener -- Tastaturnutzer sind gefangen -->
</div>

Modaler Dialog ohne Escape-Behandlung — korrekt

<!-- Modal mit korrekter Fokusbegrenzung, Escape-Handler und zugänglicher Schließen-Schaltfläche -->
<div id='modal' role='dialog' aria-modal='true' aria-labelledby='modal-title'>
  <h2 id='modal-title'>Confirm Your Order</h2>
  <p>Are you sure you want to place this order?</p>
  <button onclick='submitOrder()'>Confirm</button>
  <!-- Schließen-Schaltfläche ist per Tab erreichbar und ermöglicht Tastaturnutzern das Verlassen -->
  <button id='modal-close' onclick='closeModal()' aria-label='Close dialog'>Cancel</button>
</div>

<script>
  document.addEventListener('keydown', function(e) {
    if (e.key === 'Escape') {
      closeModal(); // Escape-Taste schließt das Modal und gibt den Fokus an den Auslöser zurück
    }
  });

  function closeModal() {
    document.getElementById('modal').hidden = true;
    document.getElementById('modal-trigger').focus(); // Fokus zum Öffner zurückgeben
  }
</script>

Benutzerdefiniertes Dropdown, das alle Tab-Tastenereignisse abfängt — falsch

<!-- Benutzerdefiniertes Dropdown fängt alle keydown-Ereignisse einschließlich Tab ab und verhindert, dass der Fokus das Element verlässt -->
<div id='custom-select' tabindex='0' role='combobox' aria-expanded='true'>
  <ul role='listbox'>
    <li role='option' tabindex='-1'>Option 1</li>
    <li role='option' tabindex='-1'>Option 2</li>
    <li role='option' tabindex='-1'>Option 3</li>
  </ul>
</div>

<script>
  // BUG: Dies fängt ALLE Tastaturereignisse ab und ruft preventDefault für Tab auf,
  // was bedeutet, dass der Nutzer nie aus dieser Komponente heraus tabben kann
  document.getElementById('custom-select').addEventListener('keydown', function(e) {
    e.preventDefault(); // Dies erzeugt die Tastaturfalle
    if (e.key === 'ArrowDown') { /* Fokus nach unten verschieben */ }
    if (e.key === 'ArrowUp') { /* Fokus nach oben verschieben */ }
  });
</script>

Benutzerdefiniertes Dropdown, das alle Tab-Tastenereignisse abfängt — korrekt

<!-- Korrekt: Nur für Pfeiltasten, die für die interne Navigation verwendet werden, preventDefault aufrufen;
     Tab und Escape normal funktionieren lassen, damit Nutzer das Element verlassen können -->
<div id='custom-select' tabindex='0' role='combobox' aria-expanded='false'>
  <ul role='listbox' hidden>
    <li role='option' tabindex='-1'>Option 1</li>
    <li role='option' tabindex='-1'>Option 2</li>
    <li role='option' tabindex='-1'>Option 3</li>
  </ul>
</div>

<script>
  document.getElementById('custom-select').addEventListener('keydown', function(e) {
    if (e.key === 'ArrowDown' || e.key === 'ArrowUp') {
      e.preventDefault(); // Nur für interne Navigationstasten preventDefault aufrufen
      // Fokus zwischen Optionen verschieben
    }
    if (e.key === 'Escape' || e.key === 'Tab') {
      // KEIN preventDefault aufrufen -- Tab und Escape durchreichen lassen,
      // damit der Browser den Fokus natürlich von dieser Komponente weg bewegen kann
      closeDropdown();
    }
  });
</script>

Eingebettetes Drittanbieter-iframe ohne Ausweg — falsch

<!-- Ein eingebettetes Chat-Widget-iframe, das alle Tab-Tastendrücke absorbiert
     und den Fokus nie an die übergeordnete Seite zurückgibt -->
<iframe
  src='https://example-chat-widget.com/embed'
  title='Customer support chat'
  width='350'
  height='500'>
</iframe>
<!-- Das interne JavaScript des iframes verbraucht Tab-Ereignisse und fängt Nutzer darin ein -->

Eingebettetes Drittanbieter-iframe ohne Ausweg — korrekt

<!-- Verwenden Sie eine Schaltfläche, um den Chat in einem neuen Fenster zu öffnen, statt
     ein iframe einzubetten, das Tastaturnutzer möglicherweise einfängt -->
<button
  id='open-chat'
  onclick='window.open("https://example-chat-widget.com", "_blank", "noopener")'>
  Open Customer Support Chat (opens in new window)
</button>

<!-- Wenn ein iframe verwendet werden muss, fügen Sie davor einen sichtbaren Skip-Link ein,
     damit Tastaturnutzer es bei Bedarf überspringen können -->
<a href='#after-chat-widget' class='skip-link'>Skip chat widget</a>
<iframe
  src='https://example-chat-widget.com/embed'
  title='Customer support chat'
  width='350'
  height='500'>
</iframe>
<span id='after-chat-widget' tabindex='-1'></span>

Häufige Fehler

event.preventDefault() in einem keydown-Listener aufrufen, ohne es auf bestimmte Tasten zu beschränken — wenn preventDefault() auf alle Tastaturereignisse einer fokussierbaren Komponente angewendet wird, blockiert dies Tab und Shift+Tab und erzeugt sofort eine Tastaturfalle. Beschränken Sie preventDefault() immer auf genau die Tasten, die Ihre Komponente intern verarbeiten muss (z. B. Pfeiltasten für Listboxen).
Einen modalen Dialog erstellen, der den Fokus in ihn hinein setzt, aber keinen Escape-Handler oder keine Schließen-Schaltfläche bietet — Entwickler implementieren oft den Teil des Modal-Musters korrekt, der den Fokus in das Modal hinein verlagert, vergessen aber, dass Fokusbegrenzung innerhalb eines Modals nur zulässig ist, wenn es immer einen tastaturzugänglichen Ausweg gibt. Jedes Modal muss die Escape-Taste verarbeiten und eine per Tab erreichbare Schließen-Schaltfläche enthalten.
tabindex='-1' auf einem Containerelement verwenden, um es aus der Tab-Reihenfolge zu entfernen, während JavaScript weiterhin den Fokus programmatisch hinein verschieben kann — wenn der Fokus per element.focus() in ein Element mit tabindex='-1' verschoben wird, gibt es kein natürliches Tab-Ziel, um es wieder zu verlassen, was den Nutzer stranden kann, wenn keine weitere Tastaturbehandlung implementiert ist.
Drittanbieter-Widgets (Chat, Karten, Video) einbetten, ohne sie auf Tastaturfallen zu prüfen — Anbieter entwickeln ihre eingebetteten Widgets nicht immer tastaturzugänglich. Seitenbetreiber bleiben für alle Inhalte auf ihren Seiten verantwortlich, einschließlich eingebetteter Drittanbieter-Inhalte. Testen Sie eingebettete Komponenten immer manuell und umgeben Sie sie mit einem Skip-Link oder ersetzen Sie sie durch eine tastatursichere Alternative, wenn sie Tastaturnutzer einfangen.
Einen Fokusfang für ein Modal oder eine Seitenleiste implementieren, aber den Fokus nicht freigeben, wenn die Komponente geschlossen wird — wenn das JavaScript, das den Fokus begrenzt, beim Schließen des Modals nicht korrekt bereinigt wird, kann es weiterhin Tab-Ereignisse abfangen und den Nutzer auf der nun unsichtbaren Ebene festhalten.
CSS visibility: hidden oder display: none verwenden, um die Schließen-Schaltfläche eines Dialogs aus Designgründen zu verstecken, ohne einen alternativen Tastaturausgang zu bieten — wenn die Schließen-Schaltfläche visuell verborgen, aber nicht aus dem Accessibility-Tree entfernt wird, können Screenreader-Nutzer sie weiterhin finden; wenn sie jedoch auch aus dem Accessibility-Tree entfernt wird, gibt es möglicherweise keinen Ausweg. Stellen Sie sicher, dass alle Schließmechanismen per Tastatur bedienbar sind, auch wenn sie optisch dezent gestaltet sind.
Benutzerdefinierte Autovervollständigungs- oder Type-Ahead-Komponenten erstellen, die eine Vorschlagsliste öffnen und dann alle Tab-Tastendrücke zum Durchlaufen der Vorschläge verwenden, statt zum Verlassen — Nutzer sollten Escape drücken können, um die Vorschlagsliste zu schließen, und dann Tab, um zum nächsten Formularfeld zu wechseln. Autovervollständigungs-Widgets, die Tab für interne Navigation umleiten, verstoßen gegen dieses Kriterium.
Vergessen, Rich-Text-Editoren (WYSIWYG-Editoren wie TinyMCE, CKEditor oder Quill) zu testen — diese Komponenten verwalten ihre Tastaturinteraktion intern und sind eine häufige Quelle von Tastaturfallen. Stellen Sie immer sicher, dass das Drücken von Escape oder einer dokumentierten Tastenkombination den Editor verlässt und den Fokus in die normale Tab-Reihenfolge der Seite zurückführt.
Anzunehmen, dass eine Komponente keine Tastaturfalle sein kann, nur weil sie native HTML-Elemente verwendet — ein <select>-Element in einem Formular, dessen blur-Ereignis per JavaScript überschrieben wird, kann den Fokus dennoch einfangen. Die Verwendung semantischen HTMLs garantiert kein tastaturfallenfreies Verhalten, wenn benutzerdefinierte JavaScript-Ereignisbehandlung darübergelegt wird.
Keine Bildschirmdokumentation bereitzustellen, wenn zum Verlassen einer Komponente eine nicht standardmäßige Taste erforderlich ist — WCAG 2.1.2 erlaubt ausdrücklich Komponenten, die zum Verlassen nicht standardmäßige Tasten erfordern, sofern der Nutzer informiert wird. Wenn Ihr Widget das Drücken von F6 oder einer benutzerdefinierten Tastenkombination verlangt, müssen Sie dies klar kommunizieren, idealerweise über sichtbare Hinweise in der Nähe der Komponente oder eine ARIA-Live-Region, die beim Eintritt des Fokus eine Ansage macht.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die Präsidialverfügung 2025/10 der Türkei, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Anforderungen an die digitale Barrierefreiheit für eine breite Palette öffentlicher und privater Einrichtungen fest, die in der Türkei tätig sind. Die Verfügung schreibt die Einhaltung international anerkannter Web-Barrierefreiheitsstandards vor — in Übereinstimmung mit WCAG 2.1 Stufe AA als Basis, die alle Kriterien der Stufe A einschließlich WCAG 2.1.2 „Keine Tastaturfalle“ umfasst.

WCAG 2.1.2 ist ein Kriterium der Stufe A, das das Mindestniveau der Konformität darstellt. Nach der Verfügung ist die Konformität der Stufe A für alle erfassten Einrichtungen verpflichtend. Öffentliche Institutionen müssen diese Konformität innerhalb eines Jahres nach Veröffentlichung der Verfügung erreichen, während privaten Einrichtungen zwei Jahre zur Umsetzung eingeräumt werden.

Der Kreis der von der Verfügung erfassten Einrichtungen ist weit gefasst und umfasst öffentliche Institutionen und Regierungsstellen auf allen Ebenen, E-Commerce-Plattformen und Betreiber von Online-Marktplätzen, Banken und Finanzdienstleister, Krankenhäuser und Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200,000 oder mehr Abonnenten, Reisebüros, private Transportunternehmen und Privatschulen, die vom Bildungsministerium (MoNE) autorisiert sind. Das bedeutet, dass das Unterlassen der Beseitigung von Tastaturfallen auf einer Website oder Webanwendung, die von einer dieser Einrichtungen betrieben wird, einen direkten Verstoß gegen die verbindlichen Barrierefreiheitsvorschriften der Türkei darstellt.

Angesichts der Häufigkeit von Tastaturfallen in komplexen Webanwendungen — insbesondere in Online-Banking-Portalen, Systemen zur Krankenhaus-Terminbuchung, E-Commerce-Checkout-Prozessen und Seiten zur Verwaltung von Telekommunikationskonten — verdient WCAG 2.1.2 im türkischen Compliance-Kontext besondere Aufmerksamkeit. Genau diese interaktionsintensiven, JavaScript-gesteuerten Oberflächen enthalten am ehesten benutzerdefinierte Widgets, modale Dialoge und Drittanbieter-Einbettungen, die Tastaturnutzer unbeabsichtigt einfangen können.

Organisationen, die der Verfügung unterliegen, sollten das Testen auf Tastaturfallen als unverzichtbaren Bestandteil ihres Barrierefreiheitsaudits betrachten. Da automatisierte Tools Tastaturfallen nicht zuverlässig erkennen können, müssen betroffene Einrichtungen in manuelle Tastaturtests investieren, die von qualifizierten Barrierefreiheitsspezialisten durchgeführt werden, idealerweise unter Einbeziehung von Menschen mit Behinderungen, als Teil ihres Weges zur Konformität. Das Versäumnis, im Audit identifizierte Tastaturfallen zu beheben, stellt nicht nur ein rechtliches Risiko im Rahmen der Verfügung dar, sondern auch eine erhebliche Zugangshürde für Nutzer mit motorischen und visuellen Beeinträchtigungen, die auf Tastaturnavigation angewiesen sind, um digitale Dienste zu nutzen.