WCAG 2.1.4: Tastenkombinationen mit einzelnen Zeichen

Was diese Regel bedeutet

WCAG 2.1.4 — Tastenkombinationen mit Zeichen ist ein Erfolgskriterium der Stufe A, das in WCAG 2.1 eingeführt wurde. Es befasst sich mit einer spezifischen, aber schwerwiegenden Barriere: wenn eine Webanwendung Tastenkombinationen zuweist, die aus einem einzelnen druckbaren Zeichen bestehen – einem Buchstaben, einer Zahl, einem Satzzeichen oder einem Symbol – ohne dass eine Modifikatortaste wie Strg, Alt, Meta oder Umschalt zusätzlich erforderlich ist.

Das Kriterium besagt, dass, wenn eine Tastenkombination in Inhalten implementiert ist, die nur eine einzelne Zeichentaste verwendet, mindestens eine der folgenden Bedingungen erfüllt sein muss:

• Ausschalten: Es steht ein Mechanismus zur Verfügung, der es der Nutzerin oder dem Nutzer ermöglicht, die Tastenkombination vollständig auszuschalten.
• Neu zuordnen: Es steht ein Mechanismus zur Verfügung, der es der Nutzerin oder dem Nutzer ermöglicht, die Tastenkombination so neu zuzuordnen, dass eine oder mehrere nicht druckbare Modifikatortasten (wie Strg oder Alt) verwendet werden.
• Nur bei Fokus aktiv: Die Tastenkombination für eine Benutzeroberflächenkomponente ist nur aktiv, wenn diese Komponente den Fokus hat.

Eine Tastenkombination mit einer einzelnen Zeichentaste ist eine, die durch Drücken einer einzelnen Taste ausgelöst wird, die ein druckbares Zeichen erzeugt – zum Beispiel das Drücken von G, um eine Galerie zu öffnen, das Drücken von /, um die Suchleiste zu fokussieren, oder das Drücken von N, um eine neue Nachricht zu verfassen. Diese unterscheiden sich grundlegend von Tastenkombinationen wie Strg+S oder Alt+F4, die eine nicht druckbare Modifikatortaste erfordern und daher nicht in den Geltungsbereich dieses Kriteriums fallen.

Eine Tastenkombination erfüllt dieses Kriterium, wenn die Anwendung entweder: (1) eine Einstellungs- oder Präferenzseite bereitstellt, auf der Einzeltasten-Kombinationen deaktiviert oder in Mehrtasten-Kombinationen geändert werden können; (2) automatisch auf modifikatorbasierte Tastenkombinationen neu zuordnet; oder (3) die Tastenkombination nur auslöst, wenn das auslösende Element selbst den Tastaturfokus hat – was bedeutet, dass das Drücken der Taste, während der Fokus anderswo liegt, nichts bewirkt.

Eine Tastenkombination verfehlt das Kriterium, wenn ein einzelner Tastenanschlag eine globale Aktion jederzeit auslöst, unabhängig davon, welches Element den Fokus hat, und es keine Möglichkeit für die Nutzerin oder den Nutzer gibt, sie auszuschalten oder zu ändern. Ein häufiges Beispiel aus der Praxis ist eine Single-Page-Anwendung, die eine Navigationsaktion ausführt, wann immer die Nutzerin oder der Nutzer eine Buchstabentaste drückt – selbst während sie oder er ein Textfeld ausfüllt oder Text diktiert.

Das Kriterium enthält eine wichtige offizielle Ausnahme: Es gilt nicht, wenn die Tastenkombination nur aktiv ist, während eine bestimmte Komponente den Fokus hat. Ein Beispiel ist ein benutzerdefiniertes Dropdown-Widget, das nur dann auf Buchstabentasten reagiert, wenn das Dropdown selbst geöffnet und fokussiert ist; dies ist zulässig, weil die Fokuseinschränkung das Risiko unbeabsichtigter Auslösungen begrenzt.

Warum es wichtig ist

