WCAG 2.1.2: Brak pułapki klawiaturowej

Co Oznacza Ta Zasada

WCAG 2.1.2 — Brak pułapki klawiaturowej — to kryterium sukcesu na poziomie A w ramach zasady Operable (Możliwość obsługi). Stanowi ono: „Jeśli fokus klawiatury może zostać przeniesiony na komponent strony za pomocą interfejsu klawiatury, to fokus może zostać przeniesiony z tego komponentu używając wyłącznie interfejsu klawiatury, a jeśli do przeniesienia fokusu potrzeba więcej niż niezmodyfikowanych klawiszy strzałek lub Tab, użytkownik jest poinformowany o metodzie przenoszenia fokusu.”

W praktyce oznacza to, że każdy interaktywny komponent na stronie internetowej, do którego użytkownik klawiatury może przejść klawiszem Tab, musi również pozwalać użytkownikowi na wyjście z niego za pomocą Tab. Pułapka klawiaturowa występuje wtedy, gdy użytkownik wchodzi do widżetu, okna dialogowego, niestandardowego kontrolki formularza, osadzonego odtwarzacza multimediów lub innego obszaru z fokusem i nie jest w stanie go opuścić, używając standardowych skrótów klawiaturowych — jest w efekcie uwięziony.

Kryterium obejmuje wszystkie elementy HTML, które mogą otrzymać fokus klawiatury: natywne elementy interaktywne, takie jak tagi <input>, <select>, <textarea>, <button> i <a>, a także niestandardowe widżety, które otrzymują fokus poprzez tabindex, role ARIA lub zarządzanie fokusem w JavaScript. W równym stopniu dotyczy to osadzonych komponentów zewnętrznych, takich jak widżety czatu, odtwarzacze wideo, osadzone mapy, selektory daty i edytory tekstu sformatowanego.

Komponent spełnia to kryterium, jeśli użytkownik klawiatury zawsze może przenieść fokus poza niego, używając standardowych klawiszy — zazwyczaj Tab, Shift+Tab, Escape lub klawiszy strzałek — lub jeśli strona wyraźnie informuje użytkowników o niestandardowym mechanizmie klawiaturowym służącym do przeniesienia fokusu. Komponent nie spełnia kryterium, jeśli fokus zostaje w nim zablokowany bez możliwości wyjścia za pomocą klawiatury lub jeśli jedyny mechanizm wyjścia wymaga kliknięcia myszą, gestu dotykowego lub innego wejścia niż klawiatura.

WCAG przewiduje wątek wyjątek: dopuszczalne jest tymczasowe ograniczenie fokusu klawiatury do komponentu, jeśli jest to częścią zamierzonego i dostępnego wzorca projektowego — w szczególności modalnego okna dialogowego. Modalne okno dialogowe powinno „uwięzić” fokus wewnątrz okna, gdy jest ono otwarte (aby zapobiec interakcji z zasłoniętą treścią w tle), ale musi zawsze zapewniać klawiaturowo dostępny sposób zamknięcia okna i zwolnienia fokusu — na przykład obsługę klawisza Escape lub wyraźnie oznaczony przycisk zamknięcia osiągalny klawiszem Tab. Tego rodzaju zamierzone, możliwe do opuszczenia ograniczenie fokusu nie jest pułapką klawiaturową; jest poprawną implementacją wzorca modalnego okna dialogowego. Pułapka staje się błędem dopiero wtedy, gdy użytkownik w ogóle nie może się wydostać.

Dlaczego To Ma Znaczenie

Pułapki klawiaturowe należą do najpoważniejszych błędów dostępności, jakie może mieć strona internetowa. W przeciwieństwie do wielu innych problemów z dostępnością, które jedynie pogarszają doświadczenie części użytkowników, pułapka klawiaturowa może całkowicie uniemożliwić użytkownikowi dalsze korzystanie ze strony. Jest to w istocie odpowiednik ustawienia fizycznej bariery w korytarzu bez zapewnienia jakiejkolwiek drogi obejścia.