Dieses Kriterium dient in erster Linie dem Schutz zweier Nutzergruppen, auch wenn seine Vorteile darüber hinausgehen.

Nutzerinnen und Nutzer von Spracheingabe sind am unmittelbarsten betroffen. Menschen mit motorischen Beeinträchtigungen steuern ihre Computer häufig vollständig über Spracherkennungssoftware wie Dragon NaturallySpeaking (heute Dragon Professional). Beim Diktieren von Text oder beim Ausführen von Sprachbefehlen erzeugen diese Werkzeuge Tastenanschläge, die unbeabsichtigt Einzeltasten-Kombinationen auf der aktiven Webseite auslösen können. Man stelle sich eine Person vor, die ein medizinisches Formular diktiert und „next“ sagt – wenn die Anwendung global auf den Buchstaben N hört, könnte sie vom Formular weg navigieren und die Eingaben der Person zerstören. Laut CDC leben in den Vereinigten Staaten etwa 61 Millionen Erwachsene mit einer Behinderung, und ein erheblicher Teil von ihnen ist auf alternative Eingabemethoden einschließlich Spracherkennung angewiesen.

Motorisch beeinträchtigte Nutzerinnen und Nutzer, die Schaltersteuerung, Saug-und-Pust-Geräte oder ausschließlich die Tastatur zur Navigation verwenden, sind ebenfalls gefährdet. Diese Personen können Tasten versehentlich drücken oder über mehrere Tasten „rollen“, während sie versuchen, ein Ziel zu erreichen. Ein einziger Fehlanschlag, der eine nicht rückgängig zu machende Aktion auslöst – etwa das Archivieren einer E-Mail, das Löschen einer Datei oder das Absenden eines Formulars – kann zu erheblicher Frustration und Datenverlust führen.

Nutzerinnen und Nutzer mit kognitiven Beeinträchtigungen können ebenfalls geschädigt werden. Personen mit Aufmerksamkeitsstörungen oder Personen, die mit einer Oberfläche nicht vertraut sind, drücken möglicherweise experimentell Tasten, um die Seite zu erkunden, ohne zu wissen, dass Einzeltasten-Kombinationen aktiv sind. Unerwartete Navigationen oder Zustandsänderungen erhöhen die kognitive Belastung und Desorientierung.

Betrachten wir folgendes Szenario aus der Praxis: Eine türkische E-Commerce-Plattform implementiert Einzeltasten-Kombinationen für Power-User – Drücken von C, um zum Warenkorb zu gelangen, Drücken von F, um zu den Favoriten zu gelangen. Eine Nutzerin oder ein Nutzer mit Spracheingabe versucht, die Lieferadresse in ein Formularfeld zu diktieren. Während sie oder er „Caddesi“ (das türkische Wort für „Straße“) sagt, gibt die Spracherkennungssoftware den Buchstaben C aus, bevor der Fokus vollständig in das Eingabefeld wechselt, und löst die Navigation zur Warenkorbseite aus. Die teilweise eingegebene Adresse geht verloren. Die Person muss von vorne beginnen, und wenn sich die Erfahrung wiederholt, wird sie die Seite möglicherweise ganz aufgeben.

Über die Barrierefreiheit hinaus verbessert die Behebung dieses Kriteriums die allgemeine Benutzerfreundlichkeit. Eine Benutzeroberfläche zur Anpassung von Tastenkombinationen signalisiert ein ausgereiftes, nutzerorientiertes Produkt. Sie kann auch Supportanfragen von frustrierten Nutzerinnen und Nutzern reduzieren, die versehentlich Tastenkombinationen auslösen.

Verwandte Axe-core-Regeln

WCAG 2.1.4 erfordert manuelle Tests, da automatisierte Werkzeuge nicht zuverlässig alle Tastenkombinationen mit einzelnen Zeichen erkennen oder überprüfen können, ob ein Mechanismus zum Neu­zuordnen/Deaktivieren existiert. Hier ist der Grund, warum Automatisierung an ihre Grenzen stößt und worauf Testerinnen und Tester manuell achten müssen:

• Keine dedizierte axe-core-Regel (manuelle Prüfung erforderlich): Axe-core und Lighthouse verfügen über keine automatisierte Regel, die speziell Tastenkombinationen mit einzelnen Zeichen kennzeichnet. Der Grund ist architektonischer Natur: Das Verhalten von Tastenkombinationen wird in JavaScript-Ereignis-Listenern (keydown, keyup, keypress) implementiert, und eine statische DOM-Analyse kann nicht bestimmen, welche Aktion ein bestimmter Tastenanschlag auslöst, ob diese Aktion global oder fokusbezogen ist oder ob ein benutzerseitiger Mechanismus zum Deaktivieren/Neu­zuordnen existiert. Ein Werkzeug müsste Tastenanschläge für alle möglichen Zeichen simulieren und die resultierenden Zustandsänderungen der Anwendung beobachten – eine kombinatorisch aufwendige und kontextabhängige Aufgabe, die die aktuellen Möglichkeiten automatisierter Tests übersteigt.
• Inspektion von Ereignis-Listenern (teilweise Automatisierung): Browser-DevTools können Ereignis-Listener auf document-, window- oder body-Elementen auflisten. Wenn eine Seite einen keydown-Listener an document anhängt und die Inspektion seines Quellcodes eine Logik zur Prüfung einzelner Zeichen offenlegt, ist dies ein starkes Signal, das eine manuelle Überprüfung erfordert. Das Werkzeug kann jedoch nicht selbst bestimmen, ob das resultierende Verhalten eine Tastenkombination darstellt oder ob ein Deaktivierungsmechanismus vorhanden ist.
• Framework-spezifische Shortcut-Bibliotheken: Viele React-, Vue- oder Angular-Anwendungen verwenden Bibliotheken wie react-hotkeys-hook, tinykeys oder Mousetrap, die globale Tastenkombinationen registrieren. Eine manuelle Prüfung sollte im Seitenquelltext oder im Netzwerk-Tab nach diesen Abhängigkeiten suchen und dann jede registrierte Tastenkombination anhand der Anforderungen des Kriteriums testen.

Wie man testet