Najbardziej dotknięte są osoby z niepełnosprawnościami motorycznymi lub fizycznymi, które nie mogą obsługiwać myszy i polegają wyłącznie na nawigacji klawiaturą. Obejmuje to osoby z takimi schorzeniami jak zespół cieśni nadgarstka i inne urazy przeciążeniowe, stwardnienie rozsiane, choroba Parkinsona, tetraplegia czy porażenie mózgowe. Według Światowej Organizacji Zdrowia około 1,3 miliarda osób — 16% światowej populacji — żyje z jakąś formą znaczącej niepełnosprawności, a zaburzenia motoryczne stanowią istotną część tej liczby. Dla tych użytkowników napotkanie pułapki klawiaturowej na stronie płatności, formularzu logowania czy widżecie czatu obsługi klienta może oznaczać całkowitą niemożność wykonania zadania.

Silnie dotknięci są także użytkownicy czytników ekranu — głównie osoby niewidome i słabowidzące. Czytniki ekranu, takie jak NVDA, JAWS i VoiceOver, nawigują wyłącznie za pomocą poleceń klawiaturowych. Jeśli fokus zostanie uwięziony w komponencie, użytkownik czytnika ekranu słyszy ten sam element powtarzany przy każdym naciśnięciu Tab, bez możliwości przejścia dalej lub cofnięcia się na stronie. Jest to głęboko dezorientujące i zmusza użytkownika do zamknięcia karty przeglądarki lub odświeżenia strony, co powoduje utratę wszelkich dotychczasowych postępów.

Rozważmy scenariusz z życia wzięty: użytkownik z ograniczoną sprawnością dłoni odwiedza turecką stronę e-commerce, aby kupić produkt. Dodaje przedmiot do koszyka i przechodzi do kasy. Strona płatności zawiera zewnętrzny widżet autouzupełniania adresu zbudowany w niestandardowym frameworku JavaScript. Widżet otwiera listę podpowiedzi w rozwijanym menu, gdy pole adresu otrzymuje fokus. Programista zapomniał dodać obsługę zdarzeń klawiatury do zamykania tego menu — więc gdy użytkownik przechodzi klawiszem Tab do pola adresu i pojawia się lista, nie może wyjść klawiszem Tab, nie może nacisnąć Escape i nie może zamknąć listy bez kliknięcia myszą. Użytkownik jest całkowicie zablokowany i nie może dokończyć zakupu. Nie jest to drobna niedogodność — to całkowite wykluczenie z usługi.

Poza dostępnością dla osób z niepełnosprawnościami, pułapki klawiaturowe dotykają także zaawansowanych użytkowników, którzy preferują nawigację klawiaturą ze względu na szybkość, użytkowników w środowiskach korporacyjnych, gdzie użycie myszy jest ograniczone, oraz użytkowników na niektórych urządzeniach mobilnych lub hybrydowych z fizycznymi klawiaturami. Usunięcie pułapek klawiaturowych poprawia więc doświadczenie szerszej grupy odbiorców niż tylko osób z niepełnosprawnościami.

Powiązane Zasady Axe-core

WCAG 2.1.2 wymaga testów manualnych. Żadna zautomatyzowana reguła axe-core nie wykrywa bezpośrednio i niezawodnie pułapek klawiaturowych. Wynika to z faktu, że narzędzia automatyczne działają poprzez analizę statycznej struktury DOM — mogą identyfikować elementy z fokusem, sprawdzać kolejność tabulacji i weryfikować atrybuty ARIA, ale nie są w stanie zasymulować pełnego, interaktywnego doświadczenia nawigacji klawiaturą, jakie wykonuje tester. Pułapka klawiaturowa zazwyczaj wynika z logiki obsługi zdarzeń JavaScript, która przechwytuje lub tłumi zdarzenia klawiatury w czasie działania; takie zachowanie nie jest widoczne w strukturze DOM i nie może zostać wywnioskowane przez analizator statyczny.

• Wymagane testy manualne — brak dedykowanej reguły axe-core: Axe-core nie dostarcza reguły, która automatycznie wykrywa pułapki klawiaturowe, ponieważ tryb błędu ma charakter behawioralny. Pułapka ujawnia się dopiero wtedy, gdy użytkownik faktycznie wchodzi do komponentu klawiszem Tab i próbuje go opuścić. Skaner automatyczny nie może tego odtworzyć, ponieważ musiałby symulować sekwencyjną nawigację klawiaturą po każdym elemencie z fokusem na stronie, wywołać wszystkie powiązane nasłuchiwacze zdarzeń JavaScript, a następnie ustalić, czy fokus opuścił zamierzony obszar — co jest problemem obliczeniowo nierozwiązywalnym dla złożonych stron. Dodatkowo, rozróżnienie między pułapką a zamierzonym ograniczeniem fokusu (jak w przypadku modala) wymaga osądu kontekstowego, którego reguły automatyczne nie są w stanie wiarygodnie zastosować. Testerzy powinni używać axe DevTools lub Lighthouse do identyfikacji elementów z fokusem i problemów z kolejnością tabulacji jako punktu wyjścia, ale następnie muszą ręcznie przejść klawiaturą przez każdy interaktywny obszar, aby potwierdzić, że nie występują pułapki.

Jak Testować

1. Uruchom zautomatyzowany skan dostępności jako punkt odniesienia. Otwórz axe DevTools (rozszerzenie przeglądarki) lub uruchom audyt dostępności Lighthouse w Chrome DevTools. Choć żadne z tych narzędzi nie oznaczy bezpośrednio pułapki klawiaturowej, skan zidentyfikuje elementy z fokusem, brakujące role ARIA i nieprawidłową kolejność tabulacji, które mogą wskazywać na ryzykowne komponenty interaktywne warte ręcznego zbadania. Zanotuj wszelkie niestandardowe widżety, osadzone iframy, komponenty zewnętrzne, modalne okna dialogowe, menu rozwijane, selektory daty, karuzele i edytory tekstu sformatowanego — to najczęstsze źródła pułapek klawiaturowych.
2. Odłącz lub odłóż mysz. Aby ręczne testy klawiatury były wiarygodne, nie możesz używać myszy. Odłóż mysz poza zasięg lub wyłącz ją w ustawieniach systemu operacyjnego, aby uniknąć przypadkowego polegania na niej podczas testów.
3. Nawiguj po całej stronie, używając wyłącznie klawiszy Tab i Shift+Tab. Zaczynając od paska adresu przeglądarki lub górnej części strony, naciskaj wielokrotnie Tab i obserwuj, gdzie przenosi się fokus. Śledź wizualnie wskaźnik fokusu na każdym kroku. Gdy dotrzesz do każdego komponentu interaktywnego — szczególnie do niestandardowych widżetów, osadzonej treści lub złożonych elementów interfejsu — upewnij się, że naciśnięcie Tab lub Shift+Tab przenosi fokus płynnie poza komponent do następnego lub poprzedniego elementu z fokusem na stronie.
4. Przetestuj każdy komponent interaktywny osobno. W przypadku modalnych okien dialogowych: otwórz modal, sprawdź, czy fokus przenosi się do jego wnętrza, następnie naciśnij Escape i potwierdź, że fokus wraca do elementu wywołującego. W przypadku menu rozwijanych: otwórz menu, nawiguj w jego obrębie, następnie naciśnij Escape i potwierdź, że menu się zamyka, a fokus wraca do elementu wyzwalającego. W przypadku selektorów daty, selektorów kolorów i podobnych widżetów: przejdź do nich klawiszem Tab, wykonaj interakcję, następnie przejdź dalej klawiszem Tab i potwierdź, że fokus wychodzi. W przypadku osadzonych iframe’ów (np. map, odtwarzaczy wideo, widżetów czatu): przejdź do iframe’u klawiszem Tab, nawiguj w jego obrębie i potwierdź, że możesz wyjść z niego klawiszem Tab z powrotem na główną stronę.
5. Testuj z NVDA i Firefox. Uruchom NVDA, przejdź do strony w Firefox i używaj Tab do poruszania się po elementach interaktywnych. Zwracaj uwagę, czy NVDA odczytuje nowy element przy każdym naciśnięciu Tab, czy też wydaje się wracać do tego samego elementu. Jeśli Tab nie przenosi fokusu poza komponent, jest to pułapka klawiaturowa.
6. Testuj z VoiceOver i Safari na macOS. Włącz VoiceOver (Command + F5), otwórz stronę w Safari i używaj klawisza Tab do nawigacji. Upewnij się, że VoiceOver ogłasza nowy element przy każdym naciśnięciu Tab i że fokus nigdy nie utknie w obszarze, którego nie możesz opuścić.
7. Testuj z JAWS i Chrome. Uruchom JAWS, przejdź do strony w Chrome i używaj Tab do nawigacji po wszystkich komponentach interaktywnych. W szczególności przetestuj każdy komponent, który używa zarządzania fokusem sterowanego JavaScriptem, ponieważ JAWS wchodzi w interakcję z drzewem dostępności w sposób, który może ujawnić pułapki niewidoczne przy testach wizualnych.
8. Sprawdź niestandardowe mechanizmy wyjścia. Jeśli jakikolwiek komponent wymaga do wyjścia klawisza innego niż Tab, Shift+Tab lub Escape, upewnij się, że strona wyraźnie to komunikuje użytkownikowi — na przykład poprzez instrukcje na ekranie, podpowiedź (tooltip) lub komunikat w regionie ARIA live, gdy fokus wchodzi do komponentu.