1. Die Anwendung auf bekannte Einzeltasten-Kombinationen prüfen: Lesen Sie alle verfügbaren Dokumentationen, Hilfeseiten oder Dialoge mit Tastenkombinationsübersichten (oft mit ? geöffnet oder über ein Hilfe-Menü zugänglich). Listen Sie alle dokumentierten Tastenkombinationen auf, die ein einzelnes Zeichen ohne Modifikatortaste verwenden.
2. JavaScript-Ereignis-Listener inspizieren: Öffnen Sie Chrome DevTools oder Firefox DevTools, navigieren Sie zum Reiter „Elements“ oder „Sources“ und verwenden Sie den Tab „Event Listeners“, um Listener auf document, window und body zu inspizieren. Suchen Sie nach Handlern für keydown, keyup oder keypress. Klappen Sie den Handler auf und lesen Sie den Quellcode, um zu sehen, ob einzelne Zeichentasten ohne Prüfung von Modifikatoren getestet werden (d. h. der Code prüft event.key === 'n', ohne zusätzlich event.ctrlKey || event.metaKey || event.altKey zu prüfen).
3. Tastenkombinationen testen, während der Fokus in einer Texteingabe liegt: Klicken Sie in ein Textfeld, ein Suchfeld oder ein Textarea. Drücken Sie dann jede Einzeltasten-Kombination, die Sie identifiziert haben. Wenn die Tastenkombination ausgelöst wird (Navigation erfolgt, eine Aktion wird ausgelöst, der Zustand ändert sich), ist dies ein Fehler – die Tastenkombination ist nicht fokusbezogen und ist aktiv, selbst wenn die Nutzerin oder der Nutzer tippt.
4. Test mit NVDA + Firefox: Aktivieren Sie den NVDA-Browse-Modus (Einfg+Leertaste zum Umschalten). Im Browse-Modus verwendet NVDA Einzeltasten zur Navigation (H für Überschriften, B für Schaltflächen usw.). Starten Sie die zu testende Webanwendung. Wechseln Sie in den Fokusmodus (Einfg+Leertaste) und diktieren oder tippen Sie Text. Vergewissern Sie sich, dass die eigenen Einzeltasten-Kombinationen der Seite nicht mit den Tastenanschlägen des NVDA-Browse-Modus kollidieren und dass keine unbeabsichtigten Aktionen ausgelöst werden.
5. Test mit JAWS + Chrome: Ähnlich verwendet JAWS Einzeltasten zur Schnellnavigation. Starten Sie die Anwendung, navigieren Sie mit dem virtuellen Cursor von JAWS und vergewissern Sie sich, dass die Tastenkombinationen der Anwendung nicht unerwartet ausgelöst werden, während JAWS Tastenanschläge verarbeitet.
6. Test mit VoiceOver + Safari (macOS): Aktivieren Sie VoiceOver (Cmd+F5). Verwenden Sie VO+Umschalt+Pfeil nach unten, um mit Inhaltsbereichen zu interagieren. Vergewissern Sie sich, dass Buchstabentasten-Kombinationen auf der Seite nicht mit VoiceOver-Navigationsbefehlen interferieren.
7. Spracheingabe simulieren: Wenn Dragon NaturallySpeaking oder die Windows-Spracherkennung verfügbar ist, diktieren Sie Text in ein Formularfeld, während die Anwendung geöffnet ist. Sprechen Sie gängige Wörter und Phrasen, die mit Buchstaben beginnen, die als Tastenkombinationen verwendet werden. Vergewissern Sie sich, dass keine unbeabsichtigten Aktionen ausgelöst werden.
8. Den Mechanismus zum Deaktivieren oder Neu­zuordnen überprüfen: Wenn Einzeltasten-Kombinationen existieren, suchen Sie die Einstellungs- oder Präferenzoberfläche, über die sie ausgeschaltet oder neu zugeordnet werden können. Bestätigen Sie, dass sie ausschließlich mit der Tastatur erreichbar ist und korrekt funktioniert. Testen Sie, dass nach dem Deaktivieren einer Tastenkombination das Drücken des Zeichens die Aktion nicht mehr auslöst.

Wie man es behebt

Globale Einzeltasten-Kombination ohne Modifikatorprüfung — Falsch

<!-- JavaScript, das an document angehängt ist, reagiert global auf jeden 'n'-Tastendruck -->
<script>
document.addEventListener('keydown', function(event) {
  if (event.key === 'n') {
    // Zur Ansicht "Neue Nachricht verfassen" navigieren
    openComposeWindow();
  }
});
</script>

Globale Einzeltasten-Kombination — Richtig: Modifikatoranforderung und Deaktivierungsschalter hinzufügen

<!-- Richtiger Ansatz 1: Eine Modifikatortaste (Strg+N) verlangen, um unbeabsichtigtes Auslösen zu verhindern -->
<script>
document.addEventListener('keydown', function(event) {
  // Nur auslösen, wenn Strg oder Meta (Cmd auf dem Mac) ebenfalls gedrückt wird
  if ((event.ctrlKey || event.metaKey) && event.key === 'n') {
    openComposeWindow();
  }
});
</script>

<!-- Richtiger Ansatz 2: Wenn eine Einzeltasten-Kombination erforderlich ist, einen Deaktivierungsschalter bereitstellen -->
<button type='button' id='toggle-shortcuts' aria-pressed='true'>
  Keyboard shortcuts enabled
</button>
<script>
let shortcutsEnabled = true;
document.getElementById('toggle-shortcuts').addEventListener('click', function() {
  shortcutsEnabled = !shortcutsEnabled;
  this.setAttribute('aria-pressed', shortcutsEnabled.toString());
  this.textContent = shortcutsEnabled ? 'Keyboard shortcuts enabled' : 'Keyboard shortcuts disabled';
});