Jak Naprawić

Modalne Okno Dialogowe Bez Obsługi Escape — Nieprawidłowe

<!-- Modal opens but has no Escape key handler and no close button reachable by keyboard -->
<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>
  <!-- No close button, no Escape key listener -- keyboard users are trapped -->
</div>

Modalne Okno Dialogowe Bez Obsługi Escape — Prawidłowe

<!-- Modal with proper focus trap, Escape handler, and accessible close button -->
<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>
  <!-- Close button is reachable by Tab and allows keyboard users to exit -->
  <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 key closes the modal and returns focus to trigger
    }
  });

  function closeModal() {
    document.getElementById('modal').hidden = true;
    document.getElementById('modal-trigger').focus(); // Return focus to opener
  }
</script>

Niestandardowe Menu Rozwijane Przechwytujące Wszystkie Zdarzenia Tab — Nieprawidłowe

<!-- Custom dropdown intercepts all keydown events including Tab, preventing focus from leaving -->
<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: This captures ALL keyboard events and calls preventDefault on Tab,
  // meaning the user can never Tab out of this component
  document.getElementById('custom-select').addEventListener('keydown', function(e) {
    e.preventDefault(); // This traps the keyboard
    if (e.key === 'ArrowDown') { /* move focus down */ }
    if (e.key === 'ArrowUp') { /* move focus up */ }
  });
</script>

Niestandardowe Menu Rozwijane Przechwytujące Wszystkie Zdarzenia Tab — Prawidłowe

<!-- Correct: Only prevent default for arrow keys used for internal navigation;
     allow Tab and Escape to function normally so users can exit -->
<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(); // Only prevent default for internal navigation keys
      // move focus between options
    }
    if (e.key === 'Escape' || e.key === 'Tab') {
      // Do NOT call preventDefault -- allow Tab and Escape to propagate
      // so the browser can move focus away from this component naturally
      closeDropdown();
    }
  });
</script>

Osadzony Zewnętrzny Iframe Bez Ścieżki Wyjścia — Nieprawidłowe

<!-- An embedded chat widget iframe that absorbs all Tab keypresses
     and never returns focus to the parent page -->
<iframe
  src='https://example-chat-widget.com/embed'
  title='Customer support chat'
  width='350'
  height='500'>
</iframe>
<!-- The iframe's internal JavaScript consumes Tab events, trapping users inside it -->

Osadzony Zewnętrzny Iframe Bez Ścieżki Wyjścia — Prawidłowe

<!-- Use a button to open the chat in a new window rather than embedding
     an iframe that may trap keyboard users -->
<button
  id='open-chat'
  onclick='window.open("https://example-chat-widget.com", "_blank", "noopener")'>
  Open Customer Support Chat (opens in new window)
</button>

<!-- If an iframe must be used, add a visible skip link before it
     so keyboard users can bypass it if they choose -->
<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>

Typowe Błędy

• Wywoływanie event.preventDefault() wewnątrz nasłuchiwacza keydown bez ograniczenia do konkretnych klawiszy — zastosowanie preventDefault() do wszystkich zdarzeń klawiatury na komponencie z fokusem blokuje działanie Tab i Shift+Tab, natychmiast tworząc pułapkę klawiaturową. Zawsze ograniczaj preventDefault() tylko do konkretnych klawiszy, które komponent musi obsługiwać wewnętrznie (np. klawisze strzałek dla listboxów).
• Budowanie modalnego okna dialogowego, które ustawia fokus w swoim wnętrzu, ale nie zapewnia obsługi klawisza Escape ani przycisku zamknięcia — programiści często poprawnie implementują część wzorca modala z wejściem fokusu, ale zapominają, że ograniczenie fokusu wewnątrz modala jest dopuszczalne tylko wtedy, gdy zawsze istnieje klawiaturowo dostępne wyjście. Każdy modal musi obsługiwać klawisz Escape i zawierać element zamykający dostępny w kolejności tabulacji.
• Używanie tabindex='-1' na elemencie kontenerowym, aby zapobiec pojawianiu się go w kolejności tabulacji, przy jednoczesnym pozwoleniu JavaScript na programowe przeniesienie do niego fokusu — gdy fokus zostanie przeniesiony do elementu z tabindex='-1' za pomocą element.focus(), nie ma naturalnego celu Tab, aby go opuścić, co może uwięzić użytkownika, jeśli nie zostanie zaimplementowana dodatkowa obsługa klawiatury.
• Osadzanie zewnętrznych widżetów (czat, mapy, wideo) bez audytu pod kątem pułapek klawiaturowych — dostawcy nie zawsze budują swoje osadzone widżety jako dostępne z klawiatury. Właściciele stron pozostają odpowiedzialni za całą treść na swoich stronach, w tym za osadzone komponenty zewnętrzne. Zawsze testuj ręcznie osadzone komponenty i, jeśli uwięzią użytkowników klawiatury, opatrz je linkiem pomijającym lub zastąp alternatywą bezpieczną dla klawiatury.
• Implementowanie pułapki fokusu dla modala lub panelu wysuwanego bez zwolnienia jej po zamknięciu komponentu — jeśli JavaScript ograniczający fokus nie zostanie poprawnie wyczyszczony po zamknięciu modala, może nadal przechwytywać zdarzenia Tab i więzić użytkownika na teraz niewidocznej warstwie.
• Używanie CSS visibility: hidden lub display: none do ukrycia przycisku zamknięcia okna dialogowego ze względów wizualnych bez zapewnienia alternatywnego wyjścia z klawiatury — jeśli przycisk zamknięcia jest ukryty wizualnie, ale nie usunięty z drzewa dostępności, użytkownicy czytników ekranu nadal mogą go znaleźć; ale jeśli jest ukryty także z drzewa dostępności, może nie istnieć żadne wyjście. Upewnij się, że wszystkie mechanizmy zamykania są obsługiwalne z klawiatury, nawet jeśli są wizualnie dyskretne.
• Budowanie niestandardowych komponentów autouzupełniania lub podpowiedzi, które otwierają listę sugestii, a następnie kierują wszystkie naciśnięcia Tab na przechodzenie między sugestiami zamiast wyjścia — użytkownicy powinni móc nacisnąć Escape, aby zamknąć listę sugestii, a następnie Tab, aby przejść do następnego pola formularza. Widżety autouzupełniania, które przekierowują Tab na nawigację wewnętrzną, naruszają to kryterium.
• Zapominanie o testowaniu edytorów tekstu sformatowanego (edytorów WYSIWYG, takich jak TinyMCE, CKEditor czy Quill) — komponenty te zarządzają własną interakcją klawiatury wewnętrznie i często są źródłem pułapek klawiaturowych. Zawsze upewnij się, że naciśnięcie Escape lub udokumentowanej sekwencji klawiszy powoduje wyjście z edytora i powrót fokusu do normalnej kolejności tabulacji strony.
• Zakładanie, że skoro komponent używa natywnych elementów HTML, nie może stanowić pułapki klawiaturowej — element <select> wewnątrz formularza, który używa JavaScript do nadpisania zdarzenia blur, nadal może uwięzić fokus. Użycie semantycznego HTML nie gwarantuje braku pułapek klawiaturowych, gdy na wierzch nakładana jest niestandardowa obsługa zdarzeń JavaScript.
• Brak dokumentacji na ekranie, gdy do wyjścia z komponentu wymagany jest niestandardowy klawisz — WCAG 2.1.2 wyraźnie dopuszcza komponenty, które wymagają niestandardowych klawiszy do wyjścia, pod warunkiem poinformowania użytkownika. Jeśli twój widżet wymaga naciśnięcia F6 lub niestandardowej kombinacji klawiszy, musisz jasno to zakomunikować użytkownikowi, najlepiej poprzez widoczne instrukcje obok komponentu lub komunikat w regionie ARIA live, gdy fokus wchodzi do komponentu.