document.addEventListener('keydown', function(event) {
  if (!shortcutsEnabled) return; // Nutzerpräferenz respektieren
  if (event.key === 'n') {
    openComposeWindow();
  }
});
</script>

Tastenkombination innerhalb eines fokussierten Widgets aktiv — Falsch

<!-- Tastenkombination hört auf das gesamte Dokument, nicht auf das Widget beschränkt -->
<div id='autocomplete-list' role='listbox'>
  <div role='option'>Istanbul</div>
  <div role='option'>Ankara</div>
</div>
<script>
// FEHLER: an document angehängt, wird ausgelöst, selbst wenn Autovervollständigung nicht fokussiert ist
document.addEventListener('keydown', function(e) {
  if (e.key === 'Enter') selectHighlightedOption();
});
</script>

Tastenkombination innerhalb eines fokussierten Widgets aktiv — Richtig: Listener auf das Widget beschränken

<!-- Richtig: Listener befindet sich auf dem Widget-Element; Tastenkombination wird nur ausgelöst, wenn es den Fokus hat -->
<div id='autocomplete-list' role='listbox' tabindex='0'>
  <div role='option'>Istanbul</div>
  <div role='option'>Ankara</div>
</div>
<script>
var widget = document.getElementById('autocomplete-list');
// Listener auf dem Widget selbst: Enter wird nur ausgelöst, wenn die Listbox fokussiert ist
widget.addEventListener('keydown', function(e) {
  if (e.key === 'Enter') selectHighlightedOption();
});
</script>

Keine für Nutzer zugängliche UI zur Neu­zuordnung — Falsch

<!-- Anwendung registriert Tastenkombinationen mit einer Bibliothek, bietet aber keine Einstellungsseite -->
<!-- Nutzerinnen und Nutzer können 'g' (Gehe zur Galerie) oder 'c' (Gehe zum Warenkorb) nicht ändern oder deaktivieren -->
<script src='hotkeys.min.js'></script>
<script>
hotkeys('g', function() { goToGallery(); });
hotkeys('c', function() { goToCart(); });
</script>

Keine für Nutzer zugängliche UI zur Neu­zuordnung — Richtig: barrierefreies Einstellungsfenster hinzufügen

<!-- Einstellungsfenster ist per Tastatur zugänglich; ermöglicht das Umschalten aller Einzeltasten-Kombinationen -->
<nav aria-label='Accessibility settings'>
  <button type='button' id='open-shortcut-settings'>Keyboard shortcut settings</button>
</nav>

<dialog id='shortcut-settings-dialog' aria-labelledby='dialog-title'>
  <h2 id='dialog-title'>Keyboard Shortcuts</h2>
  <label>
    <input type='checkbox' id='enable-single-char' checked />
    Enable single-character keyboard shortcuts (G, C, N...)
  </label>
  <p>Disable this if you use speech recognition software or experience accidental activations.</p>
  <button type='button' id='close-dialog'>Save and close</button>
</dialog>

<script src='hotkeys.min.js'></script>
<script>
var checkbox = document.getElementById('enable-single-char');

function applyShortcuts() {
  if (checkbox.checked) {
    hotkeys('g', function() { goToGallery(); });
    hotkeys('c', function() { goToCart(); });
  } else {
    hotkeys.unbind('g');
    hotkeys.unbind('c');
  }
}

applyShortcuts();
checkbox.addEventListener('change', applyShortcuts);

document.getElementById('open-shortcut-settings').addEventListener('click', function() {
  document.getElementById('shortcut-settings-dialog').showModal();
});
document.getElementById('close-dialog').addEventListener('click', function() {
  document.getElementById('shortcut-settings-dialog').close();
});
</script>

Häufige Fehler