Związek z Tureckimi Regulacjami Dotyczącymi Dostępności

Prezydencki Okólnik Turcji 2025/10, opublikowany w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia wiążące wymagania dotyczące dostępności cyfrowej dla szerokiego zakresu podmiotów publicznych i prywatnych działających w Turcji. Okólnik nakazuje zgodność z międzynarodowo uznanymi standardami dostępności stron internetowych — przyjmując WCAG 2.1 na poziomie AA jako punkt odniesienia, który obejmuje wszystkie kryteria poziomu A, w tym WCAG 2.1.2 Brak pułapki klawiaturowej.

WCAG 2.1.2 jest kryterium poziomu A, który reprezentuje minimalny poziom zgodności. Zgodnie z okólnikiem, zgodność na poziomie A jest obowiązkowa dla wszystkich objętych podmiotów. Instytucje publiczne są zobowiązane do osiągnięcia tej zgodności w ciągu jednego roku od publikacji okólnika, podczas gdy podmioty sektora prywatnego mają dwa lata na dostosowanie się.

Zakres podmiotów objętych okólnikiem jest szeroki i obejmuje instytucje publiczne i organy rządowe na wszystkich szczeblach, platformy e-commerce i operatorów rynków internetowych, banki i instytucje usług finansowych, szpitale i świadczeniodawców opieki zdrowotnej, firmy telekomunikacyjne z 200,000 lub większą liczbą abonentów, biura podróży, prywatne firmy transportowe oraz szkoły prywatne upoważnione przez Ministerstwo Edukacji Narodowej (MoNE). Oznacza to, że brak rozwiązania problemu pułapek klawiaturowych na stronie internetowej lub w aplikacji webowej obsługiwanej przez którykolwiek z tych podmiotów stanowi bezpośrednie naruszenie obowiązkowych tureckich regulacji dotyczących dostępności.

Biorąc pod uwagę powszechność pułapek klawiaturowych w złożonych aplikacjach webowych — szczególnie w portalach bankowości internetowej, systemach rezerwacji wizyt w szpitalach, procesach płatności w e-commerce i stronach zarządzania kontem w telekomunikacji — WCAG 2.1.2 zasługuje na szczególną uwagę w kontekście zgodności w Turcji. To właśnie tego typu interfejsy, bogate w interakcje i oparte na JavaScript, najczęściej zawierają niestandardowe widżety, modalne okna dialogowe i osadzone komponenty zewnętrzne, które mogą nieumyślnie uwięzić użytkowników klawiatury.

Organizacje objęte okólnikiem powinny traktować testowanie pod kątem pułapek klawiaturowych jako nienegocjowalną część procesu audytu dostępności. Ponieważ narzędzia automatyczne nie są w stanie wiarygodnie wykrywać pułapek klawiaturowych, objęte podmioty muszą zainwestować w ręczne testy klawiatury prowadzone przez wykwalifikowanych specjalistów ds. dostępności, najlepiej z udziałem użytkowników z niepełnosprawnościami, jako element drogi do zgodności. Brak usunięcia pułapek klawiaturowych zidentyfikowanych podczas audytu stanowi nie tylko ryzyko prawne w świetle okólnika, ale także istotną barierę w dostępie dla użytkowników z niepełnosprawnościami motorycznymi i wzrokowymi, którzy polegają na nawigacji klawiaturą, aby korzystać z usług cyfrowych.