• Registrieren von Tastenkombinationen auf document oder window, ohne zu prüfen, ob derzeit ein Eingabeelement fokussiert ist: Selbst wenn ein Deaktivierungsmechanismus existiert, vergessen viele Implementierungen, document.activeElement zu prüfen und die Tastenkombination zu unterdrücken, wenn sich die Nutzerin oder der Nutzer in einem <input>-, <textarea>- oder contenteditable-Element befindet, was zu Störungen beim normalen Tippen führt.
• Behandlung der ?-Tastenkombination (Hilfe öffnen) als ausgenommen: Das Fragezeichen ist ein druckbares Zeichen und eine Einzeltasten-Kombination. Es ist von diesem Kriterium nicht ausgenommen, es sei denn, es ist fokusbezogen oder es existiert ein Mechanismus zum Deaktivieren/Neu­zuordnen.
• Nur das Deaktivieren von Tastenkombinationen in Texteingaben, aber nicht in contenteditable-Bereichen oder Rich-Text-Editoren: Nutzerinnen und Nutzer von Spracheingabe diktieren häufig in contenteditable-Elemente, die von Rich-Text-Editoren verwendet werden (wie in CMS-Plattformen). Das Versäumnis, globale Tastenkombinationen in diesen Kontexten zu unterdrücken, verstößt weiterhin gegen das Kriterium.
• Speichern der Tastenkombinationspräferenz der Nutzerin oder des Nutzers nur im Sitzungsspeicher: Wenn die Person Tastenkombinationen deaktiviert und dann die Seite aktualisiert, sollte die Präferenz beibehalten werden (in localStorage oder einer Benutzereinstellung im Profil), damit sie nicht bei jedem Besuch erneut deaktivieren muss.
• Die Einstellungsoberfläche für Tastenkombinationen selbst unzugänglich machen: Wenn die Option zum Deaktivieren/Neu­zuordnen tief in einem Menü platziert ist, das mit der Tastatur nicht erreichbar ist, oder wenn ein benutzerdefiniertes Umschalt-Widget ohne korrektes role='switch' und aria-checked verwendet wird, ist der Mechanismus für genau die Nutzerinnen und Nutzer unbrauchbar, denen er helfen soll.
• Davon ausgehen, dass nur Buchstabentasten relevant sind: Zahlentasten (1–9), Satzzeichen (/, ., Komma, Semikolon) und Symboltasten (#, @, !) sind alles druckbare Zeichen. Einzeltasten-Kombinationen mit diesen Zeichen unterliegen gleichermaßen dem Kriterium.
• Versäumnis, zu dokumentieren, welche Tastenkombinationen existieren: Selbst wenn ein Deaktivierungsmechanismus vorhanden ist, können Nutzerinnen und Nutzer ihn nicht effektiv nutzen, wenn sie nicht wissen, welche Tastenkombinationen aktiv sind. Es wird dringend empfohlen, eine sichtbare, per Tastatur zugängliche Übersicht der Tastenkombinationen bereitzustellen (z. B. einen Dialog, der über eine Hilfe-Schaltfläche geöffnet wird).
• Verwendung der Standardkonfiguration einer Shortcut-Bibliothek, die global bindet, ohne die Dokumentation zu lesen: Bibliotheken wie Mousetrap, Hotkeys.js und tinykeys binden standardmäßig im globalen Geltungsbereich. Entwickelnde verwenden sie oft, ohne die Dokumentation zu Geltungsbereichsbeschränkungen oder Modifikatoranforderungen zu lesen, und schaffen so unbeabsichtigt Verstöße gegen das Kriterium in großem Umfang.
• Kein Test mit Spracherkennung vor dem Launch: Teams, die Dragon NaturallySpeaking nicht in ihrem QA-Werkzeugkasten haben, entdecken Konflikte mit Einzeltasten-Kombinationen häufig erst nach der Bereitstellung, wenn Nutzerinnen und Nutzer mit Spracheingabe Probleme melden.
• Die Annahme, dass eine Tastenkombination, weil sie „optional“ oder „für Power-User“ ist, ausgenommen sei: Das Kriterium gilt für alle Einzeltasten-Kombinationen, unabhängig davon, ob sie als erweiterte Funktionen vermarktet werden. Die Optionalität der Funktion befreit sie nicht von der Konformitätsanforderung.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die türkische Präsidialverfügung 2025/10, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Anforderungen an die Barrierefreiheit von Web- und Mobilangeboten fest, die an WCAG 2.2 ausgerichtet sind. WCAG 2.1.4 — Tastenkombinationen mit Zeichen ist ein Erfolgskriterium der Stufe A und gehört damit zur höchsten Prioritätsstufe der Verpflichtungen gemäß der Verfügung.

Die Verfügung umfasst eine breite Palette von Einrichtungen, die in der Türkei tätig sind. Öffentliche Institutionen – darunter Ministerien, Kommunen, staatliche Universitäten, öffentliche Krankenhäuser und Regierungsbehörden – müssen innerhalb von einem Jahr nach Veröffentlichung der Verfügung vollständige Konformität mit Stufe A erreichen. Private Unternehmen in den erfassten Kategorien erhalten ein zweijähriges Zeitfenster zur Einhaltung. Zu den erfassten privaten Einrichtungen gehören E-Commerce-Plattformen, Banken und Finanzinstitute, Krankenhäuser und Gesundheitsdienstleister, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnentinnen und Abonnenten, Reisebüros, private Transportunternehmen und Privatschulen, die unter der Genehmigung des Bildungsministeriums (MoNE) tätig sind.

Für diese Organisationen ist die Nichteinhaltung von WCAG 2.1.4 nicht nur eine Frage bewährter Verfahren – sie ist eine rechtliche Verpflichtung. Eine türkische E-Commerce-Seite, die Einzeltasten-Kombinationen für die Produktnavigation ohne Deaktivierungsmechanismus implementiert, oder das Online-Portal einer türkischen Bank, das Buchstabentasten-Kombinationen im Transaktionsablauf verwendet, würde direkt gegen die Anforderungen der Verfügung verstoßen.

Praktisch sollten Compliance-Teams in den erfassten Einrichtungen ihre JavaScript-Codebasen und alle Drittanbieter-Widget-Bibliotheken im Rahmen ihrer WCAG-2.2-Stufe-A-Nachbesserungsprojekte gezielt auf global registrierte Einzeltasten-Kombinationen prüfen. Da dieses Kriterium manuelle Tests erfordert, werden automatisierte Barrierefreiheits-Scans Verstöße nicht allein aufdecken – ein dedizierter Testdurchlauf mit Tastatur und Spracheingabe ist erforderlich. Organisationen, die Content-Management-Systeme oder Frontend-Frameworks verwenden, sollten neben dem eigenen Anwendungscode auch plattformseitige Implementierungen von Tastenkombinationen überprüfen (zum Beispiel standardmäßige Tastenkombinationen im CMS-Adminbereich, die auf kundenseitigen Seiten sichtbar sind).

Das Overlay-SDK von Accsible unterstützt erfasste Einrichtungen, indem es ein für Nutzerinnen und Nutzer zugängliches Panel für Barrierefreiheitspräferenzen bereitstellt, das einen Schalter zum Deaktivieren von Tastenkombinationen anzeigen kann. So können Organisationen die Anforderung eines „Mechanismus zum Ausschalten“ von WCAG 2.1.4 erfüllen, ohne den gesamten Codebestand refaktorieren zu müssen. Dies ist besonders wertvoll für Organisationen, die Legacy-Anwendungen verwalten, bei denen die Änderung der zugrunde liegenden JavaScript-Logik für Tastenkombinationen ressourcenintensiv ist. Organisationen sollten jedoch beachten, dass die ausschließliche Abstützung auf ein Overlay zur Einhaltung nicht den Ersatz für die Behebung der zugrunde liegenden Implementierungen von Tastenkombinationen darstellt und dass ein gestuftes Vorgehen, das Overlay-Werkzeuge mit Quellcode-Nachbesserungen kombiniert, den robustesten Weg zur Konformität im Rahmen der Präsidialverfügung bietet.